1. 焦油坑

过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧 烈地挣扎

实际上，我认为学习编程的最困难部分，是将做事的 方式往追求完美的方向调整。

下一个烦恼——概念性设计是有趣的，但寻找琐碎的 bug 却只是一项重复性的活动。 伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。

人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂 度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。

2. 人月神话

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所 有因素加起来的影响还大。

用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话

对于软件任务的进度安排，以下是我使用了很多年的经验法则：

• 1/3计划
• 1/6编码
• 1/4构件测试和早期系统测试
• 1/4系统测试，所有的构件已完成

向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）

3. 外科手术队伍

我常常重复这样的一个观点，需要协作沟通的人员的数量影响着开发成本，因为成本 的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。 这一点，也暗示系统应该由尽可能少的人员来开发。

测试人员。外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对 整个工作进行测试。因此，测试人员既是为他的各个功能设计系统测试用例的对头，同时也 是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台。