Frederick Brooks 如何解開大型軟體的複雜度？OS/360、《人月神話》與工程管理

先講結論：Frederick Brooks 從 System/360、OS/360 與《人月神話》的經驗說明，大型軟體的核心成本不只在寫程式，也在需求、架構、溝通、整合與不可削減的複雜度；人力、工具或 AI 不能自動消除問題本身的規則與依賴。

Q：Frederick Brooks 主要貢獻是什麼？ A：他參與 IBM System/360、OS/360 與軟體工程研究，並以《人月神話》整理大型專案的架構與管理經驗。

Q：Brooks 定律在說什麼？ A：延遲中的軟體專案再加入人力，通常可能更延遲，因為新人要學習系統，既有成員還要支付協調與整合成本。

Q：為什麼人月不能直接相加？ A：軟體工作有可平行的部分，也有依賴溝通、整合與共同理解的部分；人數增加會增加溝通邊，不是把月數像材料一樣線性切分。

Q：什麼是不可削減的複雜度？ A：它來自問題本身的規則、例外、互動與需求；工具和框架可降低偶然複雜度，卻不會消除領域本身的難題。

Q：OS/360 為什麼重要？ A：它讓大型作業系統的整合、相容性、團隊協作與時程風險具體化，成為理解架構和管理取捨的實際案例。

Q：Brooks 為何強調先處理架構？ A：清楚的概念完整性、介面與整體設計能減少局部決策互相衝突；沒有共同架構，增加人力只會放大整合負擔。

Q：大型軟體最需要管理什麼？ A：除了任務分工，還要管理依賴、介面、版本、測試、文件、決策紀錄、風險與團隊共同心智模型。

Q：這套觀點和今天的 AI／雲端專案如何連結？ A：自動化與 AI 可加速局部產出，但資料契約、系統整合、安全、測試、可觀測性與責任邊界仍需要工程團隊處理。

Q：圖片與文章的關係是什麼？ A：圖片是 Frederick Brooks、OS/360、《人月神話》、溝通成本與大型軟體工程管理的主題路線圖，不是 IBM OS/360 的官方專案文件截圖。

增量補充：Brooks 定律是診斷工具，不是拒絕擴編的口號

Computer History Museum 將 Frederick P. Brooks Jr. 的工作放在電腦架構、作業系統與軟體工程的交會處，這也提醒讀者，《人月神話》不能和他的 System/360、OS/360 經驗切開閱讀。Brooks 定律描述的是延遲、耦合與新人學習成本同時存在時的風險，不是任何團隊、任何階段都不能加人。來源：Computer History Museum — Frederick P. Brooks Jr.。

要把這個判斷用在今天的專案，先檢查工作能否平行、介面是否穩定、培訓是否有文件與測試支援，再估算新增人力帶來的協作邊與可交付工作。若新增人力只增加同步會議，速度可能下降；若工作已被清楚切分且整合自動化，擴編才較可能轉成吞吐量。

先講結論

Frederick Brooks 把大型軟體的複雜度、溝通成本與架構決策變成可檢驗的工程問題。System/360 與《人月神話》是這套方法的代表。

Frederick Brooks 是誰？

Brooks 是美國電腦科學家，曾在 IBM 參與 Stretch、Harvest 與 System/360，也在 University of North Carolina at Chapel Hill 創立電腦科學系。Computer History Museum 將他的貢獻概括為電腦架構、作業系統與軟體工程；ACM 的 Turing Award 資料則把他 1999 年獲獎理由寫成這三個領域的重大貢獻。

IBM System/360 教會了他什麼？

System/360 不只是一次硬體換代，而是要讓一整個家族的電腦共用軟體與相容性承諾。Brooks 在 IBM 擔任專案管理與架構角色時，必須同時處理硬體、作業系統、工具、時程和大量工程師之間的依賴。

Computer History Museum 的資料指出，當時 OS/360 有超過 1,000 名程式設計師參與。這種規模讓「多找幾個人」不再等於線性增加產能：新人需要理解架構、介面、工具與既有決策，原有成員還要花時間教學與協調。

《人月神話》真正談的是什麼？

1. 人月不是可任意相加的單位

一個月的時間和一個人的工作量，不能直接交換。軟體工作有不可平行化的依賴，也有溝通邊界；當人數增加，溝通路徑和整合負擔也會增加。

2. Brooks’s Law 是條件式判斷

「Adding manpower to a late software project makes it later」不是所有專案的物理定律。它描述的是已經延遲、工作高度耦合、又需要大量新人熟悉系統的情境。若任務可平行、介面穩定、訓練成本低，增加人力可能有效；但不能用一句格言取代專案診斷。

3. 概念完整性比功能堆疊更重要

Brooks 強調系統設計需要一個一致的概念結構，讓使用者和開發者能理解整體行為。架構師的工作不是把所有功能都塞進核心，而是維持少數關鍵概念的清晰，再把可變部分放到適合的邊界。

4. 沒有銀色子彈

《No Silver Bullet》把軟體問題區分成 essential complexity 與 accidental complexity：前者來自問題本身，後者來自語言、工具、流程與實作環境。新工具可以降低偶然複雜度，但不會讓需求衝突、領域規則或系統邊界自動消失。

這套思想如何對應現代工程？

今天的敏捷、持續交付、微服務與平台工程，都在處理 Brooks 描述的幾個問題：如何縮小協作邊界、讓變更可觀察、把架構決策寫清楚，以及降低新人加入的認知成本。它們不是對 Brooks 的單一答案，而是不同組織在不同約束下的工程取捨。

例如微服務可能降低團隊間的部署耦合，卻也增加分散式系統、觀測、資料一致性與運維成本。引用 Brooks 時，應同時說明它適用的複雜度來源，而不是把「加人會更慢」當成反對所有擴編的口號。

常見問題

Brooks’s Law 是什麼？

它指「把人力加入已經延遲的軟體專案，可能使專案更晚完成」。原因是新人需要訓練，既有成員要投入協作，且許多工作無法完全平行。

Frederick Brooks 只研究軟體管理嗎？

不是。他也參與 IBM System/360 等電腦架構與作業系統工作，並在 University of North Carolina 研究互動 3D 圖形與虛擬實境。把他縮成管理格言作者會漏掉架構與人機互動的部分。

《人月神話》是否反對敏捷或加人？

不是。它提醒團隊辨識工作依賴、概念完整性與溝通成本；實際是否擴編，仍要看任務可平行程度、系統邊界和新人的學習曲線。

時間線

1956：Brooks 取得 Harvard 電腦科學博士學位後加入 IBM。
1961–1965：參與 IBM System/360 的架構與專案工作。
1964：加入 University of North Carolina，創立電腦科學系。
1975：出版《The Mythical Man-Month》初版。
1986：發表〈No Silver Bullet〉，後收錄於相關論述。
1999：獲 ACM Turing Award。
2022：逝世。

Frederick Brooks 如何解開大型軟體的複雜度？OS/360、《人月神話》與工程管理