人月神話(The Mythical Man-Month: Essays on Software Engineering)是一本關於“軟件工程”和“項目管理”的書，由Fred Brooks寫於1975。有趣的是，在1995的版本中，作者增加了對自己之前觀點的評價。下面是書中各章節的主要觀點：
1. 焦油坑
- 系統產品的開發工作量是個人產品/構件程序的工作量的9倍。
- 編程行業在於創造，在於學習。
2. 人月神話
- 缺乏合理的時間進度是造成項目滯後的主要原因。
- 關於進度安排，我的經驗是：1/3計劃，1/6編碼，1/4構件測試，1/4系統測試。
- Brook法則：向進度落後的項目增添人手，只會使進度更加落後。
3. 外科手術隊伍
- Sackman、Erikson和Grand：同樣有兩年經驗而且在收到同樣培訓的情況下，優秀的專業程序員的工作效率是較差程序員的10倍。
- 一位首席程序員、類似於外科手術隊伍的團隊架構提供了一種方法——既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
4. 貴族專制、民主政治和系統設計
- “概念完整性是系統設計中最重要的考慮因素”。
- “對於非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。”[同樣適用於小型項目。]
- 體系結構（architecture）、設計實現（implementation）、物理實現（realization）的許多工作可以併發進行。[軟件和硬件設計同樣可以並行。]
5. 畫蛇添足
- 儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。
- 牢記是開發人員承擔創造性的實現責任；結構師只能提出建議。
- 時刻準備着爲所指定的說明建議一種實現的方法，準備接受任何其他可行的方法。
- 爲功能分配一個字節和微秒的優先權值是一個很有價值的規範化方法。（筆者：我覺得這是對彙編編程有效的，高級語言編程請進行類比。）
6. 貫徹執行
- 即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
- 必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。
- “項目經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。”
7. 爲什麼巴比倫塔會失敗
- 巴比倫塔項目的失敗是因爲缺乏交流，以及交流的結果——組織。
- 交流
- 由於對其他人的各種假設，團隊成員之間的理解開始出現偏差。
- 團隊應該以儘可能多的方式進行相互之間的交流：非正式、常規項目會議，會上進行簡要的技術陳述、共享的正式項目工作手冊。
- 組織
- 團隊組織的目標是爲了減少必要的交流和協作量。
- 爲了減少交流，組織結構包括了人力劃分（division of labor）和限定職責範圍（specialization of function）。
- 傳統的樹狀組織結構反映了權力的結構原理——不允許雙重領導。
- 組織中的交流是網狀，而不是樹狀結構，因而所有的特殊組織機制（往往體現成組織結構圖中的虛線部分）都是爲了進行調整，以克服樹狀組織結構中交流缺乏的困難。
8. 胸有成竹
- IBM的Aron數據顯示，生產率是系統各個部分交互的函數，在1.5K千代碼行/人年至10K千代碼行/人年的範圍內變化。
- Harr的Bell實驗室數據顯示對於已完成的產品，操作系統類的生產率大約是0.6KLOC/人年，編譯類工作的生產率大約爲2.2KLOC/人年。
- Brooks的OS/360S數據與Harr的數據一致：操作系統0.6～0.8KLOC/人年，編譯器2～3 KLOC/人年。
9. 削足適履
- 除了運行時間以外，所佔據的內存空間也是主要開銷。特別是對於操作系統，它的很多程序是永久駐留在內存中。
- 規模預算不僅僅在佔據內存方面是明確的，同時還應該指明程序對磁盤的訪問次數。
- 培養開發人員從系統整體出發、面向用戶的態度是軟件編程管理人員最重要的職能。
- 精煉、充分和快速的程序。往往是戰略性突破的結果，而不僅僅技巧上的提高。這種突破常常是一種新型算法。
10. 提綱挈領
- “前提：在一片文件的汪洋中，少數文檔形成了關鍵的樞紐，每個項目管理的工作都圍繞着它們運轉。它們是經理們的主要個人工具。”
- 對於計算機硬件開發項目，關鍵文檔是目標、手冊、進度、預算、組織機構圖、空間分配、以及機器本身的報價、預測和價格。
- 對於軟件項目，要求是相同的：目標、用戶手冊、內部文檔、進度、預算、組織機構圖和工作空間分配。
- 項目經理的主要日常工作是溝通，而不是做出決定；文檔使各項計劃和決策在整個團隊範圍內得到交流。
11. 未雨綢繆
- 系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟。
- 將開發的第一個系統——丟棄原型——發佈給用戶，可以獲得時間，但是它的代價高昂——對於用戶，使用極度痛苦；對於重新開發的人員，分散了精力；對於產品，影響了聲譽，即使最好的再設計也難以挽回名聲。
- 高級語言的使用、編譯時操作、通過引用的聲明整合和自文檔技術能減少變更引起的錯誤。
- 程序維護基本上不同於硬件的維護；它主要由各種變更組成，如修復設計缺陷、新增功能、或者是使用環境或者配置變換引起的調整。
- 所有修改都傾向於破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統退化到不可修復混亂的進程，從中必須要重新進行設計。
12. 干將莫邪
- 同天文工作者一樣，系統調試總是大部分在夜間完成。
- 主程序庫應該被劃分成（1）一系列獨立的私有開發庫；（2）正處在系統測試下的系統集成子庫；（3）發佈版本。正式的分離和進度提供了控制。
- 自頂向下、徹底地開發一個性能仿真裝置。儘可能早地開始這項工作，仔細地聽取“它們表達的意見”。
- 有限的數據表明了系統軟件開發中，交互式編程的生產率至少是原來的兩倍。
13. 整體部分
- V.A.Vyssotsky提出，“許許多多的失敗完全源於那些產品未精確定義的地方。”
- 系統測試期間，一次只添加一個構件。
14. 禍起蕭牆
- “項目是怎樣延遲了整整一年的時間？⋯一次一天。”
- 根據一個嚴格的進度表來控制項目的第一個步驟是制訂進度表，進度表由里程碑和日期組成。
以上就是老司機們對我們的諄諄教導。話說回來，又一個20年(2016)過去了——開源運動如火如荼，各種框架你來我往，摩爾定律開始放緩；下一個20年，又會是在哪兒？