背景

這篇討論源於《程式員的悖論》（The Programmer's Paradox）部落格的一篇文章，探討在構建大型複雜系統時，究竟應該採取「由下而上」的漸進式演化，還是「由上而下」的預先規格設計。文章引發了開發者對於系統思考（Systems Thinking）在軟體工程中實際應用與限制的深度對話。

社群觀點

在 Hacker News 的討論中，許多開發者引用了「蓋爾定律」（Gall's Law）來支持演化式開發，即所有運作良好的複雜系統，必然是從運作良好的簡單系統演化而來；從零開始設計的複雜系統幾乎註定失敗。支持者認為，軟體需求並非一成不變，隨著時間推移，不僅用戶需求會產生偏移，開發者對問題領域的理解也會不斷深化。這種「發現」的過程使得預先規劃的大型規格書往往在實施前就已過時。此外，演化式開發在心理層面上更具吸引力，因為它能減少無休止的會議與規格爭論，讓工程師能更早進入實作並獲得反饋。

然而，另一派觀點則對過度依賴演化提出了警示。有留言指出，軟體與土木工程不同，人們常誤以為可以將一間小木屋逐步「演化」成摩天大樓，但若基礎設施（Foundation）最初不是為了摩天大樓設計的，這種嘗試最終只會導致難以維護的混亂。部分資深工程師強調，某些系統的複雜性是內在且不可簡化的，例如飛行控制系統或大規模數據基礎設施，這些領域需要極高程度的預先系統思考與主動穩定設計，而非僅靠修補。他們認為，軟體之所以品質低劣，往往是因為管理層不願投入資源建立穩固的架構基礎，導致「臨時方案」變成了永久的負債。

有趣的是，AI 的興起為這場爭論帶來了新的維度。有觀點預測，未來的軟體開發可能會轉向「以規格為中心」的模式。在這種願景中，規格書不再是死板的文檔，而是高知識密度的定義，AI 可以根據這些規格自動生成或迭代實作。這可能打破「規格 vs. 實作」的二元對立，讓開發者能像處理程式碼一樣對規格進行版本控制與合併請求。

最後，社群也達成了一種務實的共識：現實中的專案往往處於這兩種極端之間。成功的系統設計取決於開發者對未來變化的預見能力。當需求高度不確定時，演化是生存之道；但當涉及核心架構與性能極限時，缺乏系統性的預先思考將導致災難。正如一位留言者所言，軟體開發最難的部分不在於寫程式，而是在於透過溝通釐清「究竟該寫什麼」，這正是系統思考的核心價值所在。

延伸閱讀

• Gall's Law: 出自 John Gall 的著作《Systemantics》，探討複雜系統的演化規律。
• How Complex Systems Fail: Richard I. Cook 博士的研究，分析複雜系統的脆弱性與失效模式。
• The Second-System Effect: 出自《人月神話》，描述在成功的第一個系統後，設計者往往因過度野心而導致第二個系統失敗的現象。
• TLA+: 一種用於建模與驗證系統規格的正式規格語言，討論中提到其「細化」（Refinement）概念。
• Iceberg Spec: 作為「規格先行」實踐的案例，展示社群如何先就數據存儲規格達成共識再進行實作。