2. 人月神话
乐观主义
- 系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
- 我们的构思是有缺陷的，因此总会发现Bug。也就是说，我们的乐观主义并不应该是理所应当的。
- 在单个的任务中，“一切都将运转正常”的假设在进度上具有可实现性。然而大型的编程工作，或多或少都包含了许多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于零。
人月
- 第二个谬误的思考方式是，在估计和进度安排中使用的工作量单位：人月；
- 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
- 人数和时间可以替换仅适用于：1.任务可分解（没有次序上的限制） 2.参与人员之间不需要相互交流
系统测试
要为系统测试安排足够的时间
空泛的估算
编程人员，同厨师一样，某项任务的计划进度，可能受限于顾客要求的紧迫程度，但紧迫程度无法控制实际的完成情况。就像约好在两分钟内完成一个煎蛋，看上去可能进行得非常好，但当它无法在两分钟内完成时，顾客只能选择等待或者吃生煎蛋。软件顾客的情况类似。
厨师还可以选择把火开大，不过结果常常是无法“挽救”的煎蛋————一面已经焦了，而另一面还是生的。
- 为了满足顾客的期望日期而造成不合理的进度安排，在软件领域中比其他任何工程领域要普遍得多。
- 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比期望派生出的结果要强得多。
重复产生的进度灾难
当一个软件项目落后于进度时，通常的做法是加派人手。这可能有所帮助，也可能无法解决问题。
- 重新安排进度。P.Fagg(经验丰富的硬件工程师)的忠告：“避免小的偏差（Take no small slips.）”也就是说，在进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
- 削减任务。当项目延期导致的二次成本非常高时，这常常是唯一可行的方法。
简化的Brooks法则：（冒昧的）向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.）