第1章 焦油坑
1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。
我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。
1.2 编程为什么会有趣？作为回报，它的从业者期望得到什么样的快乐？
首先，这种快乐是一种创建事物的纯粹快乐。
其次，这种快乐来自于开发对他人有用的东西。
第三，快乐来自于整个过程中体现出的一股强大的魅力。
第四，这种快乐是持续学习的快乐，它来自这项工作的非重复特性。
最后，这种快乐还来自于在易于驾驭的介质上工作。
1.3 职业的苦恼
首先，苦恼来自追求完美，这是学习编程的最困难部分
其次，苦恼来自由他人来设定目标、供给资源和提供信息。
下一个苦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。
最后一个苦恼，人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢，而产品在即将完成时总面临着陈旧过时的威胁。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。
第2章 人月神话
缺乏合理的时间进度是造成项目滞后的最主要原因。
导致这种普遍性灾难的原因是什么呢？
首先，我们对估算技术缺乏有效的研究，我们总是基于一种不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
2.1 所有的编程人员都是乐观主义者：“一切都将运作良好”。所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——概念以及灵活的表现形式来开发程序。正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。
2.2 我们围绕成本核算的估计技术，混淆了工作量和项目进展。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
2.3 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
在许多重要的方面，它与传统的进度安排方法不同：
分配给计划的时间比寻常的多。
对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
容易估计的部分，即编码，仅仅分配了六分之一的时间。
通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证。
2.4 作为一个学科，我们缺乏数据估计。因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计。
2.5 Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。