分工
1776年3月，亚当·斯密的《国富论》中第一次提出了劳动分工的观点，并系统全面地阐述了劳动分工对提高劳动生产率和增进国民财富的巨大作用。一个没有受过专门训练的劳动者，无论如何努力，一天也生产不了20枚扣针，但有了分工之后，经过前后18道工序，每人每天可以生产4800枚扣针。
社会生活也同样进行了分工，裁缝不想制作他自己的鞋子，而向鞋匠购买；鞋匠不想制作他自己的衣服，而雇裁缝制作；农民不想缝衣，也不想制鞋，而宁愿请不同的工匠去做。大家各尽所能，各取所需。
在软件项目中，分工也很常见。市场，需求，设计，开发，测试，运维，运营，等等各个岗位都有专业的人来完成。让一个人胜任所有的这些岗位，在当今社会，几乎是不可能的。人们只能各司其职，紧密合作。
信息爆炸
然而，分工的神话，可能真的要止于软件的开发环节了。与工业生产的重复性劳动不同，软件开发恰恰是一个消除重复的过程，它更像是一种智力活动。所以，与其说工程师们在合力建造一座大厦，不如说他们在合写一部著作。沟通变成了关键，分工产生的信息不对称，会在合作的时候迸发出来。
如果将100位世界级的音乐家组成一个乐队而没有指挥，简直无法想象这个世界级的乐队会奏出怎样的音乐。让这些音乐家们发挥他们的最佳水平不如让他们知道何时应该大声何时应该轻柔来得重要，这样的乐队简直是在浪费人才。相同的人才浪费在软件开发方面也很常见，优秀的团队，专业的开发人员，采用最新的开发实践，但还是无法达成项目计划目标的要求。
回想一下，软件开发过程中的大部分时间，都是在滚动屏幕，试着查找和理解代码，而真正进行代码编写的时间比例是非常小的。最坏的情况是，团队中每个人都要对这些陈旧代码自学一遍，并且对它们进行的任何修改，其他人还要再重新学习。
这些沟通成本是巨大的，即便是最称职的工程师，大多数时间考虑的也通常不是怎样实现一个功能，而是在研究以前别人是怎么做的，而且这个『以前』可能并不会太早，这个『别人』也可能是过去的自己。因此，越是代码有大量产出的团队，阅读障碍越是明显，阻碍了团队效率的进一步提高。
团队效率
生活中多数东西，最好与普通之间的差距不超过两倍。比如出租车司机，最棒的司机与普通司机之间的差距大概是30%，最好的与普通之间的差距有多大呢？20%？最好的CD机与普通CD机的差距有多大？20%？这种差距很少超过两倍。乔布斯在《遗失的访谈》中指出，在软件行业，还有硬件行业，这种差距有可能超过15倍，甚至100倍。
在一项相关研究中，Sackman、Erikson和Grand曾对一组具有经验的程序员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异。简而言之，$20,000/年的程序员的生产率可能是$10,000/年程序员的10倍，数据还显示经验和实际的表现没有直接联系。
考虑到工程师们在效率方面的差异，Harlan Mills提供了一个崭新的、创造性的解决方案。Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
有些软件公司已经采用了类似的工作方式：
Facebook的工程师们不分前端和后端，只分product和infrastructure。做product的通常都是全栈工程师，不需要对特定的技术非常精通，但要求学习能力和灵活性足够好，不能只做自己舒适区以内的事情。infrastructure拥有更多各个领域的specialist，前端只是其中之一。infrastructure的客户就是product，要做的事情就是让product开发实际产品时效率更高。
可见，效率问题应该始终围绕着瓶颈展开，不能怀有侥幸心理。最大化并行程度，并不是一个永远适用的方法，也要看问题本身是否具有可并行处理的属性。一个人20秒可以跑完100米，可是20个人1秒却不可能跑完全程。
