本书第一章提到，过去几十年的大型系统开发犹如一个焦油坑，很多大型和强壮的动物在其中剧烈挣扎。各种问题纠结在一起，团队的行动越来越慢。他们大多开发出了可运行的系统，但只有极少数的项目满足了目标。
究其原因，首先，我们对估算技术缺乏有效的研究，总是假设“一切都将运作良好”，但事实往往不是这样，在我们编程的时候也从中了解，不经测试一下子写100或1000行代码不出错的概率几乎为零，同样在大型项目里，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于零。因此我们的乐观主义并不应该是理所应当的，这要求我们对项目时间估算要更加谨慎。
我们采用的估算技术（使用工作量单位：人月）隐含地假设人和月可以互换，错误地将进度与工作量相互混淆，那也许真得就是一个“人月神话”。人数和时间的互换，仅仅适用于任务可以任意分解的情况，这在系统编程中几乎是不可能的，一个软件如果被分成若干个子程序，它们之间必定有关联，有次序关系。于是在添加人手时，并不等于平均分配了时间，因为他们之间还要为了将各自模块组成软件进行交流，在这种情况下，人员和时间的关系并不是线性关系，如图所示。
对进度缺少跟踪和监督，也是导致项目时间延长的原因之一。关于任务进度的安排，有如下经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
感谢作者分享的多年经验