1. 焦油坑
过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧 烈地挣扎
实际上，我认为学习编程的最困难部分，是将做事的 方式往追求完美的方向调整。
下一个烦恼——概念性设计是有趣的，但寻找琐碎的 bug 却只是一项重复性的活动。 伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的劳动。
人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂 度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
2. 人月神话
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所 有因素加起来的影响还大。
用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
- 1/3计划
- 1/6编码
- 1/4构件测试和早期系统测试
- 1/4系统测试，所有的构件已完成
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
3. 外科手术队伍
我常常重复这样的一个观点，需要协作沟通的人员的数量影响着开发成本，因为成本 的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。 这一点，也暗示系统应该由尽可能少的人员来开发。
测试人员。外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对 整个工作进行测试。因此，测试人员既是为他的各个功能设计系统测试用例的对头，同时也 是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台。
3.1. 核心启发
- 软件项目延期往往首先是管理问题，不只是技术问题。
- 人力不是线性叠加资源，沟通成本会快速上升。
- 测试、设计、调试这些看似“后段”的工作，往往比编码本身更耗时。
3.2. 我的理解
《人月神话》最有价值的地方，不是某一句名言，而是它反复提醒：复杂软件开发的难点，很多来自组织协同、进度管理和系统复杂度本身。
3.3. 现实映射
- 进度落后时盲目加人，通常只会让沟通更乱。
- 架构设计没想清楚时，后期 bug 和返工会指数级增加。
- 测试周期被压缩时，问题只会向上线后转移，而不会真正消失。