1999 Frederick Brooks —— 「沒有銀彈」的軟體本質論#

「他管理了 IBM System/360 這個史上最龐大的硬體+軟體專案，然後寫了一本關於專案為什麼會遲到的書。五十年來，沒有人能推翻他的結論。」

案件檔案#

項目	內容
得主	Frederick P. Brooks, Jr. (1931–2022)
得獎理由	電腦架構、作業系統與軟體工程的里程碑貢獻（System/360 與 OS/360）
關鍵詞	System/360、《人月神話》、本質複雜性

1960s 初，IBM 面臨產品線爆炸：1401、7090、Stretch…… 每台機器各有指令集、各有 OS，客戶換機即重寫一切。謎題：如何用一套架構統治所有價位與規模的機器？

決策：全系列共用同一指令集架構（ISA）與字元編碼（EBCDIC）
低階機器微程式模擬高階指令（Wilkes 1967 案的微碼思想）
「家族」概念誕生：今天的 x86/ARM 家族即其直系

代價：OS/360 有 5000 人年投入、數千件錯誤報告。Brooks 後自嘲：「把熊掉進陷阱裡的是我。」此痛催生《人月神話》（1975）。

為延誤的專案增加人手，只會更加延誤。

推理鏈：溝通成本 = n(n−1)/2 條通道，隨人數平方增長；而培訓新人的成本由老人支付 → 邊際產出遞減為負。

軟體的困難分兩層：

層	性質	能否消除
本質（essence）	問題概念結構的複雜性、不可見性、可變性	不可
偶然（accident）	工具、語法、平台造成的摩擦	可（且已被大幅消除）

高階語言、IDE、OO 已把偶然複雜性削掉大半，進步空間只剩本質部分——故無單一技術能帶來數量級提升。 40 年後的檢驗：敏捷、微服務、AI 輔助編程皆改善「協調」與「偶然」，本質複雜性依舊。

Brooks 的深層貢獻是把管理問題數學化：

生產力 P ≈ f(個體能力) / g(n²) 溝通項
概念完整性 > 功能完整性 → 「外科手術團隊」組織模式
「概念完整性」應由單一設計心智擁有（architect 制）

與 Dijkstra（1972 案）、Wirth（1984 案）同屬「複雜性是頭號敵人」陣營，但 Brooks 把戰場放在組織與人。