焦油坑
在过去几十年的软件发展史中，大型开发系统团队的确开发出了可运行的系统，但是非常少数的项目满足了目标、时间进度和预算的要求，一个接一个淹没在焦油坑中。究其根源，在于问题纷繁复杂，难以解决。
编程系统产品
由上图可以看出，程序变成编程产品需要文档、并可以使用、修复、扩展，编程产品的成本至少是程序的三倍。程序变成编程系统中的一个构件单元需要与其他程序交互，用来组装和搭建整个系统，测试也会更为复杂，相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元，成本还会更高。
最后的编程系统产品才是真正有用的产品，是大多数系统开发的目标，这才是真正有用的产品。
职业的乐趣
编程的有趣在于首先它给人创建事物的纯粹快乐；其次，开发对其他人真正有用的东西；实现系统各个部分并组合到最终实现系统这个过程体现出魔术般的力量；学习的乐趣，编程过程中也在不断提升自己；最后，乐趣还在于编程易于驾驭的介质。
总之，编程不仅满足我们进行创造的渴望还愉悦嘞我们的内在情感。
职业的苦恼
编程的苦恼在于必须追求完美；由他人控制工作环境和工作目标；寻找以及处理BUG的过程是枯燥痛苦的；软件产品更新速度飞快，经常投入大量劳动后收获甚微。
综上，编程就像一个焦油坑，这是一个乐趣与苦恼并存的创造性活动。
人月神话
在软件项目中，经常由于缺乏合理的时间进度导致项目滞后，原因在于：管理者对估算技术缺乏足够的研究；错误地认为人和月可以互换；软件经理对自己的估算缺乏信心而没有耐心持续地估算这项工作；缺少跟踪和监督；盲目增加人力。
乐观主义
系统编程进度安排都假设一切都进度良好而没有留出遇到意外问题的时间，这是导致开发时间滞后乃至项目延误的一个重要原因。
在单个任务中，一切正常或许可以实现，但是在大型编程中，由于经常有任务互相制约甚至前后次序的情况，一切正常几乎就不可能实现了。
人月
用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
事实上，人数和时间的互换在现实软件团队开发中不可能实现，这两者之间并非线性关系。当任务由于次序限制不能分解时，增加人力不会有任何帮助。当任务可以分解时，增加人手也比未调整前要差一些。造成这种情况的原因是培训和相互交流造成的沟通负担。需要的交流越多，造成的后果越严重。
所以，增加更多的人手实际上是延长了时间进度。
系统测试
系统测试由于顺序限制尤为影响时间进度，而且其要求的时间依赖于所遇到的错误、缺陷数量以及捕捉它们的程度。所以，分配给测试的时间应该投入进度中一半的时间。如果不为系统测试安排足够时间很容易造成巨大的灾难。
空泛的估算及重复产生的进度灾难
为了满足顾客期望的日期而做不合理进度安排，在软件领域尤为普遍。而且，非阶段化方法的采用，不足的数据支持，加上软件经理的错误估计，很难生产出健壮可靠和规避风险的估计。
对于此问题，我们要么推行可靠地估算规则，要么项目经理坚持确信自己的经验和直觉比从期望派生出的结果要强得多。
向进度落后的项目中增加人手，只会使进度更加落后。如果在计划较短的时间内分派较多的人手，将无法得到可行的进度表。
总之，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
外科手术队伍
问题与Mills 的建议
需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、不充分的，开发出的是无法在概念上进行集成的产品。
对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。
如何调和这两方面的矛盾呢？
Mills 建议大型项目的每一个部分由一个团队解决，但是同每个成员截取问题某个部分的做法相反，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
如何运作
首先，外科医生和副手都了解所有的设计和全部的代码。这节省了空间分配、磁盘访问等的劳动量，同时也确保了工作概念上的完整性。
第二，在外科手术团队中，不存在利益的差别，观点的不一致由外科医生单方面来统一，可以达到客观的一致性。
另外，团队中剩余人员职能的专业化分工是高效的关键，它使成员之间采用非常简单的交流模式成为可能。
团队的扩建
对于协调的问题，还是需要使用分解的技术。可以认为整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须专注于体系结构。总的说来，上述的角色分工和技术是可行的，在实际工作中，具有非常高的效率。