在本书的第二章节——人月神话中，作者有提到关于编程时间的问题，大体上是这么说的：项目之所以延期，排在第一位的原因是因为缺乏合理的进度安排，而且列举了会导致进度安排不合理的原因，其中大部分都是人为因素或者观念以及概念上的问题，例如估算盲目自信、遭受到外部压力、不重视测试环节或者对编程工作量没有清晰的认识等等。
开篇
在第八章作者就对这些问题进行了后续的探讨，开篇的时候引用了两句谚语，第一句说：实践是最好的老师，第二句说：实践是最好的老师，但傻瓜才从不向别人学习。意思就是说科学的进度估计是来自实践的，而且这种实践是可以整个行业相互学习的。
编程领域必读经典《人月神话》（P9）时间估算
之前提到过作者推荐的时间配比是：1/3计划，1/6编码，1/4组件测试，1/4系统测试，但是有两点需要特别说明的。
首先，在学习案例经验的时候不能以编码时间占1/6来倒推出整体时间，比如案例里说编码用了1个月是推不出总体用时6个月的。还有另一种情况就是独立小型程序的案例数据可能不适用于系统的产品，这就像不能通过统计百米短跑纪录得出人类可以在3分钟内跑完一英里的结论一样。
其实编码1个月，总周期是可能大于6个月的，因为书中作者提出了编程总体工作量和程序规模之间显示出的关系是指数关系，指数值在1.05到1.2之间。也就是随着程序规模的增加，编程工作量的增长量也会增长。
案例
书中总共提到了5个案例，分别是：
- Portman的ICL数据显示，相对于其他活动，全职的编程人员仅将50%的时间用于编程和调试
- IBM的数据显示，生产率是系统各个部分交叉的函数，范围在1.5K行/人-年到10K行/人-年
- Bell实验室数据显示，对于已经完成的产品，操作系统类的生产率为0.6K行/人-年，编译类工作的生产率为2.2K行/人-年
- Brooks的OS/360数据与Bell实验室相同
- MIT项目数据显示，在操作系统和编译器混合类型上的生产率为1.2千行/人-年
编程领域必读经典《人月神话》（P9）时间估算
其实上面的案例什么意思不重要，因为距离现在太遥远，总之：
对于常用的编程语言，生产率似乎是固定的
使用适当的高级语言，编程的生产率可以提高5倍
