《人月神話》的主張：是真是假？

一場自我審判#

在這一章中，Brooks 做了一件大膽的事：他從原書前十五章中逐一提取每個主要論點，然後以二十年的後見之明來評判它們是真是假。這不僅是一份誠實的自我檢討，更是一份極為精煉的全書摘要。

本章的價值不僅在於回顧，更在於它提供了一份濃縮版的《人月神話》——每個核心論點都被清楚地陳述、歸類、並加以評價。

最廣為人知的論點——「在一個已經延遲的專案上增加人力，只會讓它更加延遲」——在二十年後依然顛撲不破。新成員需要訓練時間，溝通路徑以人數的平方增長，而工作的分割與整合本身就耗費巨大的心力。

Brooks 確認，無數的產業實例持續驗證這個定律。即使到了 1995 年，管理者在專案陷入危機時仍然本能地想加人——而結果幾乎總是更糟。

Brooks 對概念完整性（Conceptual Integrity）的堅持從未動搖。他認為這是系統設計中最重要的考量——一個系統必須反映出一個（或極少數幾個）統一的設計理念，而非多個設計者各自想法的拼湊。

Brooks 在回顧中甚至加強了這個論點：概念完整性不僅重要，而且是成功系統的首要條件。無論團隊多大、技術多先進，缺乏概念完整性的系統終將成為不可維護的怪物。

第二系統效應（Second-System Effect）——設計者在第二個系統中傾向於過度設計，塞入所有在第一個系統中被省略的功能——在二十年後依然是真實的陷阱。Brooks 指出，這個效應在大型組織中尤其明顯。

系統需要一位（或一小群）架構師來維護概念完整性。架構師負責定義使用者可見的介面，而將實作細節留給建造者。這個論點不僅成立，而且在更大規模的系統中更加重要。

這是 Brooks 修正幅度最大的論點。原始的主張是：

「計畫丟掉一個吧；反正你終究會這麼做。」

二十年後，Brooks 認為這個建議過於簡化。正確的做法不是建一個再丟掉，而是採用漸進式開發——從一個可運行的小系統開始，逐步擴充與改進。

Brooks 明確表示：瀑布模型是錯誤的。不應該先完整設計、再完整建造、再完整測試。軟體應該像有機體一樣生長，而非像建築一樣搭建。

Brooks 在第三章提出的外科手術團隊概念——一位首席程式設計師搭配多達十種支援角色——其核心理念依然正確：小團隊、一位主要設計者、充分的支援。然而，具體的十種角色配置已經過時。到了 1995 年，許多支援角色已被工具和環境取代。

Brooks 保留了核心原則：最好的軟體來自一兩位傑出設計者的頭腦，而非大型團隊的集體努力。但組織這些設計者的具體方式需要與時俱進。

Brooks 關於文件的原則——每個專案都需要一組關鍵文件，而管理者應該透過文件來追蹤進度——在精神上依然正確。然而，具體的文件格式、工具和流程已經完全改變。紙本文件被電子文件取代，版本控制系統改變了追蹤方式，而敏捷方法論甚至挑戰了某些文件的必要性。

Brooks 誠實地承認，某些論點已經被技術的進步所超越：

Brooks 的自我審視揭示了一個重要模式：原則層面的論點（如 Brooks 定律、概念完整性）經受住了時間考驗，而實作層面的建議（如具體工具、角色配置）則需要隨時代更新。這提醒我們，閱讀經典著作時應該關注其背後的原則，而非表面的細節。

Brooks 的總結評估是樂觀的：原書中大多數核心論點都經受住了考驗。軟體工程的根本挑戰——人的溝通、概念的複雜性、團隊的協調——並未因為硬體更快或語言更好而消失。

這些挑戰是人的問題，不是技術問題。而人的本質在二十年間並未改變。