這是人月神話：軟體專案管理之道（20週年紀念版）的第十六章：沒有銀彈：軟體工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering），這一篇文章落落長而且一開始在摘要就有一個註解，ㄚ琪好奇地去看，赫然發現原來這一篇不是原作者的文章，這是出於Information Processing 1986, 由H. –J. Kugler (1986)所編輯的the Proceedings of the IFIP Tenth World Computing Conference, pp. 1069-76. 在IFIP和Elsevier Science B. V., Amsterdam, The Netherlands授權轉載的，難怪看起來很像是論文的文章，讀來也不是很順，不過還是得分享自己的讀後心得看看。
篇名中的本質性指的是『去創造出一種由抽象的軟體實體所組成的複雜概念架構』，附屬性則指『用程式語言來表現這些抽象的實體，並在某些空間和速度的限制之下，將程式對應至機器語言』。當我們在努力克服附屬性的工作時，作者認為我們再怎麼努力也無法讓開發工作有一個數量級的提昇，所以接下來的就只能從本質性工作來著手了。
這裡有幾個建議，引用簡體版的：
- 仔細地進行市場調查，避免開發已上市的產品。
- 在獲取和制訂軟體需求時，將快速原型開發(rapid prototyping)作為迭代計畫的一部分。
- 有機地更新軟體，隨著系統的運行、使用和測試，逐漸添加越來越多的功能。
- 不斷挑選和培養傑出的概念設計人員。
避免開發已上市的東西確實是一個捷徑，但ㄚ琪會悲觀地看是軟體工程師的無用之時，因為別人有了，我們就用買的就好了，延伸到現在很多的軟體一直外包到大陸到印度，就是這樣的情形，這是從成本面上來考量，如果就安全面上來考量，或許就不是這麼一回事了。另外可能也是另一個新興工作的開始，這裡就題到了概念設計人員這個名詞，概念設計這個名詞可以發現很多是指創意方面的設計人員，所以像是建築、工業設計之類的工作，概念設計人員確實有其需要和供給的空間，但是在軟體界來說至少就台灣來看，好像沒有這一號的人物，或許我太孤陋寡聞吧。
在簡介這裡提到我們對疾病的看法，已經從惡魔說(demon theory)進步到體液說(humours theory)，再進步到細菌說(germ theory)，作者也很有信心，軟體工程也會這樣的，只是那時的軟體工程到底是在舊石器時代，還是新石器時代呢？現代的軟體工程又處在那個時代呢？ㄚ琪就不得而知了。
在註定就是要那麼辛苦嗎？–本質上的困難這裡，軟體開發的真正困難是『在於這種概念構造的規格制定、設計和測試，而並非在孜孜矻矻於它的呈現方式，以及測試該呈現方式的精確程度。』本質這兩個字感覺就很抽象，作者繼續用複雜度(complexity)、配合性(conformity)、易變性(changeability)、隱匿性(invisibility)做討論。
複雜度在這裡我只要說軟體實體的規模是舉世無雙的，這裡頭因為如此造成技術上的困難、管理上的問題，以及阻礙概念整體性(conceptual integrity)，並且難以發現疏忽的錯誤以及學習及理解上的困難，看到這頭應該開始暈了吧。
配合性的主軸就是軟體得配合人類現有的制度和系統的介面，這點倒說得較容易懂。
易變性來說，軟體碰到比房屋建築、電腦硬體及汽車更大的壓力，你看動不動就叫你改程式，你會常聽人說你給我改房子或改車子嗎？很少，而且工程號大成本也高，但是程式的變動總讓人覺得容易太多了，所以就會一直改改改。
軟體是很抽象的東西，它不像房子那樣可見，正因為這樣所以它的隱匿性就很高，高到可能你做了什麼努力，老闆看不出來。
在過去的突破所解覺得都是附屬性的難題，看來作者很直言不諱喔，像高階語言的使用，看起來是被認定微附屬性的工作。而分時技術的解決緩慢的回覆時間，也被認定是軟體開發過程中的附屬性難題的解決，所以還不是本質性。統一的軟體開發環境，我想我同意，所以就不用多說了。
尋找銀彈，在前面那節中，作者否定了高階語言、分時技術跟統一的軟體開發環境是本質性的工作解決，再這節裡要繼續探討幾個技術是否算是本質性的，ㄚ琪也一一地來看這些技術的意義並分享出來。
Ada和其他高階語言的進展，『Ada，是一種程式語言。源於美國軍方的一個計劃，旨在整合美軍系統中運行著上百種不同的程式語言編寫的程序，命名是為了紀念愛達·勒芙蕾絲而使用Ada。…Ada語言的重要特徵就是其嵌入式風格，模塊化設計，編譯檢查，平行處理，異常處理及泛型編程。Ada在95年加入了對物件導向設計的支持，包括動態分配等。…它被廣泛應用於一些非常重要的系統中，例如航空電子學，武器及太空飛行器的作業系統中。』這些ㄚ琪都摸不著邊，所以我無緣瞭解Ada，但是看來Ada不是本質性的工作解決。
物件導向程式設計，這是大家現在再熟不過的計術了，很可惜它也不是。
『人工智慧（英語：Artificial Intelligence, AI）有時也稱作機器智能，是指由人工製造出來的系統所表現出來的智能。通常人工智慧是指通過普通計算機實現的智能。該詞同時也指研究這樣的智能系統是否能夠實現，以及如何實現的科學領域。』，文中AI有分AI-1及AI-2，而AI-1則是這裡所指的人工智慧，不過這門技術頗深，ㄚ琪也摸過一點邊而已，但它也不是。
『專家系統是早期人工智慧的一個重要分支，它可以看作是一類具有專門知識和經驗的計算機智能程序系統，一般採用人工智慧中的知識表示和知識推理技術來模擬通常由領域專家才能解決的複雜問題。』所以這裡指的是前面說的AI-2，不過它也不是。
「自動化」程式設計(Automatic programming)，它可不是在說CIM喔，我的認知是程式自動設計程式，其實我的認知並沒什麼問題，但是文中這段『簡而言之，自動化程式設計從來都是一種好聽的說法，骨子里其實是用更高階的語言來編寫程式，比程式設計師目前所使用的語言還要高階罷了。』讀到這裡有點失望，不過也算認這個解釋，因此它也不是。
圖形化程式設計，這個真的也不用多說，太多視窗了，夠視覺吧，不過它也不是。
軟體的驗證，當然也不是。
環境與工具，『軟體開發環境上，現在已經實現的最大成果可能是整合資料庫的使用，用來追蹤大量的開發細節，供每個程式設計師精確地查閱資訊，以及在整個團隊協作開發中保持最新的狀態。』這也不是本質上的改進，唉。
工作站，別想了，它當然不可能是。
分享這麼多的技術，但是多不是，那麼在概念上大有可為的做法是什麼？外購與自製，『軟體開發最極端的可行方案，就是根本不要自己開發』，這還真廢話喔，但是真理，不過從事軟體開發的人可能就要失業了，改賣雞排嗎？所以像微軟的辦公室軟體，你只要會了，我想很多程式就不用再設計了，的確，這太具威力了，但是還是有這類軟體不能做的事，不過我想也撐不了多久，我倒希望這日子不要太早來臨，不然很快就要找另一份工作了。
需求的提煉與快速原型製作，這裡頭提到客戶的需求要再提煉萃取，這裡頭其實是頗高難度的挑戰，ㄚ琪到現在還沒碰到這樣厲害的客戶，都是要再訓練，不過這個成本應該很可觀，但是確實是本質性工作的解決。
漸進式開發-發育軟體，而非建構軟體，作者說『我現在還記得在1958年，當聽到一個朋友提及建構（building），而不是寫（writing）程式時，我所感受到的震驚。』今天ㄚ琪也要說，原來寫成式跟建構程式有這麼大的差別，ㄚ琪在跟人自我介紹時都會用到寫程式這個字眼，大家也都懂，但是今天才知道用建構程式看起來比較貼切我的工作，而建構這個字眼ㄚ琪其實很早就看見過，只是沒想到有這麼大的差異，好吧，下次要改用建構程式來自我介紹了，但是現在或許又要改成發育程式了，理由是程式要慢慢地漸進開發，這還真是酷的說法啊，但是我這樣自我介紹你會懂嗎？我自己都不太懂，也很難向人解釋。
偉大的設計師，繼續用我以前主管口頭語，『找對的人做對的事』，不管你在工作上或事工上，都要面臨這樣的抉擇，不管怎樣，制度還是沒法優先於人，所以是否能培養偉大的設計師，是否有方法，應該有人會感興趣，但是實際上，似乎不會有組織會花那麼多的心血在尋找和栽培偉大的設計師吧，嗯，成本應該不低，所以作者給出了個建議『每個軟體機構必須下定決心表明，傑出的設計人員和卓越的管理人員一樣重要，他們應該得到相同的培訓和報酬。不僅僅是薪資，還包括各個方面的認可——辦公室規模、安排、個人的設備、差旅費用、人員支持等——必須完全一致。』有這個宣言真酷，這樣ㄚ琪自然會努力學程式開發。
這裡也有養成偉大設計師的建議，『
- 盡可能早地、有系統地辨識出頂級的設計人才。最好的往往不是那些最資深的人員。
- 為設計人員指派一位職業導師，負責他們技術方面的成長，仔細地為他們規劃職業生涯。
- 為每個明日之星方面制訂和維護一份生涯成長計畫，包括與設計大師的、經過仔細挑選的學習過程、正式的高級教育和以及短期的課程——所有這些都穿插在設計和技術領導能力的培養安排中。
- 為成長中的設計人員提供相互交流和學習的機會。』
- 希望有這樣的伯樂，但是我想這不是作者要在這裡做討論，所以要看看以後有無章節討論。