《人月神话》是软件工程管理的一本奇书，他用深入浅出的文字阐明了在软件工程开发的过程中，我们可能会遇到的陷阱，以及如何避免它们。
系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所"应该"花费的时间。
在单个的任务中，“一切将运转正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排的那样顺利，然而大型的编程工作，或多或少包含了许多子任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常的小，甚至接近于零。
用人月作为衡量一项工作的规模是一个危险和带有欺骗性质的神话。它暗示着人员数量和时间是可以相互替换的。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别与其他部分单独协作，则工作量按照n(n-1)/2递增。在一对一交流的情况下，3个人的工作量是2个人的3倍，4个人的工作量是2个人的6倍。
向进度落后的项目增加人手，只会使进度更加落后。
效率高和效率低的实施者之间个体差异非常大，经常能达到数量级的水平。
概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
而进度压力却要求很多人员来开发系统。有两种方法可以解放这种矛盾，第一种是仔细地对设计方法和具体实现进行分工。第二种前一章节所讨论的，一种崭新的组建开发团队的方法。
在开发第一个系统时，结构师倾向于精炼和简洁，他知道自己对正在进行的任务不够了解，所以会谨慎、仔细的工作。
第二个系统设计师们所设计的最危险的系统。而当他着手设计第三个或第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
对于软件开发团队来说，进取同样是非常必要的。进取提供了缓冲和储备，使开发团队能够处理常规的灾祸，可以预计和防止小的灾祸。