在本書的第二章節——人月神話中，作者有提到關于程式設計時間的問題，大體上是這麼說的：項目之是以延期，排在第一位的原因是因為缺乏合理的進度安排，而且列舉了會導緻進度安排不合理的原因，其中大部分都是人為因素或者觀念以及概念上的問題，例如估算盲目自信、遭受到外部壓力、不重視測試環節或者對程式設計工作量沒有清晰的認識等等。
傳送門：
程式設計領域必讀經典《人月神話》（P2）錯誤的進度估計開篇
在第八章作者就對這些問題進行了後續的探讨，開篇的時候引用了兩句諺語，第一句說：實踐是最好的老師，第二句說：實踐是最好的老師，但傻瓜才從不向别人學習。意思就是說科學的進度估計是來自實踐的，而且這種實踐是可以整個行業互相學習的。
程式設計領域必讀經典《人月神話》（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千行/人-年
其實上面的案例什麼意思不重要，因為距離現在太遙遠，總之：
- 對于常用的程式設計語言，生産率似乎是固定的
- 使用适當的進階語言，程式設計的生産率可以提高5倍