巴別塔為什麼失敗？

巴別塔的教訓#

巴別塔擁有一切成功的條件：明確的目標、充足的人力、充裕的材料、足夠的時間，甚至當時最好的技術。然而它仍然失敗了。為什麼？因為溝通崩潰——人們無法彼此交談，無法協調行動，整個計畫因此瓦解。

Brooks 以這個聖經故事作為隱喻，指出大型軟體專案失敗的根本原因往往不是技術問題，而是溝通問題。當團隊規模增長時，溝通路徑呈指數級增加，若缺乏有效的溝通機制，專案就會像巴別塔一樣分崩離析。

大型程式設計專案失敗的最常見原因，既非時程不足，也非技術不行，而是團隊成員之間缺乏有效的溝通。

Brooks 提出專案工作手冊（Project Workbook）作為溝通的核心工具。這是一個正式的文件庫，包含專案中所有重要的文件和決策記錄。每位團隊成員都應該能夠存取這份工作手冊。

工作手冊應具備以下特性：

在 Brooks 的時代，他們使用微縮膠片（microfiche）來分發工作手冊；在今天，我們有 Wiki、共享文件平台和版本控制系統來實現同樣的目的。工具變了，原則不變。

工作手冊的價值不僅在於「記錄」，更在於「共享」。每個人都能看到其他人的工作進展和設計決策，才能真正避免巴別塔的悲劇。

Brooks 引用了 Melvin Conway 的洞察，後來被稱為康威定律（Conway’s Law）：

「設計系統的組織，其產出的設計等同於該組織的溝通結構。」

這意味著組織架構不僅影響管理效率，更直接決定了軟體系統的架構。如果三個團隊分別負責編譯器的三個部分，你最終會得到一個三階段的編譯器——不是因為這是最佳設計，而是因為這反映了組織的溝通結構。

因此，組織架構本身就是一個設計決策。管理者在決定團隊分工時，實際上也在決定系統的模組劃分。

David Parnas 提出了一個當時頗為激進的觀點：團隊成員不應該看到彼此的程式碼。每個模組應該隱藏在精確定義的介面（interface）背後，只暴露必要的功能。

Brooks 承認這個想法乍看之下違反了「充分溝通」的原則，但他逐漸認識到其中的智慧：

溝通的目的不是讓每個人知道一切，而是讓每個人知道他們需要知道的事情。Parnas 的資訊隱藏原則與 Brooks 的充分溝通原則並不矛盾——兩者共同定義了「正確的溝通邊界」。

Brooks 指出，大型專案需要兩種不同的領導角色：

專注於管理面：時程規劃、資源調配、對外溝通、行政事務。製作人確保團隊有足夠的資源，並在正確的軌道上前進。

專注於設計面：架構決策、技術方向、設計的概念完整性。技術總監確保系統在技術上是一致且優雅的。

這兩個角色都不可或缺，但可以有不同的組合方式：

選擇哪種組織結構不應取決於理論偏好，而應取決於可用的人才。組織結構應該配合人的特質，而非反過來要求人去適應結構。