人月神话
焦油坑
编程有它的乐趣，来自于创造事物、创造有用的劳动成果、精妙组织产生的魔术般力量、学习和挑战和自我驾驭等等。然而这份职业也有自己的问题，如必须追求完美，由他人设定目标和供给资源和信息，不可避免的重复劳动，以及更新换代快等等。
而软件工程（尤其是开发大型系统）就像焦油坑，只有非常少数项目能满足目标、时间进度和预算的要求。表面上看，没有一个单独的问题导致了困难，但当它们相互纠缠和积累在一起的时候，麻烦就来了。
人月神话
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因：
- 缺乏有效的估算；
- 假设人和月可以互换，错误地将进度与工作量混淆；
- 对估算没有信心，而又不愿意持续估算；
- 对进度缺少跟踪和监督；
- 进度偏移时，下意识增加人力，火上浇油，适得其反。
乐观主义
所有的编程人员都是乐观主义者，“这次一定能运行”你一定听得多吧？编程是一种创造性的活动，而人的构思总是有缺陷的，因此总会有bug。即使单个任务万无一失，在大型项目中，多个任务的组装不一定就那么顺利，使得一切正常的概率变得非常小。
人月
在软件工程中，成本的确随开发产品的人数和时间的不同，有着很大的变化，但进度却不是如此。因此用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。无论多少个母亲，孕育一个生命都需要十个月。而对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。
沟通的负担来自于两个部分，培训和相互交流。每个成员需要进行技术、项目目标以及总体策略上的培训。一对一交流的情况下，三个人的工作量是两个人的三倍，四个人则是两个人的六倍。而对于需要在三四个人之间召开会议、进行协商、一同解决的问题，情况会更加恶劣。
对于进度安排，一个经验法则是，30%的时间用来做计划，20%的时间用来编码，25%+25%的时间用来做构建测试+系统测试。也就是说，测试至少占一半的时间。
缺乏合理的时间进度是造成项目滞后的主要原因，而向进度落后的项目中增加人手，只会使进度更加落后。