这是人月神话：软体专案管理之道（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的函式库手册吧，历经了无数版别的开发，ㄚ琪觉得真的越来越厚了，难怪手册一直翻不完，甚至觉得买那么大本的手册要当枕头睡吗？可是又很难睡啊。
最后的结论，虽然很多人要反驳，但是作者一一地驳回，并且说形势没有改变，至于真的是否没有改变，ㄚ琪也无法评论，好像没办法继续写下去了，我想我还是继续用分享心得的方式来写下去，用学习的心态来看这本书，或许会比较快乐。