《人月神话》第二章主要讲的是软件工程的滞后灾难的出现及其原因，它比其他因素造成的影响加起来还要大。
首先，在软件工程项目中缺乏合理的进度安排是造成项目滞后的主要原因。前期对项目缺少研究，对自己的估算缺乏信心，实现过程中对进度缺少监督和跟踪，下意识增加人力造成火上浇油等都是缺乏合理进度安排造成的影响。在我们目前阶段的学习以及团队开发过程中，更可能出现进度预测不准确的原因是，我们无法对自己的能力有个合理的估算，也无法对于自己每天能完成的工作量和专心程度做正确的估算，而且没有经验也是一大主要原因。
之前曾经听别的学长说软工是吃青春饭的，开始不理解，现在有些认识了。年轻人很多都是乐观主义者，他们很习惯的会说出“这次肯定运行成功”之类的话。所以这些乐观主义者也是造成项目滞后的原因，他们没有看到目前的软件所存在的问题。很多交织和累积的问题。
人月作为衡量一项工作的规模是一个危险的和带有欺骗性的神话，这也就是“人月神话”这个名称的由来。人员和时间互换仅仅适用于任务可以分配给参与人员，并且他们之间不需要交流。但是软件工程是一项浩大的工程，需要大量的沟通交流，如果增加人手，则需要更多的交流，这样下去可能造成相反的效果，所以说大的软件项目中，不可能存在人月神话的模式，之所以称之为神话，我想原因也在此吧。
之前老师讲到过单元测试。单元测试是用来更正缺陷。由于乐观主义，导致出现了BUG，然后我们就需要进行单元测试，因而书中说，系统测试进度的安排常常是编程中最不合理的部分。
编程人员像厨师，进度受顾客施压影响。这就像我们平常做作业一样，那个老师厉害，先把哪门作业完成，但是质量不敢保证。项目负责人员根据自己的经验，为了迎合顾客的需求，从而做出了一个并不合理的进度估计。从根本上说，是对自己和项目以及顾客的极其不负责任，很容易失去用户。
向进度处于落后的项目添加人手，是一个不理智的决定，甚至可能造成进度更加落后。这就是重复产生的灾难。添加人手后需要培训，对项目任务重新分配，这也需要消耗时间，而且新添加的人手需要的交流更多，而且在某项情况下，原先已经做好的某些项目可能会丢失，这还是在不考虑每个人工作习惯的情况下。这也就产生了所谓的Brooks法则--向进度落后的项目增加人手，只会使使进度更加落后。
因此，为了避免对项目造成滞后的影响，就要对项目进度有合理安排，这是最主要的，其次要避免乐观主义，进度落后的时候不要添加人手。