這是人月神話：軟體專案管理之道（20週年紀念版）的第十七章：再論「沒有銀彈」(“No Silver Bullet”Refired)，上一篇沒有銀彈：軟體工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering），ㄚ琪說過很抽象又很長的文章，之後過了九年，作者自栩預言滿準的，看來比王老師準，但是卻也引發了很爭議，原因就是ㄚ琪說的，太抽象了，每個說詞都很難懂，所以作者針對這說爭議，再繼續說明，我們也就繼續地看好戲。
含糊不清的用語將造成誤解，這節裡頭的主題就是如此，我本身也有點懷疑作者自打嘴巴，因為真的很抽象，你就得花很多時間解釋，而使用者也得聰明很容易融入那個意境才能懂，所以作者被很多人批評沒有講得很清楚，首先的議題就是附屬性(accident)跟附屬的(accidental)的混淆，就英文看起來好像是意外，偶然發生的，但是作者說那是次要的，不過我們從中文翻譯來看應該不會混淆不清，除非譯者翻的有問題。
所以作者說在軟體開發裡頭，『本質性(essence)工作，所指的就是概念構造的創作智能』，『附屬性工作指的是實作的程序』，這樣的解釋希望大家能比較懂，但是ㄚ琪還是抱著懷疑的態度。
在對事實的一項質疑裡頭，甚至連赫茨伯格的雙因素理論也把激勵因素跟保健因素用來抨擊這篇文章，但是以我初淺的瞭解，這個研究好像比較針對勞工，相較於軟體開發來說，這個理論是否完全用得上就有疑問了，不過文章中把生產力拿來討論或許也不錯吧。
本質性工作很困難所以就無望了嗎？原來There Is a Silver Bullet裡做反擊了，『採取可再利用(reusable)、可替換組件的方式，來對付屬於概念本質性部份的問題，我由衷地表示贊同。』，作者先表示贊同，後面還是說到但是…，然後開始反駁，似乎這就是論文口試的一種常見到的劇情不是嗎？
就複雜性的層級來說，反正就一個字complex複雜，來述說我的感覺吧。
Harel的Biting the Silver Bullet（中譯咬緊銀彈），看來大家很喜歡一直針對銀彈做討論喔，不過ㄚ琪此刻讀來有點意興闌珊了，但是David Harel可算是有來頭的人物，可以從維基及他的網頁看出來，而這篇的文章在文中以悲觀、樂觀與事實來討論，作者直說很多程式設計師有樂觀的職業病，ㄚ琪看起來好像也是如此，難道樂觀不好嗎？應該沒什麼不好，但可別樂觀過了頭，所以我想這些事實ㄚ琪頗能接受的。
Harel覺得沒有銀彈的原因有三點：
- 本質性與附屬性的清晰劃分
- 獨立地評論每個銀彈
- 只預測了十年，這樣沒有足夠長的時間“出現任何重大的進步”
囧，本質性與附屬性這種太深奧的問題，看起來大師都很喜歡討論喔，我只覺得有點愛睏，但是看到大師還努力地做實驗，ㄚ琪應該覺得汗顏才對，不過這個實驗是基於歸繆法(reducto ad absurdum)，常聽過歸納法，很少聽過歸繆法，不過另一個名詞反證法應該就有聽過了，維基這樣寫：『
反證法（又稱歸謬法、背理法）是一種論證方式，他首先假設某命題不成立（即在原命題的條件下，結論不成立），然後推理出明顯矛盾的結果，從而下結論說原假設不成立，原命題得證。
反證法常稱作Reductio ad absurdum，是拉丁語中的「轉化到不可能」，源自希臘語中的「ἡ εις το αδυνατον παγωγη」，阿基米德經常使用它。』不過用這樣的方式做實驗，被作者駁回，駁來駁去的很是精彩啊。
Harel後來有提出「香草框架」(The Vanilla Framework)的模塑技術(modeling technique)，而這這就是銀彈，作者倒是沒有駁回，只是說無法衡量好壞，看起來是一句話帶過了，不過或許是個好方法，但是這個方法ㄚ琪也不甚是很瞭解，期待有機緣可以碰到。
Capers Jones是一個在軟體工程方法上的專家，他也有他的官點來反對沒有銀彈，他說：『非也，把重點放在品質上，生產力將隨之而來。』他認為，只要是成本過高和時程落後的專案，都耗費了非常多的額外時間和工作在尋找並修正規格、設計、實作中的錯誤。這裡頭講到品質，那麼，生產力的情形如何？被作者點到了，生產力值難以評估，這類的工作的人做得要死要活卻很容易被低估了，理由是沒有performance輸出給主管的看，如果這位主管習慣用監控線上生產的角度來看，我想程式設計師或是設計師之類的人會很難生存下去，Sophia看起來就面臨了這種情形，而我也想擺脫這樣情形，可是文章很少有人按讚，看來也很難跳多出來。
續談到套裝軟體-用買的；不要自己做以及威力強大的創作工具，好吧，不得不妥協了，我勸大家用，看來工作達人可能要改行寫軟體的分享了，寫程式少寫一點，創作工具也得好好分享，這樣的口味才能迎合大眾。
至於物件導向程式設計，這個已慢慢深耕於ㄚ琪的心中，只能被作者稱為是銅彈，而且被質疑為可行嗎？
這種看起來用大塊積木來建構的技術，其特徵是，模組化(modularity)和簡潔的介面。其次，它強調了封裝(encapsulation)，即外界無法看到元件的內部結構；它還強調了繼承(inheritance)和階層(hierarchical)結構的類別(class)以及虛擬函式(virtual function)。物件導向還強調了強制抽象資料型別(strong abstract data-typing)，它確保某種特定的資料型別只能由它適當的操作(operation)方法來操作。
一個『為什麼物件導向技術的成長如此緩慢？』，作者這樣敘述，不過ㄚ琪並不覺得成長緩慢，可能我並不是早期的那個時代的人吧，這個技術現在應該很火熱吧，不過作者提到的主要概念『投資集中在前期，回收集中在後期』，這樣看起來好像前人種樹，後人乘涼的感覺，既是如此，就真的是要看很長的一段時期了，Designing C++ Libraries有這樣一段『物件導向技術將不會使第一個專案的開發速度變快，下一個可能也不會，將要到同一類型的第五個專案才會明顯地變快』，想要搭快速列車的人，有沒人自願先做這列火車啊，ㄚ琪一定是繼續有耐心地等吧。
作者也提到了再利用的情形，從字裡行間來看，雖然有了物件導向這個偉大的技術，但是再利用性好像很低，不論是個人或團體層級來說都不是很高，但是如果從開放原始碼的觀念來看，我覺得再利用性，會慢慢提高，但是前提是要有人願意分享，而且這種人可以活下去，那麼再利用性要提高不是難題，這不就事看在神眼光是多麼美好的一件事啊。
作者接下來預測了一個可預測卻未預測的軟體再利用問題—學習大量字彙，我想這個預測現在應該已經實現了，看看Java的函式庫手冊吧，歷經了無數版別的開發，ㄚ琪覺得真的越來越厚了，難怪手冊一直翻不完，甚至覺得買那麼大本的手冊要當枕頭睡嗎？可是又很難睡啊。
最後的結論，雖然很多人要反駁，但是作者一一地駁回，並且說形勢沒有改變，至於真的是否沒有改變，ㄚ琪也無法評論，好像沒辦法繼續寫下去了，我想我還是繼續用分享心得的方式來寫下去，用學習的心態來看這本書，或許會比較快樂。