摘要
所有軟體創作都包括了本質性工作（essential task）和附屬性工作（accidental task）。前者是去創造出一種由抽象的軟體實體所組成的複雜概念結構，後者則是用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言。
若跟本質性的工作相比，軟體工程人員所做的事，還有多少算是花在附屬性的工作上呢？除非附屬性工作要耗費的心力超過全部工作的9/10，否則就算是將所有的附屬性工作降至零，也無法將整個開發工作的輕鬆程度提升一個數量級。以往，軟體生產力的重要進展絕大部分是來自於人為障礙的排除，像是嚴苛的硬體限制、難用的程式語言、上機時間（machine time）的不足等等，這些都是造成附屬性工作益發困難的原因。
論文核心
這篇經典論文的核心論述通常被解釋為複雜的軟體工程問題無法靠簡單的答案來解決。
次要和必要複雜度
在該論述當中，討論到了次要和必要複雜度的差異。所謂次要複雜度是指由人們本身所產生的問題，而這類型的問題是可以被解決的。譬如說，撰寫和最佳化組合語言的複雜度就是屬於次要的，它可以藉由高階程式語言如Java來取代。必要複雜度則是從軟體本身要解決的問題衍生而來，並無法被移除。如果軟體需要提供三十個不同的功能，那么這三十個功能都是必要的，這些功能都必須被實作出來。
軟體工程面臨的問題在於我們已經清除了大部分的次要複雜度，而剩餘的（主要複雜度）都無法改變。
在移除次要複雜度中最大的進展也許要算是高階語言的誕生，像是Fortran和Java。
在歐洲中世紀的傳說中，有一種叫“人狼”的妖怪，就是人面狼身。它們會講人話，專在月圓之夜去襲擊人類。而且傳說中對“人狼”用一般的槍彈是不起作用的，普通子彈都傷不到也打不死它，只有一種用銀子作成的特殊子彈才能把它殺死。Brooks在他最著名的隨筆文章《No Silver Bullet》里引用了這個典故 ，說明在軟體開發過程里是沒有萬能的終殺性武器的，只有各種方法綜合運用，才是解決之道。而各種聲稱如何如何神奇的理論或方法，都不是能殺死“軟體危機”這頭人狼的銀彈。他當時大膽聲稱並預言方法學家們10年之內絕找不到什麼好的的神奇銀彈。他的文章發表後，被廣泛引用，後來他的隨筆結集成書，《人月神話》。從此，在軟體界，銀彈（Silver Bullet）成了一個通用的比擬流行開來。1975年所出版的《人月神話》—被稱為軟體工程聖經。
問題之所在－銀彈與軟體項目
佛瑞德·布魯克斯在《沒有銀彈》中提到：
在民俗傳說里，所有能讓我們充滿夢靨的怪物之中，沒有比狼人更可怕的了，因為它們會突然地從一般人變身為恐怖的怪獸，因此人們嘗試著查找能夠奇蹟似地將狼人一槍斃命的銀彈。
我們熟悉的軟體項目也有類似的特質（以一個不懂技術的管理者角度來看），平常看似單純而率直，但很可能一轉眼就變成一隻時程延誤、預算超支、產品充滿瑕疵的怪獸，所以，我們聽到了絕望的呼喚，渴望有一種銀彈，能夠有效降低軟體開發的成本，就跟電腦硬體成本能快速下降一樣。
但是，我們預見，從當前開始的十年之內，將不會看到任何銀彈，無論是在技術上或管理上，都不會有任何單一的重大突破，能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
然而，懷疑並非悲觀，雖然我們預見不會有任何重大的突破，而且事實上，我相信發生這種重大突破也不符軟體的本質，但是，仍然有許多令人振奮的創新正在進行當中，若能按部就班、持之以恆地予以發展、散布，並靈活運用的話，想必應該會得到一個數量級的進展。捷徑是不會有的，但有志者事竟成。
人類能克服疾病的第一步，就是以細菌說（germ theory）淘汰了惡魔說（demon theory）和體液說（humours theory），正是這一步，帶給了人類希望，粉碎了所有奇蹟式的冀望，告訴人們進步是要靠按部就班、不辭勞苦而來，得在清潔衛生方面持續不斷地投入心血，養成良好習慣，才是正道。如今，我們面對軟體工程也是一樣。
《沒有銀彈》主張並斷言在未來的十年之內（從1986年文章發表後開始計算），不會有任何單一的軟體工程上的突破，能夠讓程式設計的生產力得到一個數量級的提升。不過，作者認為這個假設當前已不再成立。
假設軟體開發的總工作量為10，其中，本質性工作占掉1，附屬性工作占掉9，那么改善附屬性工作，將之消除，就可以把軟體工作量減輕到1（因為附屬性工作變成0），此時我們可以說，軟體工作開發的輕鬆程度提升了一個數量級（因為由10進步到1，差10倍）。
軟體開發的困難
布魯克斯將軟體開發的困難分為兩類，這篇經典論文的核心論述通常被解釋為複雜的軟體工程問題無法靠簡單的答案來解決。布魯克斯相信軟體開發真正的困難，是在於這種概念構造的規格制定、設計和測試，而並非在孜孜矻矻於它的呈現方式，以及測試該呈現方式的精確程度。
•本質性（essence）：軟體本身在概念（conceptual）建構上存先天的困難；亦即如何從抽象性問題，發展出具體概念上的解決方案。
•附屬性（accident）：將概念上的構思施行於電腦上，所遭遇到的困難。
布魯克斯提到，有某些地方已經被附屬性（accident）和附屬的（accidental）這些字眼給混淆了，這個字眼是出自於亞里斯多德的古老用法。就英語：accidental的這個字眼而言，他所指的並不是偶然發生的意思，也不是意外不幸的意思，而是比較接近伴隨的或次要的意思。
造成本質性困難的原因
布魯克斯認為，附加性的困難會隨著工具的改善而逐漸淡化，反而是本質性的困難最難以解決，因為大部分的活動是發生在人們的腦海里，缺乏有效的輔助工具。依照布魯克斯的說法有下列幾項：
•複雜性（complexity）：軟體要解決的問題，通常牽扯到計算步驟，這是一種人為、抽象化的智慧型活動，多半是複雜的。
•隱匿性（invisibility）：尚未完成的軟體是看不見的，即使利用圖示說明，也常無法充分呈現其結構，使得人們在溝通上面臨極大的困難。
•配合性（conformity）：在大型軟體環境中，各子系統的接口必須協同一致。由於時間和環境的演變，要維持這樣的一致性通常十分困難。
•易變性（changeability）：軟體所套用的環境常是由人群、法規、硬體設備、套用領域等，各因素所匯集而成，而這些因素皆會快速變化。
過去的突破解決了附屬性的困難
高級語言[編輯]參見：彙編語言和機器語言
高級語言達成了什麼樣的使命呢？它使程式不再陷入許多原來附屬在程式里的複雜性。一支抽象的程式所包含的是一些概念的構造：函式、數據類型、先後順序的關係，以及訊息傳遞的方式，然而實際上，與機器碼攸關的其實是比特、暫存器、條件、分支、通道、磁碟等等。高級語言可以將抽象程式里所必要的構造予以具體化，並且避免掉所有更低級的東西，在這種情形下，它把跟程式內涵一點關係都沒有的那一整層複雜性給去除了。
分時技術[編輯]參見：時間片
分時（time-sharing）技術所挑戰的是另一個截然不同的難題，因為分時，確保了即時性，使我們得以持續保住腦子裡對複雜的概觀。分時技術所能貢獻的底限也可以直接推算出來，由於其主要的效用就是縮短系統的反應時間，當這項時間趨近於零，並在某一點上跨越了人類所能夠察覺到有系統反應時間存在的臨界點，大約是十分之一秒，低於這個值，就不會再有任何效益了。
統一的開發環境[編輯]參見：集成開發環境
Unix和Interlisp是第一個得到廣泛使用的集成軟體開發環境，並且也被公認已將生產力提升了好幾倍。這方面所挑戰的附屬性難題，就是藉由完整的程式庫、統一的檔案格式、管道（pipe）和過濾器（filter），以促成軟體的共用，於是，任何概念的構造在理論上都可以調用、傳遞和運用在另一個對象，而實務上，這點也很容易就可以辦得到。這方面的突破隨後也帶動了整個工具軟體的發展，因為每一個新工具只要用的是標準規格，就可以適用於任何程式。
查找銀彈
•Ada和其他高級語言的進展
程式語言Ada是1980年代的一個通用型高級語言。事實上，Ada不只是反映了在語言概念上的演進，同時也具體實現了一些助長現代設計與模組化概念的特徵；也許，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）》，Cox指出採取可再利用（reusable）、可替換組件的方式來對付屬於概念本質性部分的問題。Glass、Vessey和Conger在他們1992年的一篇論文中就指出，有充分的證據顯示，對銀彈這種沒有意義的研究仍尚未停止。
Harel的分析
David Harel在1992年的一篇文獻《緊咬銀彈（Biting the Silver Bullet）》中，對已經發表的《沒有銀彈》進行非常仔細的分析。Harel認為《沒有銀彈》和1984年Parnas《戰略防禦系統軟體面面觀》這兩篇都寫得太過於絕望了，於是他就針對這一點來闡述較為光明的一面，他的文章還用了個副標題是“讓系統開發走向一個光明的未來”。
就Harvel的認知，他認為造成《沒有銀彈》悲觀的原因有三點：
•本質性和附屬性的二分法。
•對每一個可能的銀彈採取個別單獨評論的方式。
•只預測10年，這對“預期任何重大的突破”而言，並沒有足夠長的時間。
Harvel更提出了一項假想實驗，他假定《沒有銀彈》的主張不變，只是發表的時間換做是在1952年，而非1986年。他這時用的是歸謬法（reducto ad absurdum），用來反駁自附屬性中切分出本質性的作法。
Jones的觀點
Caper Jones曾提出一個敏銳的見解，這個見解最初是寫在一連串非正式的紀錄中，後來出當前書上，幾個與布魯克斯通信的朋友也提到過。《沒有銀彈》就如同大部分的論文一般，都把焦點集中在生產力，也就是軟體每單位的輸入成本能得到多少輸出效果。Jones則表示：“把重點放在品質上，生產力將隨之而來”。他認為，只要是成本過高和時程落後的項目，都耗費了非常多的額外時間和工作在查找並修正規格、設計、實現中的錯誤。Jones並提出數據佐證，缺乏有系統的品質控制與發生時程落後的災難，這兩者之間有強烈的相關性。
Caper Jones相信，兩份同等的Cobol程式分別花10年編寫，但其中一份使用結構化的方法，另一份則否，那么所得到的效果將相差3倍。
