沒有銀彈

《沒有銀彈：軟體工程的本質性與附屬性工作》（英語：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（因為附屬性工作變成0），此時我們可以說，軟體工作開發的輕鬆程度提升了一個數量級（因為由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的理念才是比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]