再論《沒有銀彈》 （“No Silver Bullet”Refired）
生死有命，富貴在天
- 威廉三世，奧倫治王子
那些想看到完美方案的人，其實在心底裏就認爲它們以前不存在，以後也不可能出現。
- 亞歷山大·波普，批判散文
Every bullet has its billet.
- WILLIAM III OF ENGLAND, PRINCE OF ORANGE
Whoever thinks a faultless piece to see, thinks what ne’er was, nor e’er shall be.
- ALEXANDER POPE, AN ESSAY ON CRITISIM
人狼和其他恐怖傳說
《沒有銀彈－軟件工程中的根本和次要問題》（第16章）最初是在IFIP’86年都柏林大會的約稿，接着在一系列的刊物上發表1。《計算機》雜誌上翻印了該文章，封面是一副類似於《倫敦人狼》2影片的恐怖劇照。同時，還有一欄補充報道《殺死人狼》，描述了銀彈將要完成的（現代）神話。在出版以前，我並未注意到補充報道和文字，也沒有料到一篇嚴肅的技術性文字會被這樣潤色。
Computer雜誌的編輯們是取得他們想要的效果的專家，不過，似乎有很多人閱讀了那篇文章。因此，我爲那一章選擇了另一幅人狼插圖，一幅對這種近乎滑稽物種的古老素描。我希望這副並不刺眼的圖案有相同的正面效果。 - 120 -
存在着銀彈－就在這裏！
《沒有銀彈》中聲稱和斷定，在近十年內，沒有任何單獨的軟件工程進展可以使軟件生產率有數量級的提高（引自1986年的版本）。現在已經是第九個年頭，因此也該看看是否這些預言得到了應驗。
《人月神話》一文被大量地引用，很少存在異議；相比之下，《沒有銀彈》卻引發了衆多的辯論，編輯收到了很多文章和信件，至今還在延續3。他們中的大多數攻擊其核心論點和我的觀點——沒有神話般的解決方案，以及將來也不會有。他們大都同意《沒有銀彈》一文中的多數觀點，但接着斷定實際存在着殺死軟件怪獸的銀彈——由他們所發明的銀彈。今天，當我重新閱讀一些早期的反饋，我不禁發現在1986年～1987年期間，曾被強烈推崇的祕方並沒有出現所聲稱的戲劇性效果。
在購買計算機軟件和硬件時，我喜歡聽取那些真正使用過產品並感到滿意的用戶的推薦。類似的，我很樂意接受銀彈已經出現的觀點，例如，某個名副其實的中立客戶走到面前，並聲稱，“我使用了這種方法、工具或者產品，它使我的軟件生產率提高了十倍。”
很多書信作者進行了若干正確的修訂和澄清，其中一些還提供了很有針對性的分析和辯駁，對此我非常感激。本章中，我將同大家分享這些改進，以及對反面意見進行討論。
含糊的表達將會導致誤解
某些作者指出我沒有將一些觀點表達清楚。
次要（Accident）。在第16章的摘要中，我已經盡我所能地清晰表達了《沒有銀彈》一文的主要觀點。然而，仍有些觀點由於術語“accident（偶然）”和“accidental（次要）”而被混淆，這些術語來自亞里斯多德的古老用法4。術語“accidental”，我不是指“偶然發生”，也不是指“不幸的”，而是更接近於“附帶的”或者“從屬的”。
我並不是貶低軟件構建中的次要部分，相反，我認同英國劇作家、偵探小說作者和神學家桃樂絲·賽爾絲看待創造性活動的觀點，創造性活動包括（1）概念性結構的形式規格化，（2）使用現實的介質來實現，（3）在實際的使用中，與用戶交互5。在軟件開發中，我稱爲“必要（essence）”的部分是構思這些概念上的結構；我稱爲“次要（accident）”的部分指它的實現過程。 - 121 -
現實問題。對我而言（儘管不是所有人），關鍵論點的正確與否歸結爲一個現實問題：整個軟件開發工作中的哪些部分與概念性結構的精確和有序表達相關，哪些部分是創造那些結構的思維活動？根據缺陷是概念性的（例如未能識別某些異常），或者是表達上的問題（例如指針錯誤或者內存分配錯誤）等，可以將這些缺陷的尋找和修復工作進行相應的劃分。
在我看來，開發的次要或者表達部分現在已經下降到整個工作的一半或一半以下。由於這部分是現實的問題，所以原則上可以應用測量技術來研究6。這樣，我的觀點也可以通過來更科學和更新的估計來糾正。值得注意的是，還沒有人公開發表或者寫信告訴我，次要部分的任務佔據了工作的9/10。
《沒有銀彈》無可爭辯地指出，如果開發的次要部分少於整個工作的9/10，那麼即使不佔用任何時間（除非出現奇蹟），也不會給生產率帶來數量級的提高。因此，必須着手解決開發的根本問題。
由於《沒有銀彈》，Bruce Blum把我的注意力引向Herzberg、Mausner和Sayderman7等人在1959年的研究。他們發現動機因素可以提高生產率。另一方面，環境和次要因素，無論起到多麼積極的作用，仍無法提高生產率。但是在產生負面影響時，它們會使生產率降低。《沒有銀彈》認爲很多軟件開發過程已經消除了以下負面因素：十分笨拙的機器語言、漫長的批處理週轉時間以及無法忍受的內存限制。
因爲是根本困難所以沒有希望？1990年Brad Cox的一篇非常出色的論文《這就是銀彈》（There Is a Silver Bullet），有說服力地指出重用和交互的構件開發是解決軟件根本困難的一種方法8。我由衷地表示贊同。
不過，Cox在兩點上誤解了《沒有銀彈》。首先，他斷定軟件困難來自“編程人員缺乏構建當今軟件的技術”。而我認爲根本困難是固有的概念複雜性，無論是任何時間，使用任何方法設計和實現軟件的功能，它都存在。其次，他（以及其他人）閱讀《沒有銀彈》，並認定文中的觀點是沒有任何處理軟件開發中根本困難的希望——這不是我的本意。作爲本質上的困難，構思軟件概念性的結構本身就有複雜性、一致性、可變性及不可見性的特點。不過實際上，每一種困難產生的麻煩都是可以改善的。
複雜性是層次化的。例如，複雜性是最嚴重的內在困難，並不是所有的複雜性都是不可避免的。我們的很多軟件，但不是全部，來自應用本身隨意的複雜特性。來自一家國際管理諮詢公司，MYSIGMA Lars Sodahl的Lars Sodahl和合作夥伴曾寫道：就我的經驗而言，在系統工作中所遇到的大多數困難是組織結構上的一些失誤徵兆。試圖爲這些現實建模，建立同等複雜的程序，實際上是隱藏，而不是解決這些雜亂無章的情況。
Northrop的Steve Lukasik認爲即使是組織機構上的複雜性也不是任意的，可能容易受到策略調整的影響。
我曾作爲物理學家接受過培訓，因此傾向於用更簡單的概念來描述“複雜”事物。現在你可能是正確的，我無法斷定所有的複雜事物都容易用有序的規律表達⋯⋯同樣的道理，你不能斷定它們不能。
⋯⋯昨天的複雜性是今天的規律。分子的無序性啓迪了氣體動力學理論和熱力學的三大定律。現在，軟件沒有揭示類似的規律性原理，但是解釋爲什麼沒有的重擔在你的身上。我不是遲鈍和好辯的。我相信有一天軟件的“複雜性”將以某種更高級的規律性概念來表達（就像物理學家的不變式）。
我並沒有着手於Lukasik提倡的更深層次的分析。作爲一個學科，我們需要更廣泛的信息理論，它能夠量化靜態結構的信息內容，就像針對交互流的香農信息論一樣。這已經超越了我的能力。作爲對Lukasik的簡單迴應，我認爲系統複雜性是無數細節的函數，這些細節必須精確而且詳細地說明——或者是藉助某種通用規則，或者是逐一闡述，但決不僅僅是統計說明。僅靠若干人不相干的工作，是不大可能產生足夠的一致性，能用通用規律進行精確描述。
不過，很多複雜性並不完全是因爲和外部世界保持一致，而是因爲實現的本身，例如數據結構、算法、互聯性等。而在更高的級別開發（發展）軟件，使用其他人的成果，或者重用自己的程序——都能避免面對整個層次的複雜性。《沒有銀彈》提出了全力解決複雜性問題的方法，這種方法可以在現實中取得十分樂觀的進展。它倡導向軟件系統增加必要的複雜性：