四、沒有銀彈，或人狼殺不死
人狼這個動物很奇怪，皮肉堅實還是自療系的，所以要麼砍它不動，要麼殺它不死。這種動物如同習得（傳說中的）金鐘罩功夫，刀槍不入，水火不怕。也如同金鐘 罩有罩門一樣，人狼對銀沒有免疫，因此如果做一顆銀彈就能穿透它，進而殺了它。
所以人們總是說一物剋一物，大象怕老鼠，總有對付它的法子。但如果你設定了一個自圓已說的悖論，那除了否定悖論本身沒有意義，也就沒有解它的法子了。同樣 的道理用在“沒有銀彈”這個觀點上，也是成立的。
也就是說，如果我們討論“有或者沒有銀彈”，那麼應該先反過來看看“人狼”的本質。因爲本質是人狼對銀不免疫，所以我們才能找到銀彈並殺了它。如果人狼根
本就殺不死，那麼不要說金彈銀彈，就是核彈也沒用——因爲它殺不死。
我們來看看Brooks所謂的人狼，也就是“軟件活動的根本任務”。首先，Brooks認爲我們並沒有足夠的精力來放到“軟件活動的根本任務”這一目標之
上。他的論證過程是：
根本任務的目標：抽象軟件構成的複雜概念結構；
次要任務的目標：表達抽象實體，在一定範圍內映射成計算機的執行邏輯；
我們大多時候在關注次要目標，例如寫程序和開發“寫程序用的”程序；
我們寫再多的程序與再強的“寫程序用的”程序都不會觸及到根本任務。
進一步的分析來說，是我們探索目標的方法，分散了達到目標的力量。我們在通向目標的路線上越是努力，那麼我們的力量就被分解得越快。次要目標是達到主要目
標所必須的，但次要目標上花費越多的精力，就越無法接近主要目標。既然要經過A才能達到B，而經過了A也就沒有力量達到B。那麼結論自然是：達不到B（主
要目標）。
這個悖論說的是手法問題。你當然可以超越某種手段，可以從純理論上來推論出：沒有了A就成了，我們可以由C達到B。由於永遠存在C至*（任意）的途徑，那
麼當然存在C～B的途徑。由於手段無以窮盡，所以Brooks當然不能從這上面說服大衆。於是，Brooks立即又論述了這個人狼的四個具體特性：複雜
度、一致性、可變性和不可見性。
一是要面對極端的複雜性。儘管我們可以用模件複用來緩解複雜性，但是軟件實體的擴展必須是不同元素實體的添加，這些元素“以非線性遞增的方式交互，因此整 個軟件的複雜度以更大的非線性級數增長”。所以你創建一個新軟件就必然面臨更多的（非線性級數增長的）舊軟件中不能被複用的元素。所以在複雜性方面，人狼 是自療系的：越做越複雜，不可能變簡單。
二是要背上不可丟棄的歷史包袱。由於Brooks強調新的軟件需要保證跟舊的軟件兼容（有點象MS Vista兼容MS DOS），你創生了一個軟件也就創生了下一個軟件的需求，所有的創生活動產生了需求的自增集合，儘管這種“變體不是必需的”，但它一個不可丟棄的歷史包 袱。所以在保證一致性這一方面，人狼是自增長的。
三是要接受需求的持續變更。軟件要保證設計一致性才能成功，但從這個軟件被設計的那一刻開始，你就必須接受來自它人的、自身的、市場的、自然及社會規律 的，以及不同的文化和思想習慣的差異的需求（這意味着每個人的想法都可能被作用在一個軟件實體上）。需求是無度和不可控的，所以人狼本身又是變形系的。
四是不可見。你找不到足夠的抽象方法描述軟件的不同側面，也就不能將它們表達爲抽象概念上的圖形。如果你找到了這樣的方法，那麼這個“軟件”本身就不足夠 複雜，因此也就不是原本含義上的“根本任務”。所以，它是隱形的——你如果看見了它，要麼是看見了諸多複雜的方面中的一面，要麼根本就是看錯了。
從遊戲術語來說，我們要面對的是“自增＋自療＋變形＋隱身”的終極大BOSS，而Brooks還要求：HI，小子，你得拿個足夠簡潔（例如小刀？）的武器 去單挑（獨立的解決方案？）。
如果有遊戲策劃寫出這樣的腳本，那麼他得被玩家活活罵死。但Brooks描繪了這樣一隻“殺不死的人狼”，並開心的說“你們沒有銀彈”。然而，他不但沒有 被罵死，還得到了一致的認可，並且整個工程界歡欣雀躍，一致以找出那枚銀彈爲已任。
這樣來戲謔大師的預言實在是有些不敬。那麼大師是否就是在那麼嚴謹地對待自己的觀點呢？他說：必須聲明的是，構建獨立小型程序的數據不適用於編程系 統產品。
大師的意思是：因爲不能通過“做更多的小型程序”來得到做大型系統的經驗／數據，所以無論何時，只要面對大型工程，你的經驗值就立即歸零（或者極低）。顯 然，（連白癡都知道）毫無經驗值地直接面對終極大BOSS，結果一定是失敗。又由於所有面對這些大BOSS的都（無可置疑地）失敗，因此我們也就不可能有 成功。
顯然這是一個法寶：如果你違背這個邏輯而又獲得了成功，那麼這種成功可以立即被歸結於：你在做一個小型程序。
放心吧，沒有人能殺得死Brooks的人狼的，也不可能找得到這樣的銀彈。因爲Brooks的人狼原本就是殺不死的，他甚至連“給睡熟的人狼胸口一刀”這 樣偶然性的機會也沒給你留下。任何時候，你殺死了一頭看起來有點象是人狼的怪物，Brooks都可以輕描淡寫的說：OH，小子，你看錯了，那並不是人狼。
五、從廣義工程到狹義工程
現在我們回到一個實際的問題上：工程的本質需求是什麼？如果我問一千個人工程的本質，可能會得到一千種答案。因爲大家離本質的東西都很遠，又從不同的角度 去看這本質，故而得到的答案並不相同——而且每一種答案都貌似正確。
但是我問的是“本質需求”。對此，我的答案是：本質需求是“實現(工程的目標)”。
不管工程本質是怎樣的，但這個需求如一。我們完不成它就等於失敗，至於它是否是Brooks所說的“軟件活動的根本任務”，與這個具體的工程無關；至於它
是不是從人類發展的歷史上來看，向着“軟件活動的根本任務”的目標邁進了一步，也無與這個具體的工程無關。
簡單地說，我們做具體工程的目標，並不等同於Brooks所說的“軟件活動的根本任務”。
回到具體工程的視角，我們面臨的可能是：
這個對比中，a1的需求基本可控，a2就得面對客戶或業務規則的變化；b1不需要背上歷史包袱，甚至不用考慮架構一致性，而b2就必須做好設計並面臨長期 用戶需求的沉積；c1可能一兩個人就完成任務，c2就必須組織大型團隊 ……我們如果要找一個方案來適應這所有的“軟件開發活動”，那麼它只可能是彈性的。而彈性並自由伸縮的一個 方案必然帶來學習和運用上的困難，因此你又得投入人力來學習使用，並在實施中不時監控它。——於是，你的人力和時間成本又增加了。
不要去相信“它適合於所有的工程”這種商業推廣的鬼話。那絕對是赤祼祼的欺騙。你要看住你的口袋，因爲你可能在消耗你的資源 （時間、人力與金錢）去適應一種方法。你一方面要花銷資源去組織、實踐和推動這些工程方法，另一方面工程的 規模可能根本沒有資源去推動它們，你必然面臨失敗；如果你增加資源去推動，那麼成本可能大於項目利潤，你的老闆會不樂意而直接中止這個項目，你還是失敗。
所以問題出在你啓動這個工程的最早階段：你認清目標並決定用什麼方法來驅動這個工程。你的選擇涉及到項目的各方面因素，而不是昨天從某個培訓 中聽到的什麼奇怪方法。作爲合格的項目經理 （和工程決策者），你必須要洞悉各種工程方法的應用環境、代價，也必須清楚所在團隊 或公司的規模與實力，同時還要了解團隊的優點與弱點。只有充分評估這些因素，你纔可能決策在具體工程中應用 的方法，或嘗試之。
但是我們總是會遇到無比龐大的項目，這絕不是“只做做小項目”就可以解決得了的問題。然而我認爲Brooks的假設過於學術，因爲我們找不出一個理由來證 明：需要一種純粹的、獨立的和並不那麼複雜的方法來實施一個工程。對於一個具體的、哪怕是無比龐大的項目來說，這種學術的純粹和完美也不是必須的。在這個 具體工程來說，完成它是必要的，而尋找完美方法，只是在完成這個項目之後進行總結時的一種附帶價值。
換而言之，即使我們承認Brooks所說的“
軟
件
活動的根本任務”需要一種完美的、類似於銀彈的解決方案，我們也不得不承認對於具體工程來說，“表達抽象實體，在一定範圍內映射成計算機
的執行邏輯”纔是根本任務。
我們看到了分歧。而我認爲對這個分歧的合理的解釋是：在廣義工程與狹義工程(或言之具體工程)中，主要目標與次要目標正好是倒置的。對於後者來說，將需求
表達爲抽象實體，並在“一定範圍”內映射成計算機的執行邏輯，正好是這個工程存在的根本價值。如果這項目標不能被達成，那麼這個狹義的工程既不可能實施，
也不可能爲所謂廣義工程產生任何價值。
既然對於狹義工程（哪怕它無比龐大）來說，Brooks所設的銀彈只是面向其次要目標的，那麼它也不是必須的元素。因此，我們儘可以選擇集束炸彈來解決問 題。我們可以從建築工程中學習監理，可以從製造工業中學習模件，也可以從哲學中學習概念抽象，我們還可以從社會學中去了解集體、組織、規模和控制……
一切一切，前提是我們要放開對那個“銀質子彈”的追尋。這樣，面對一個確定的工程對象，我們便可以找到很多問題的解法。但如果堅持存在一個“絕對正確的解
法”，那麼任何實際問題都會延伸出枝節，蔓佈於這個“絕對正確的解法”的牆籬之外。
最後再來看一眼那頭人狼，也許（對於我們實施狹義工程的人們來說，）我們接下來便要闊別它了。要知道在所有“有銀彈”的故事裏，“人狼”都是殺得死的。而
Brooks描述了一頭殺不死的人狼。因而“沒有銀彈”也自然成立了。但是如同我們上一節講述過的，這種結論並沒有意義。對於“殺不死”這個前提，“有或
者沒有”這樣的討論本身就是多餘的。
同樣的方法，我們也證明過Brooks所述的銀彈是理想化的。於學術而言，任何現象都應該有一個純粹的解。但這種廣義工程的論題，除了給商家制造更多的商 機之外，並不會因爲它的爭爭吵吵而給狹義工程帶來什麼價值。事實上，正是狹義工程給廣義工程提供了談資和論據，才讓後者變得越來越豐富。
卻也正是這些豐富的、源自那些狹義工程的實踐所帶來的知識，讓更多人憧憬於那顆銀彈的存在，而全然忘卻，一顆子彈的威力，原本是出自一個並不成功的丹藥實
驗。
結束語
總的來說，我事實上並不反對某種具體的方法，而是在努力的學習種種方法。但是我並不認爲有什麼單一的方法能解決所有問題，每一種解決方案都是有其前提和背 景的。精通一種或全部工程工具、方法和過程，都無助於掌握這些前提、背景以及潛在的關係。理解工程的適用性，涉及到工程專家的整體素養和實踐經驗，也涉及 到具體的工程環境、目標和實施者（團隊 ）。而這些課題，卻正好是目前的軟件工程 甚少談論的。
在銀彈的話題上，答案不外是：有、沒有和將來一定會有。我的答案與這些都不一樣。我認爲“有沒有”的話題沒有意義，不值得討論。因爲Brooks在人狼的 設定上是一個僞命題，而銀彈的假設上則是學術的。我進一步的觀點是，廣義工程對首要任務（人狼）和完美方案（銀彈）的假設，不應該成爲狹義工程所逐求的終 極與利器。
我們要分清狹義工程與廣義工程。正是由於他們對本質需求的設定完全不同，因而也有各自不同的主要與次要任務。一切工程活動的歷史告訴我們，曾經的經驗、失 敗和成功，以及據此在廣義工程中歸納推演的理論，都只是我們在具體的、狹義的工程中的參考，而非無往不利的銀彈。