这部写于1974年的软件工程管理经典著作，至今已有43年历史。但是可惜的是，这样的著作至今少之又少，今天我们重温这部经典。或许它已成为一个时代，但依然给当下人之深思。—imagineXie
一、焦油坑
编程系统产品的演进：
- 程序要转变成编程产品，可以被任何人运行、测试、修复和扩展的程序，在多种平台上运行，程序必须要按照普遍认可的风格来编写，特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。
- 程序要转变成编程系统中的一个构建单元，程序必须按照一定的要求编制，使输入和输出在语法和语义上与精确定义的接口一致。程序还需要与其他系统构件单元一道，以任何能想象到的组合进行测试。
- 编程系统产品，是真正有用的产品，是大多数系统开发的目标。
现实中，很少人类活动要求完美，所以人类对一种追求完美的方式本来就不太习惯。
所以，学习编程最困难的部分，是将做事的方式向追求完美的方向调整。
产品开发所基于的技术在不断地进步。一旦设计被冻结，在概念上就已经开始陈旧了。不过，实际产品需要一步一步按阶段实现。实现落后与否的判断应根据其他已有的系统，而不是未实现的概念。因此，我们所面临的挑战和任务是在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。
编程，是一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。对于许多人而言，其中的快乐远远大于苦恼。
二、人月神话
乐观主义
所有的编程人员都是乐观主义者。你总能看到无论是什么样的程序，结果在年轻人（因为程序员更加年轻）看来都是毋庸置疑的：“这次它肯定会运行”或者“我刚刚找出了最后一个错误。”
所以系统编程的进度安排背后的第一个错误假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。然而，这种乐观主义应该受到慎重分析。
是什么造成这样的乐观主义的呢？在许多创造性活动中，实施的介质往往很难掌握。例如木头切割、上油漆、电气接线等。这些难以掌握的介质限制了思路的表达，对现实造成了许多预料之外的困难。然而，遇到这样的困难，我们总是倾向于去责怪哪些介质，因为他们不顺应“我们”设定的思路。
计算机编程是一种基于容易掌握的介质，编程人员通过纯粹的思维活动来开发程序。正是由于这样的介质易于驾驭，程序员总会期待在实现过程中不会碰到困难，从而造成乐观主义的弥漫。然而，你总会发现bug，所以，这样的乐观主义并非应该在程序员看来是理所应单的。
人月
人月是一种在估计和进度安排中使用的工作单位。如图，如果你认为人员数量的增加可以替代时间的减少，那么这将是一种危险和带有欺骗性的神话。
当任务由于次序上的限制不能分解时，人力的添加对进度没有帮助。就如一位母亲，孕育一个生命需要10个月。这和许多软件开发工作相类似。
软件开发本质上是一项系统工作，其中包含的实践，沟通，交流的工作量非常大，它会很快消耗任务分解所节省下来的个人时间。从而，添加更多的人生，实际上是延长了而不是缩短了时间进度。
系统测试
由于我们的乐观主义，通常实际上出现的缺陷数量比预计的要多得多。因此，系统测试的时间安排往往成为早期进度策划师非常重要的环节。你可以想象，直到接近项目的发布日期才有人发现进度上的问题，这样的坏消息通常是没有任何预兆的。
所以，从传统项目进度安排的研究发现，很少有项目允许为测试分配一半的时间。
空泛的估算
为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中比其他工程领域要普遍的多。加上非阶段化方法的采用，少的可怜的数据支持，有时还要凭借项目经理的直觉，这样的方式将很难产出生产有力的、看似可靠的和规避风险的估计。
那么有什么解决方案呢？
- 开发并推行生产率图表、缺陷率图表、估算规则等等；
- 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强的多。
项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。