没有银弹

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

摘要

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

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

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

佛瑞德·布魯克斯在《沒有銀彈》^[4]^{[註 3]}中寫道：

在民俗傳說裡，狼人是最令人恐懼的怪物之一，因為牠們會突然從一般人變成可怕的怪獸，所以人們一直想找到能一槍解決狼人的銀彈。
軟體專案也常有類似情況（尤其從不懂技術的管理者角度來看）：平時看起來單純，卻可能很快變成時程延誤、預算超支、品質不佳的怪獸。因此，人們總希望有一種銀彈，能像硬體成本快速下降那樣，有效降低軟體開發成本。
但我們預期，從現在起十年內不會出現任何銀彈。無論是技術或管理，都不會有某個單一重大突破，能保證在生產力、可靠度或簡潔性上帶來一個數量級的改善。
不過，這種懷疑不等於悲觀。雖然不會有單一重大突破（而且這也不符合軟體本質），仍有許多值得期待的創新正在發展。只要持續推進、擴散並善用這些做法，整體上仍可能達到一個數量級的進展。捷徑沒有，但穩定累積會有效果。
人類克服疾病的第一步，是用細菌說（germ theory）^{[註 4]}取代惡魔說（demon theory）^{[註 5]}與體液說（humours theory）^{[註 6]}。這讓人們放下對奇蹟解法的期待，改為靠按部就班的衛生改進與習慣養成來推動進步。軟體工程面對的情況也是如此。

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

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

軟體開發的困難

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

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

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

造成本質性困難的原因

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

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

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

高階語言

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

分時技術

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

統一的開發環境

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

尋找銀彈

Ada和其他高階語言的進展

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

物件導向程式設計

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

評價迴響

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

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

Harel的分析

David Harel在1992年的一篇文獻《緊咬銀彈》（"Biting the Silver Bullet" ）^[12]中，對《沒有銀彈》做了細緻分析^[13]。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟體面面觀》^[14]都寫得過於悲觀，因此嘗試補充較正向的一面，並在副標題中提出「讓系統開發走向一個光明的未來」。

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

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

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

Jones的觀點

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

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

注释

^ 歐美古老傳說中使用銀子彈（silver bullet）可以殺死吸血鬼、狼人或怪獸；銀子彈引申為解決問題的有效方法。
^ 這篇標題為〈沒有銀彈〉的文章出自於Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, pp.1069-76.由H. J. Kugler所編輯。
^ 編者錢一一譯註：傳說在月圓之夜，狼人就會從普通人獸化成狼，變成可怕的怪獸，對付狼人得用銀製的子彈貫穿牠的心臟。為什麼要用銀彈？因為銀被視為與月亮同體，具有法力，所以銀彈是殺死狼人的「必殺技」。
^ 細菌說：由法國微生物學家巴斯德（Louis Pasteur, 1822～1895）開創，發現疾病是由細菌感染而來。
^ 惡魔說：生病是因為惡魔作怪，或者是做錯事，觸怒了惡魔。
^ 體液說：人體流著四種體液，血液（blood）、黏液（phlegm）、膽汁（choler）、黑膽汁（black bile），這四種體液各有不同的屬性，決定了人的性情、脾氣。生病是因為這四種體液的比例不均衡所致。
^ 『根據亞里斯多德（Aristotle）和士林哲學（scholastic philosophy）的說法，附屬性是一種不屬於事物根本或必要的性質，而是其他原因造成的影響才產生出來的性質。』^[5]
^ 有些來信與回應刊登在1987年7月份的IEEE《Computer》。雖然沒有銀彈並未得獎，但Bruce M. Skwiersky對它的評論獲選為1988年《Computer Reviews》的最佳評論，這份獎項以及該評論被公佈並轉載於E. A. Weiss, "Editrial", Computing Reviews(Jun, 1989), pp. 283-284. 評論中得有重大錯誤：「6倍」應該為「10^6」
^ Brad Cox也是軟體工程学的大師級人物，「軟體IC」一詞就是他提出來的。
^ 編者錢一一譯註：「歸謬法」：由q出發，推導出邏輯結果r，如果r是矛盾的，那麼q就被否定掉。

參考文獻

引用

^ IFIP Congress 1986: Dublin, Ireland. [2012-07-08]. （原始内容存档于2012-07-05）.
^ Brooks, F. P.，“No silver bullet—essence and accidents of software engineering,”in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.
^ Brooks, F. P. "No silver bullet—essence and accidents of software engineering", Computer 20, 4 (April, 1987), pp. 10-19.
^ F. P. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering", Computer, Vol. 20, pp. 10-19, 1987.
^ Webster's New International Dictionary of the English Language, 2d ed., Springfield, Mass.: G. C. Merriam, 1960.
^ 鄭炳強. 軟體工程：從實務出發（Software Engineering: A Perspective from Practices）. 智勝文化事業有限公司. 2007. ISBN 978-957-729-659-7.
^ Parnas, D. L.，“Designing software for ease of extension and contraction.”
IEEE Trans. on SE,5,2 (March, 1979), pp. 128-138.
^ Booch, G. Object-oriented design,”in Software Engineering with Ada.
Menlo Park, Calif.: Benjamin/Cummings, 1983.
^ Cox, Brad. No Silver Bullet Revisited. American Programmer Journal. 1995年11月 [2012-07-10]. （原始内容存档于2018-02-28）（英语）. In one of the most influential books of this era, The Mythical Man-month, Dr. Fred Brooks observed that adding more people to a late software project only seems to make matters worse. And in an equally influential article, No Silver Bullet; Essence and Accidents of Software Engineering, he argued that the difficulties are inevitable, arising from software's inescapable essence, as distinct from accident; something we're doing wrong in producing it.
^ Cox, B. J., "There is a silver bullet", Byte (Oct., 1990), pp. 209-218.
^ Glass, R. L., and S. A. Conger，“Research Software tasks: Intellectual or clerical?”Information and Management, 23, 4 (1992), pp. 183-192.
^ Harel, David. Biting the Silver Bullet: Toward Brighter Future for System Development. 1992年 [2012-07-10]. （原始内容存档于2013-05-22）（英语）. This article was triggered by those of Brooks and Parnas. It is not a rebuttal. Indeed, I agree with most of the specific points made in both papers. Instead, the goal of this article is to illuminate the brighter side of the coin, emphasizing developments in the field that were too recent or immature to have influenced Brooks and Parnas when they wrote their manuscripts.
^ Harel, D., "Biting the silver bullet: Toward a brighter future for system development", Computer (Jan., 1992) , pp. 8-20.
^ Parnas, D. L., "Software aspects of strategic defense systems", Communications of the ACM, 28 (12) (Dec., 1985), pp. 1326-1335.
^ Jones, C., Assessment and Control of Software Risks. Englewood Cliffs, N. J.: Prentice-Hall, 1994. p. 619.
^ T.Caper Jones. Assessment and Control of Software Risks. Prentice Hall. 1993-12-17 [2012-07-12]. ISBN 978-0137414062. （原始内容存档于2012-09-04）（英语）.

来源

期刊文章

Brooks, Fred P. No Silver Bullet —Essence and Accident in Software Engineering. Proceedings of the IFIP Tenth World Computing Conference. 1986: 1069–1076.
Brooks, Fred P. No Silver Bullet —Essence and Accidents of Software Engineering. IEEE Computer. April 1987, 20 (4): 10–19.

书籍

Frederick P. Brooks, Jr. 人月神話：軟體專案管理之道. 由錢一一翻译. 臺北市: 經濟新潮社. 2004-04-01 [2012-07-01]. ISBN 986-7889-18-5. （原始内容存档于2013-11-08）（中文（臺灣））.

外部連結

（英文） 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.
（简体中文）论银弹的存在（页面存档备份，存于互联网档案馆）

參見

[4] 歐美古老傳說中使用銀子彈（silver bullet）可以殺死吸血鬼、狼人或怪獸；銀子彈引申為解決問題的有效方法。

[5] 這篇標題為〈沒有銀彈〉的文章出自於Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, pp.1069-76.由H. J. Kugler所編輯。

[7] 編者錢一一譯註：傳說在月圓之夜，狼人就會從普通人獸化成狼，變成可怕的怪獸，對付狼人得用銀製的子彈貫穿牠的心臟。為什麼要用銀彈？因為銀被視為與月亮同體，具有法力，所以銀彈是殺死狼人的「必殺技」。

[8] 細菌說：由法國微生物學家巴斯德（Louis Pasteur, 1822～1895）開創，發現疾病是由細菌感染而來。

[9] 惡魔說：生病是因為惡魔作怪，或者是做錯事，觸怒了惡魔。

[10] 體液說：人體流著四種體液，血液（blood）、黏液（phlegm）、膽汁（choler）、黑膽汁（black bile），這四種體液各有不同的屬性，決定了人的性情、脾氣。生病是因為這四種體液的比例不均衡所致。

[12] 『根據亞里斯多德（Aristotle）和士林哲學（scholastic philosophy）的說法，附屬性是一種不屬於事物根本或必要的性質，而是其他原因造成的影響才產生出來的性質。』^[5]

[16] 有些來信與回應刊登在1987年7月份的IEEE《Computer》。雖然沒有銀彈並未得獎，但Bruce M. Skwiersky對它的評論獲選為1988年《Computer Reviews》的最佳評論，這份獎項以及該評論被公佈並轉載於E. A. Weiss, "Editrial", Computing Reviews(Jun, 1989), pp. 283-284. 評論中得有重大錯誤：「6倍」應該為「10^6」

[17] Brad Cox也是軟體工程学的大師級人物，「軟體IC」一詞就是他提出來的。

[24] 編者錢一一譯註：「歸謬法」：由q出發，推導出邏輯結果r，如果r是矛盾的，那麼q就被否定掉。

[1] IFIP Congress 1986: Dublin, Ireland. [2012-07-08]. （原始内容存档于2012-07-05）.

[2] Brooks, F. P.，“No silver bullet—essence and accidents of software engineering,”in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069-1076.

[3] Brooks, F. P. "No silver bullet—essence and accidents of software engineering", Computer 20, 4 (April, 1987), pp. 10-19.

[6] F. P. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering", Computer, Vol. 20, pp. 10-19, 1987.

[11] Webster's New International Dictionary of the English Language, 2d ed., Springfield, Mass.: G. C. Merriam, 1960.

[13] 鄭炳強. 軟體工程：從實務出發（Software Engineering: A Perspective from Practices）. 智勝文化事業有限公司. 2007. ISBN 978-957-729-659-7.

[14] Parnas, D. L.，“Designing software for ease of extension and contraction.”
IEEE Trans. on SE,5,2 (March, 1979), pp. 128-138.

[15] Booch, G. Object-oriented design,”in Software Engineering with Ada.
Menlo Park, Calif.: Benjamin/Cummings, 1983.

[18] Cox, Brad. No Silver Bullet Revisited. American Programmer Journal. 1995年11月 [2012-07-10]. （原始内容存档于2018-02-28）（英语）. In one of the most influential books of this era, The Mythical Man-month, Dr. Fred Brooks observed that adding more people to a late software project only seems to make matters worse. And in an equally influential article, No Silver Bullet; Essence and Accidents of Software Engineering, he argued that the difficulties are inevitable, arising from software's inescapable essence, as distinct from accident; something we're doing wrong in producing it.

[19] Cox, B. J., "There is a silver bullet", Byte (Oct., 1990), pp. 209-218.

[20] Glass, R. L., and S. A. Conger，“Research Software tasks: Intellectual or clerical?”Information and Management, 23, 4 (1992), pp. 183-192.

[21] Harel, David. Biting the Silver Bullet: Toward Brighter Future for System Development. 1992年 [2012-07-10]. （原始内容存档于2013-05-22）（英语）. This article was triggered by those of Brooks and Parnas. It is not a rebuttal. Indeed, I agree with most of the specific points made in both papers. Instead, the goal of this article is to illuminate the brighter side of the coin, emphasizing developments in the field that were too recent or immature to have influenced Brooks and Parnas when they wrote their manuscripts.

[22] Harel, D., "Biting the silver bullet: Toward a brighter future for system development", Computer (Jan., 1992) , pp. 8-20.

[23] Parnas, D. L., "Software aspects of strategic defense systems", Communications of the ACM, 28 (12) (Dec., 1985), pp. 1326-1335.

[25] Jones, C., Assessment and Control of Software Risks. Englewood Cliffs, N. J.: Prentice-Hall, 1994. p. 619.

[26] T.Caper Jones. Assessment and Control of Software Risks. Prentice Hall. 1993-12-17 [2012-07-12]. ISBN 978-0137414062. （原始内容存档于2012-09-04）（英语）.

[1]

[2]

[3]

[註 1]

[註 2]

[4]

[註 3]

[註 4]

[註 5]

[註 6]

[註 7]

[6]

[7]

[8]

[註 8]

[註 9]

[9]

[10]

[11]

[12]

[13]

[14]

[註 10]

[15]

[16]

[5]