沒有銀彈

《沒有銀彈：軟體工程的本質性與附屬性工作》（No Silver Bullet—Essence and Accidents of Software Engineering）是IBM大型電腦之父佛瑞德·布魯克斯發表的一篇軟體工程論文。這篇文章最早是他在1986年都柏林IFIP研討會的受邀論文。隔年，電機電子工程師學會《Computer》也轉載了這篇文章，並配上《倫敦狼人》等電影劇照作為說明，同時加入〈終結狼人〉的附註，帶出「只有銀彈才能解決問題」的現代寓意。文章強調，軟體的複雜性是本質性的，因此真正的銀彈並不存在；所謂「沒有銀彈」，指的是沒有任何單一技術或方法，能在十年內讓軟體工程生產力提升十倍。

## 摘要

所有軟體開發都包含本質性工作（essential task）和附屬性工作（accidental task）。前者是建立由抽象軟體實體構成的複雜概念結構，後者則是用程式語言把這些抽象實體實作出來，並在空間與速度限制下，將程式對應到機器語言。

如果附屬性工作占比不到全部工作的9/10，那麼即使把附屬性工作完全消除，也無法讓整體開發效率提升一個數量級。過去軟體生產力的大幅進步，多半來自移除人為障礙，例如嚴苛的硬體限制、難用的程式語言，以及上機時間（machine time）不足等，這些因素都會讓附屬性工作變得更困難。

## 問題之所在－銀彈與軟體專案

佛瑞德·布魯克斯在《沒有銀彈》中寫道：

在民俗傳說裡，狼人是最令人恐懼的怪物之一，因為牠們會突然從一般人變成可怕的怪獸，所以人們一直想找到能一槍解決狼人的銀彈。

軟體專案也常有類似情況（尤其從不懂技術的管理者角度來看）：平時看起來單純，卻可能很快變成時程延誤、預算超支、品質不佳的怪獸。因此，人們總希望有一種銀彈，能像硬體成本快速下降那樣，有效降低軟體開發成本。

但我們預期，從現在起十年內不會出現任何銀彈。無論是技術或管理，都不會有某個單一重大突破，能保證在生產力、可靠度或簡潔性上帶來一個數量級的改善。

不過，這種懷疑不等於悲觀。雖然不會有單一重大突破（而且這也不符合軟體本質），仍有許多值得期待的創新正在發展。只要持續推進、擴散並善用這些做法，整體上仍可能達到一個數量級的進展。捷徑沒有，但穩定累積會有效果。

人類克服疾病的第一步，是用細菌說（germ theory）取代惡魔說（demon theory）與體液說（humours theory）。這讓人們放下對奇蹟解法的期待，改為靠按部就班的衛生改進與習慣養成來推動進步。軟體工程面對的情況也是如此。

《沒有銀彈》主張，在未來十年內（自1986年發表起算），不會有任何單一軟體工程突破，能讓程式設計生產力提升一個數量級。不過，作者後來認為這個假設已不再成立。

假設軟體開發總工作量為10，其中本質性工作占1、附屬性工作占9。若能完全消除附屬性工作，總工作量就會降到1，此時可視為開發效率提升一個數量級（由10降到1，即10倍差距）。

## 軟體開發的困難

布魯克斯把軟體開發的困難分成兩類。這篇論文的核心觀點是：複雜的軟體工程問題無法用單一簡單方法解決。他認為軟體開發真正的難點在概念架構的規格制定、設計與測試，而不是表達方式本身，或對表達方式的精確檢驗。

- 本質性（essence）：軟體在概念（conceptual）建構上的先天困難，也就是如何從抽象問題發展出具體解法。
- 附屬性（accident）：把概念構想實作到電腦上時遇到的困難。

布魯克斯指出，附屬性（accident）和附屬的（accidental）常被混用。這個詞源自亞里斯多德的古老用法。在這裡，accidental不是指「偶然發生」或「意外不幸」，而是更接近「伴隨的」或「次要的」。

### 造成本質性困難的原因

布魯克斯認為，附屬性困難會隨著工具改進而逐步減少，但本質性困難最難解決，因為大部分工作都在人的思考過程中進行，能直接幫上忙的工具有限。他列出以下幾項：

- 複雜性（complexity）：軟體要處理的問題通常牽涉到計算步驟，這是一種人為的、抽象的智能活動，本身就很複雜。
- 隱匿性（invisibility）：還沒做完的軟體看不見，就算用圖示來說明，也常常沒辦法把結構講清楚，造成溝通上的困難。
- 配合性（conformity）：在大型軟體裡，各個子系統的介面必須互相配合。但隨著時間和環境變化，要一直保持一致並不容易。
- 易變性（changeability）：軟體運作的環境包含人、法規、硬體、應用領域等等，這些因素都會不斷變化。

### 過去的突破解決了附屬性的困難

#### 高階語言

高階語言的主要作用，是讓程式不必被大量底層細節綁住。抽象程式關心的是函式、資料型別、執行順序、訊息傳遞等概念；但機器碼實際處理的是位元、暫存器、條件、分支、通道、磁碟等底層元素。高階語言把程式需要的概念具體化，同時隔離底層細節，等於移除了與程式本質無關的一層複雜性。

#### 分時技術

分時（time-sharing）技術解決的是即時回應問題。有了分時，系統互動更連續，開發者在思考時較能維持對整體脈絡的掌握。分時技術的效益也有上限：它主要改善系統反應時間，當反應時間短到人類幾乎無感（約十分之一秒）後，再加速的實際差異就不大。

#### 統一的開發環境

Unix和Interlisp是最早被廣泛使用的整合軟體開發環境，普遍被認為讓生產力提升數倍。它們處理附屬性難題的方式，是透過完整程式庫、統一檔案格式、管道（pipe）和過濾器 (Unix)（filter）等機制提升軟體可共用性。概念上的構造因此更容易被呼叫、傳遞或套用到其他場景。這項突破後來也推動了工具軟體發展，因為新工具只要遵守標準規格，就能用在多種程式上。

## 尋找銀彈

Ada和其他高階語言的進展

程式語言Ada是1980年代的通用型高階語言。Ada不僅反映了語言概念的演進，也實作了多項支持現代設計與模組化的特徵。相較於語言本身，Ada更被重視的是其設計理念：模組化（modularity）、抽象資料型別（abstract data type）、階層式結構（hierarchical structure）。

物件導向程式設計

相較於當時其他流行技術，物件導向程式設計（object-oriented programming）被許多軟體工程研究者寄予更高期待，達特茅斯學院的Mark Sherman指出，有兩個不同的概念我們必須小心地加以分辨，從名稱上就可以看出這兩個概念的不同：抽象資料型別和階層式型別。後者也被稱為類別（class）。所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏起來的，例如Ada的包裹（package，使用私有型別）或Modula的模組（module）。

- 人工智慧
- 專家系統
- 自動化程式設計
- 視覺化或圖形化程式設計
- 軟體的驗證
- 環境與工具
- 工作站

## 評價迴響

雖然《人月神話》引發許多討論，但爭議相對較少；《沒有銀彈》則引來更多反對意見，包括寄給期刊主編的信件，以及後續持續出現的書函與短評，其中相當一部分都在反駁「不會有任何特效藥」的主張。

1990年，Brad Cox發表〈銀彈存在〉（"There Is a Silver Bullet"），主張可用可再利用（reusable）、可替換組件的方法來處理概念本質性的問題。Glass、Vessey和Conger在1992年的論文中指出，有充分證據顯示，關於銀彈這類議題的研究仍未停止。

### Harel的分析

David Harel在1992年的一篇文獻《緊咬銀彈》（"Biting the Silver Bullet"

）中，對《沒有銀彈》做了細緻分析。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟體面面觀》都寫得過於悲觀，因此嘗試補充較正向的一面，並在副標題中提出「讓系統開發走向一個光明的未來」。

就Harel的認知，他認為造成《沒有銀彈》悲觀的原因有三點：

- 本質性和附屬性的二分法。
- 對每一個可能的銀彈採取個別單獨評論的方式。
- 只預測10年，這對「預期任何重大的突破」而言，並沒有足夠長的時間。

Harel還提出一項假想實驗：假設《沒有銀彈》的主張不變，但發表時間改為1952年而非1986年。他使用歸謬法（reducto ad absurdum），反駁從附屬性中硬性切分出本質性的做法。

### Jones的觀點

Caper Jones曾提出一個重要觀點，最早出現在一系列非正式紀錄中，後來收錄於書中，也被數位與布魯克斯通信的人提及。《沒有銀彈》和多數論文一樣，把焦點放在生產力，也就是每單位軟體輸入成本能產生多少輸出。Jones則主張：「把重點放在品質上，生產力會隨之而來」。他認為，凡是成本過高、時程落後的專案，都會把大量額外時間花在找出並修正規格、設計與實作錯誤上。Jones也提出資料顯示，缺乏系統化品質控制，與時程延誤災難之間有強烈相關性。

Caper Jones認為，若兩份同等的Cobol程式都花10年編寫，但其中一份採用結構化方法、另一份沒有，最終效果可相差3倍。

## 外部連結

- No Silver Bullet: Essence and Accidents of Software Engineering, by Frederick P. Brooks, Jr.
- No hay balas de plata: Lo esencial y lo accidental en la Ingeniería del Software, by Frederick P. Brooks, Jr.
- 論銀彈的存在