人月神話（四）：為什麼軟體開發不能講民主？

這篇〈貴族專制、民主政治與系統設計〉標題看起來很硬，充滿了 70 年代的古早味，但它其實探討了軟體開發中一個非常核心、甚至有點政治不正確的觀點：「民主」在設計系統時是行不通的。

這一章的核心邏輯，其實用現代開發的角度來看意外地精準。

核心重點

這是整本書最重要的概念之一。作者認為一個系統如果要好用，必須像是「由同一個人設計出來的」。

試想一下，如果十個工程師每個人都把自己覺得很酷的功能加進去，這個軟體最後就會變成一個四不像的縫合怪。使用者會覺得很混亂，因為 A 功能的操作邏輯和 B 功能完全不同。

所以作者主張：與其要一個擁有大量好點子但混亂的系統，不如要一個設計統一但功能普通的系統。

如核心重點所陳述，作者提出了一個很極端的解法：設計權必須掌握在極少數人手裡，也就是所謂的貴族專制。

這會引發一個很大的矛盾：

貴族（架構師）：負責決定系統長什麼樣子、做什麼事。

平民（實作者）：只能決定怎麼做出來，不能決定要做什麼。

這聽起來超像慣老闆在壓榨員工對吧？讀者讀到這裡通常會很不爽，覺得自己變成了寫 Code 的機器，沒有創意空間。所以作者花了很多篇幅在解釋為什麼這不是壞事。

這一章提到的角色與衝突，完全可以對應到現代軟體開發的常見職位。

作者所謂的架構師，其實就是現在負責寫 PRD 和定義 API 介面的 PM 或技術主管。他的工作是對使用者負責，告訴工程師使用者看到的是什麼。產品的規格不能讓工程師一人一句投票決定，必須由少數人拍板定案，產品才會有靈魂。

而實作者就是軟體工程師。我們的工作是對機器負責，想辦法把規格用最高效、最穩定的程式碼寫出來。

這章最難懂也最精彩的地方，在於安撫工程師的論點。

首先，「怎麼做」其實比「做什麼」更難。架構師雖然決定了要蓋一座橋，但工程師要決定怎麼在不倒塌的情況下把橋蓋起來。技術實作本身的創意空間是非常巨大的，不需要去搶設計產品的創意。

其次，規格定死了，反而比較好做事。

如果你是工程師，應該遇過需求一直變的狀況。作者認為，架構師把規格定得越死，工程師反而越自由。因為你可以專心鑽研技術，不用擔心明天 PM 又改需求。

這章其實是在講分工的哲學。

軟體設計拒絕民主，為了讓軟體好用，產品規格必須由極少數人獨裁決定，才能保證風格統一。但工程師的創意應該發揮在「如何優雅地實現功能」，而不是去改動產品設計。

簡單來說：PM 把需求講清楚，不要讓工程師猜；工程師把 Code 寫漂亮，不要去亂改需求。這才是效率最高的開發模式。