空泛的估算
编程人员有时和厨师一样，某项任务的计划进度，受限制与客户要求的紧迫程度，然而紧迫程度并不能控制实际完成的情况。
例如，约定两分钟内煎完一个鸡蛋，看上去简单，但实际上它无法在两分钟内完成，顾客只能选择等待或者吃生鸡蛋。厨师的另一个选择是把火开大，不过结果常常是得到一个更糟糕的煎蛋。
为了满足顾客期望而造成的不合理进度安排，在软件领域中非常普遍。不科学的估算方法，少的可怜的数据支持，完全凭借产品经理直觉的判断，这样的方式很难得出有力、可靠、低风险的评估。
显然，我们有两种解决方案：
- 采用科学的方法，例如生产率图表、缺陷率图表、估算规则等
- 项目经理挺直腰杆，坚持他们的估计，确信自己的经验比客户期望进度要强得多
可是，我们对自己的估计不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气。
重复产生的进度灾难
当一个周期4个月的项目，在第2个月的节点上进度没有达到要求，此时项目经理可以做些什么呢：
- 假设任务必须按时完成，整体进度估算合理，那么就指派更多的人手
- 假设任务必须按时完成，整理进度估算偏少，那么指派更多更多的人手
- 不削减任务，确保工作能彻底完成，重新安排进度
- 削减任务，仔细认真的调整项目，重新安排进度
前两种情况是灾难性的，因为增加人手从三方面增加了项目必要的总体工作量：
- 任务重新分配本身和所造成的工作中断
- 培训新人员
- 额外的相互沟通
而且毫无疑问的是，增加人手所开发出的产品，比没有增加人手而是重新安排进度所生产出的产品更差。向进度落后的项目中增加人手，只会使得项目更加落后。
以上内容就是《人月神话》第二章——人月神话，后两节所讲述的内容
作者反复论证了软件项目延期最主要的原因——缺乏合理的进度安排。读者不忍发问了“没有按时完成任务是因为时间太短”这难道不是诡辩吗？
其实，作者想要提醒的是那些制定项目进度的人。进度估算作为软件工程中十分重要的一环，常常得不到应有的重视，不全面的、不科学的、不负责任的进度安排时常发生。项目经理总会有意无意的犯下各种错误，例如忽略测试阶段、盲目自信、缺少方法、缺乏勇气等等。这么说来，软件项目延期的主要责任人也就是制定项目进度的人。
放到现实中来说，作者的观点其实是有前提假设的，那就是所有的程序员都拒绝加班，所有项目都会指派一名项目经理，所有客户都知道自己要什么。说不定国外的环境确实是这样的，但是这三点假设在我们身边都是不成立的。
首先，程序员无条件的加班让项目经理更加盲目自信，为了能够接收到项目，不断地妥协于进度紧张的客户。其次，人员安排的混乱和欠缺，大多数项目是不存在项目经理的，甚至是由商务人员直接规划进度。最后，也是最可怕的事情，客户不清楚自己需要的是什么。
这些问题都发生在进度估算阶段之前，但由于不是本书重点所以不再赘述，以后会在其他书籍的导读中再来讨论这几个问题。
总之，《人月神话》第二章作者通过严谨详实的论证，得出了这样的结论，多少有点偏袒程序员的意思，难道项目延期的问题只在于安排进度的人吗？
