Software
Craftsmanship: The New Imperative
Pete McBreen 原著
书评作者 Glen B. Alleman 2001
年 10 月 2 日 Copyright © 2001
张恂 编译 （中文版已获授权） 2005 年 11 月
概述
《软件匠艺》提出了这样一种观点：即当代的软件开发者应当重溯传统工匠的根源，以应对今天日益复杂的软件开发状况。 McBreen 论证了建造软件系统需要更加广泛的技能和经验，而非仅仅包括读书、培训课程、方法论和 CASE 工具。在他提出的软件工匠样板（paradigm）中，学徒级软件开发者向技师学习的做法大体上与其他工匠行业的做法相似。
考虑到今天从 FAA、IRS 一直到 .com 等一系列系统的失败，以上的观点既很有意思，也很及时。 McBreen 把这些观点当作“软件工程方法”（SWE）的对立面提了出来，进而他把“软件工程”当作造成我们这个行业许多悲哀的罪魁祸首进行了谴责。
从前言开始， McBreen 就一直混淆了软件开发当中“工程”的一面与“软件制造”两个不同的概念。他援引的 1969 年 Naur 和 Randell 的 NATO 报告，不但已经过时，而且与今天的软件工程学科也有所不符。这种在多个章节中采用过时参考资料的做法给人留下了 McBreen 可能没有做好功课的印象。
在 McBreen 指责软件工程的论述中存在着一些有用的观点，然而他提到的许多问题大多是些似是而非的烟幕哑弹（worn red herrings）。他举的那个“大项目”的例子距今差不多已经有 20 多年了，而且对许多人而言这是个陌生的领域（世界上首个弹道导弹防御系统）。显然，在自 1975 年以来的这段时间内，人们应该学到了一点关于软件工程的知识。
McBreen 把向软件工程师颁发执照的问题当作软件工匠的潜在威胁，可是对于这个问题他显然没能提供平衡的观点，因为，向为紧要任务系统编写软件的处理系统工程师颁发执照的做法已经存在几十年了。也许考察一下欧洲的 TüV 和 SINTEF 法规，可以为我们美国处理类似的问题提供一些借鉴。
该书的一个缺陷是：它没能为讨论基于匠艺的软件开发建立一个语境。客户关系、开发过程、项目管理过程、成功和失败的例子等等，所有这些统统没有被放在一个具体的语境当中。为此，我推荐一个研究软件项目及其属性分类的地方： Caper Jones 等人的系列著作 [1] 。这些出色的文献广泛而深入地研探了软件开发的复杂性以及对于一个问题天真地采取“万能尺码”做法可能带来的风险。
McBreen 在该书中采取了“万能尺码”的做法。他声称不存在万能尺码，可是他却在没有给出具体问题领域的情况下向读者提供运用匠艺方法的建议和指导。我们知道，为拥有现场客户的一个商务应用开发“工匠”软件的过程，与为那些采用了 COTS 产品的跨国企业或那些被高度控管的企业开发软件的过程显然存在着显著的差别。
尽管该书内容颇丰，我对它所采用的材料，其来源（或来源的缺乏），以及笼罩在“新诫”之下的整个论调，不以为然。
前部章节
《软件匠艺》从回顾早期的软件工程开始，进而提出软件工程现已寿终正寝，如今是到了回归传统匠师/学徒制的时候了。 McBreen 以 1975 年完成的 SAFEGUARD 系统作为大规模软件工程的例证。可惜这个例子即非很适时，也不能代表现代大规模的软件开发。 SAFEGUARD 案例的确反映了那个年代软件工程师们遇到的众多挑战，然而当初的这些经验教训早已被几十年来的软件工程实践所吸纳。此外 SAFEGUARD 系统属于那些早期的“发现设计型”项目，它不但建造了新式的硬件，而且还发明了新式和创新的软件过程。
软件工程的问题
McBreen 提到的“大规模开发项目是系统工程项目”是一个重要的论点。那么，究竟多大的项目就不再是“编程”，而是“系统工程”呢？对一个开发过程的领域的定义在讨论开发方法及其应用中是相当重要的。该书虽然在下文中提到了不存在“万能的尺码”，但却忽视了对开发方法的讨论应不能脱离具体领域的语境。 McBreen 想当然地认为在系统工程项目中软件开发人员必须要等待硬件，而他显然忽略了今天在商务、政府、武器和航天等系统中广泛采用的 COTS 集成方法。
关于 Site Defense 这个案例，许多内容与现代系统工程过程的实际做法不符。一个更加恰当的开发特征描述是开发人员必须在满足客户的所有需要之前，等待某些软件（比如 SAP、Oracle、Siebel、JVM、应用软件库等）的下一个主发布。换一种说法是，开发人员必须等待获得针对系统所有活跃部件的一个整合特性集。这种情况在制造业中是相当典型的，人们往往发现 CAD、ERP、CRM 和其他基础设施系统似乎都在同时朝着不同方向发展。
McBreen 接着问到“软件工程是否是您项目的好选择？”，可是他却没有定义这个项目的领域或它的特征，甚至连一个很好的软件工程的定义也没有。有关软件工程定义的一个起点请看这里 [9] 。同时我也推荐把 Capers Jones 的软件项目分类法作为对于诸如“在什么领域中什么是一个合适的方法”讨论的一个起点。 McBreen 忽略的一个起点是他忘了去广泛地收集有关这个话题的定义。[2]
通过比喻来理解软件开发
第 3 章在“天下没有万能尺码”的思维下表达了对软件开发的一种理解。然而，针对这些问题所引用的参考资料的份量显然是不够的。Highsmith 和 Cockburn 的材料算是最新的，其他材料则都是 80 年代中期的。仅在一处引用了 Humphrey，却忽略了 Humphrey 大量的其他相关著作。事实上，对于“到底什么是软件工程？”这个问题，世面上存在着非常多的参考文献。非常糟糕的是， McBreen 只挑选了那些仅能得出软件工程方法（SWE）很糟而匠师/学徒制是其解药之结论的材料。
从第 4 章开始，McBreen 为全书的匠师/学徒制讨论奠定了基础。在说明软件开发具有知识协作的一面后，他提出软件开发其实是一种具有社会性的过程（参见 Cockburn 类似的观点），随后他插入了一段对 XP 的讨论，作为实践做法的例子。可惜，这样的处理无疑忽略了众所周知并广受欢迎的其他同样满足此类标准（社会化过程）的实践作法，包括某些企业内部方法（比如 IBM 的内部方法）以及其他轻载和敏捷过程等等。
我发现一个有趣的地方：虽然 McBreen 引用了多份期刊的文章，但这些文章好像是被随手挑来的（hand picked）。例如，该书写到
Laitnen 在 IEEE
Software 2000 年第 9-10 月刊 Point - Counter Point 栏目中对通过裁减过程来适合某个问题的讨论，遗憾的是
McBreen 忘了提及这篇文章的细节和其中的反面观点。这种把引用内容从其上下文中切割出来的做法对于一片普通文章或者会议报告可能是合适的，然而像一本书这样长度的作品显然需要更加平衡的观点。
第 4 章另一个有趣之处是 Paul MacCready 有关 Gossamer Condor 的谈话以及与软件开发的类比。MacCready
当初建造这架飞机的目标是为了赢得利用人力飞行器飞跃某段距离的这样一个奖项，故这架飞机只需要完成一件工作：由一个人来提供动力，在跑道上转两圈。这里还用到
Condor “无文档”的例子来取悦那些要求只写代码而不要写设计文档的软件开发者。
McBreen 对于飞机设计师总迷恋于在绘图板上创建完美设计的臆想是个彻头彻尾的错误。我觉得他应该在作出如此鲁莽的判断之前，花一点时间走访像波音这样的飞机制造商。那么，他将会看到在为一架商用客机的几乎每个部件进行的设计、测试和分析当中的 1000 多次迭代。作者这种风格一贯的表述遍及全书，却背离了其间那些真正有价值的材料。
本周的 Aviation Week & Space Technology 第 9.24.01 期杂志刊登了一篇有关 AirplanePDQ 的产品发布广告。该产品为试验型飞机的制作者提供了一组可用于生成设计图纸和文档的自动化工具以及大小计算和分析工具。显然，那种认为试验型飞机的建造者不但不做文档，而且还抛弃所有优秀工程实践做法的看法是无稽之谈。McBreen 应该去更加细致地调查一下设计、建造和维护哪怕是世界上最简易飞机的过程，我想他会发现这些飞机的制造的确采用了轻载过程，然而关键是存在这么一种过程，而且它是建立在成熟的工程实践基础之上的。
参照这个 Gossamer 飞机的类比，波音飞机建造者们的行为是否会与 MacCready 一致呢？当然不会。那些只想写代码而不想写文档的开发者们，在波音公司的实时飞行控制系统岗位上会受到欢迎吗？很可能也不会。可见，为一个类比设定必要的语境是相当有价值的。把
MacCready 的作品作为匠艺理论的基础，却不把他制作的这架飞机放入到一个语境当中，这样做忽略了重要的一点——在一个领域中学到经验能够被另一个领域复制吗？为了获奖，Gossamer
Condor 做到了载着一名非常健壮的自行车运动员沿着封闭跑道绕场一周，可是制造这种飞机的方法能够被拓展到其他领域中去吗？是啊，这可是个大问题，不是吗？
对
Condor 可维修性的讨论的确有趣，但我们不应忘记这只是一架试验机，而非产品机。所以，让我们延伸这样的类比 —— 试验软件或“一次性”软件与强壮的商业产品级软件有什么不同吗？恐怕差别不小。
第 4 章结尾处有关软件匠艺的复兴正在发生的揣测，同样也需要一个语境。精良的手工特制应用在一些行业中比较普遍，在其他行业中却可能较为少见。飞行控制软件，尽管是严格规范化的，但为了满足飞机设计师的需要，同样也可以进行手工特制（crafted）。对于特定的产品和过程，某些过程控制软件也可以进行手工特制。我曾经在高度严格的 TüV、SINTEF 框架的约束下为气涡轮控制设备开发软件。那些代码是在涡轮控制设备工程师的监护下小心的编写的，随后它们被作为嵌入式产品进行大批量的制作，并且配备了大量的文档、确认测试和检验文件。McBreen 提出软件工程对于此类结构化、规范化的领域不合适，这种泛扩大化的说法对于从事此类工作的人们而言无疑是一种伤害。
第二部分 何谓软件匠艺？
该书于第二部分开篇处声称：软件工程比喻的一个主要失败在于它始终没有把“人”放在软件开发过程的核心位置。可惜 McBreen 没有弄清软件工程理论与其应用或不恰当应用——误用的区别。我想只要稍微翻一翻 SEI 的文献，McBreen 就能发现研讨这个问题的大量会议论文和书籍。
事实上，从 Jones 一直到 DoD （美国国防部）的规划者们，几乎所有的作者都在谈论软件开发过程中“人性”的元素。把自然语言处理的失败归罪于软件工程其实是一种烟瘴（red herring）。需求引导无疑是一个复杂的、领域相关的过程。从与程序员们在同一间屋子里工作的客户那里获得需求，显然不同于从一家横跨三大洲的企业级客户那里获取价值三千万美金的 ERP 系统项目的需求。这里 McBreen 再一次没能为“软件匠艺优于软件工程”这一笼统论述设定一个有效的上下文。
在并无材料佐证的情况下，McBreen 发表了不少其他的笼统观点。“工程曾长期依托于手工艺传统... 并在最近的几十年间才逐渐发展为学院传统” 果真如此吗？难道十九世纪末英国的桥梁建造者们没有掌握压力和横梁计算的学院传统？接着 McBreen 又抨击学术流程，声称数学模型并不符合现实，因而需要所谓的工匠们来填补空白。
建议 McBreen 更加深入地读一点关于 SAFEGUARD 项目的材料，我想他将会发现建模与仿真恰恰被认为是导致该项目成功的两个主要因素。如此重要的一本书，不应容忍这种反学术的处理方式，草率地忽略原本可以为我们这门学科添加价值的重要材料。
重归人本软件开发
第 5 章阐述了如今的业态（McBreen 并没有讲具体哪一种，所以在这里我只好泛指）如何妨碍劳动者成为真正的程序员，并且造成了哪些不良后果。CASE （计算机辅助软件工程）被描绘成导致这些失败以及程序员的工业化、技能丧失的一个根源。可是 McBreen 并没有为这些揣测提供正式的引用，所以我们很难区分这到底是整个国家的潮流趋势，还是私人的个别体验。
该章的后部呼吁人们拿起武器来战斗（call to arms ，其实我更喜欢“采取行动”—— call to action 的说法，因为商业行为与军事行动毕竟是两码事）。所谓的“采取行动”是指在我们信任程序员，让他们为我们或与我们一道开发系统之前，应该坚决确保他们真正掌握了自己的手艺。这里如果没有讲清语境，有人很可能会急迫地去寻找如今哪个行业不符合这条宗旨。我想第一个可以考虑的地方大概是 .com 业。
自然选择过程在清理由训练不良的软件工程师制造的混乱方面发挥了作用。在我所从事的 ERP 和实时系统领域中，允许一个未经严格训练的开发团队来浪费客户或投资者的钱财是相当罕见之事。这种事情的确有可能发生，但通常都会引发灾难性的后果。ERP 起步的时候在集成上面花了过多的钱，这比较普遍，但后来人们学会了如何控制需求的蔓延以及如何把用于开发的美元真正花在可度量的生产力改进之上。我看 McBreen 的大部分顾虑其实应该报告给企业的管理层而不是开发人员（至少在本章中应如此） ，因为制定部署缺乏经验团队的决策根源在于不合理的管理过程。
正如设计建造其他任何复杂的产品一样，“编程是一门手艺”的说法有其合理性。的确需要技能和经验。“即便世界上最好的过程也无法挽救一个注定要失败的项目...”等等说法也是显而易见的。这里还引用了 Hightsmith 的评述，而它们对于成功的组织而言也是明白无误的。
软件执照的烟瘴
第 6 章最终发展成对颁发软件执照的恶骂。如果该话题出现在一本商业期刊中，可能还有点意思，可是如果冒险把它作为正规图书的篇章，恐怕早在该书面世之前就该枪毙它。我在读第一遍的时候就跳过了此章，而且在读第二遍的时候也打算这么做。
看来此话题将挥之不去，继续引发持续不断的讨论。不过与此同时，正如 McBreen 在本书中所建议的，一些新鲜的、有趣的有关如何提供制作和确保高质量软件的有效方法的问题也将会层出不穷。
匠艺对软件开发过程的改变
第 7 章由摆出有关产品及其可维修性的误导性观念开始。McBreen 声称由机器——而非工匠们——制作的产品丧失了可维修性。我猜他在这里大概排除了汽车、计算机、房屋、飞机、服装以及其他无数的我们日常所使用的非易耗品。这种泛扩大化的论调简直让作者提出的其他一些重要想法也大打折扣。
接着 McBreen 提出假说认为，软件匠艺是可行的，因为软件容易拷贝。可是复制产品的部件明显是大批量生产系统所为，而非 McBreen 一直宣称的要我们前进的方向。当 McBreen 提出塑包的、适时入市的、足够好的软件以及软件膨胀理论时，工匠模式与大批量生产之间的市场动因的差别突然变得让人困惑了。他还把“工匠与用户的关系有所不同”作为某节的标题。可什么用户呢？是那一千万名塑包软件的用户？我想非也。是那个与开发人员待在一间屋子里的用户吗？恐怕是也。是一个嵌入式 OEM 构件三层之外的用户吗？恐怕非也。到底是哪些用户呢？他没有说。
由 Alan Cooper [3] 的“为单个用户设计”理念而引发的臆断，应该与 IBM、HP、Microsoft 等企业的产品营销战略相检验。软件产品在范围和功用方面皆具有极大的广度和深度。作者没有为这种泛泛的援引提供具体的语境，导致我们很难判断他的相关结论是否成立以及在何处成立。
所谓的 sold as is licenses 的想法并不能很好地解决与软件产品开发相关的法律问题。如果 McBreen 在建议我们采用工匠式的担保来将软件产品卖给大众之前，能够援引一下商业产品担保与责任的有关问题，那么他的论述恐怕会更加令人信服。一直有许多人反对软件开发公司化的做法，然而二十一世纪初的大型软件商业结构与十九世纪的作坊工业显然有所不同。
事实上 McBreen 恐怕真的期望两者是一样的，这本书给出了让我们回归到这样一种业务模型的理由，而这一章的大部分内容也让我得出了同样的结论。这种想法确实很有趣，而且可能是当今许多敏捷和轻载开发过程的核心思想。由于我的工作背景主要来自于大型环境，它们大多受到政府机构或风险补偿过程（risk indemnification processes）的管制，如石化、电力、制造等行业，所以，这一见解已经超出了我的关注范围，目前我也无法判断究竟这一道路——抛弃了现代企业结构的工匠制——最终能不能成功。
客户的角色
第 8 章的标题是“客户与工匠之间是一种新型关系”，的确如此。然而工匠制处理客户关系的做法，其适用面能否扩展到面对面互动的客户-开发者共处团队之外呢？如何应对全球市场下的软件开发？如何应对 OEM、ISV 或基于产品环境下的软件开发？在那些环境当中，很多时候不但现场客户是不可能的，甚至开发人员连谁是客户都不知道。McBreen 采取了 XP 的做法，拥有一位身旁的客户当然比没有好——这是显而易见的，可是他没有给出在什么情况下——不论多么理想——这么做是不可能的建议。
该章对“足够好软件”之失败的讨论是对其他表述、书籍的重复。过去许多文献已经探讨过该问题，并得出了类似的结论。这里的新意并不太多，因为市场驱动力依然在很大程度上制约着良好开发实践的采用。然而，作为消费者，我们创造出了长着两个脑袋的大师。我们不但要求产品更快，更便宜，具备更多的特性，而且还要求它们没有臭虫，能够免费升级。这不啻于一场市场营销人员的恶梦。我不明白这章的客户是指谁，是终端用户，内部开发机构，还是承包商？无论何种情况，市场压力都是巨大的。追求“更快、更好和更便宜”的后果是要求我们为此付出远比动动嘴皮子更多的努力。
接下去该章对工匠与客户互动关系的讨论也很有意思，包括：雇用小团队的开发者，要像工匠从事定制工作那样来个性化地管理他们，根据他们的实际技能而非市场统一标准来支付报酬，度量他们的交付成果，以及让客户主动作出成本/质量的权衡等等。在一个非常正规的组织中尝试实施这一战略恐怕颇具挑战性，过于简化的岗位描述和严格的劳工法规很有可能构成实施障碍。这并非说以上目标在当今迅速变化的环境中不具有宝贵的价值，然而我们的作者在这里再次没有讨论这些做法适用的环境。
管理工匠
McBreen 有关工匠具备专业的技能并应据此管理的论述似乎与 XP 所倡导的 everyone knows everything about the project（所有人知道项目的所有情况）理念相矛盾。该章对 ASD （敏捷软件开发）理念与 XP 理念的混淆也让人感到些许困惑。让客户与工匠保持长期关系的提法，再次有必要给出具体的语境，我想向客户提供产品的现实状况可以为这里的讨论奠定基础。现代商业企业一般通过分销商、零售商或者集成商与客户建立间接的联系，或至少要通过一个客户服务部门。让软件开发人员与客户直接打交道在商务上并非总是合理的。许多软件公司的客户支持部门通常与客户保持着直接联系，并让与其一臂之遥的开发人员可以随时听从召唤。所以，作者在提倡客户交互新模型的同时有必要对客户支持经济面的改变进行探讨，可惜我们没能看到。
在第 13 章的中间我们又发现了一个武断（out of the blue）的论断：“技师们几乎从来不独立工作”。这是说谁呢？有关的背景引用资料又在哪里呢？作者这种不断制造观点的做法，说穿了还是——“制造观点”。所以，我觉得该书需要一位更加认真的编辑来清除杂草，或至少找一些引用和论据来支撑作者的臆断。
重现定位软件工程
McBreen 声明，匠艺并非要取代软件工程，而是对软件工程的补充。既然如此，那么所有这些对软件工程的泼污，指责它如何、如何地不适于现代软件开发，又作何解释？McBreen 声称人们发明软件工程就是为了建造真正大型的、耗时多年的系统开发项目，比如航空交通管制系统。这无疑是错误的、不完整的，这些具有误导性的、提供了错误信息的笼统陈述再次玷污了该节中其他原本有价值的内容。事实是大规模的开发项目恰恰需要创新的解决之道，比如匠艺式的程序员，真正的挑战是如何把这些新颖的做法与结构化的做法整合起来。可惜 McBreen 在这方面没有提供任何建议。
第 14 章启动了给软件工程重新定位的话题。McBreen 所谓的瀑布式是占据主导地位的开发方法缺乏事实依据的支持。他把岗位描述与开发方法绑到一起，有趣的想法，可同样缺乏任何实践证据。看一看 Capers Jones [1] 的调查数据，我们可以发现为各个行业所采用的大量开发方法和最佳实践。Royce 的著作《软件项目管理》[6] 是我们了解商业、工业公司如何开发软件的一个更好起点，而 Ambler 的两本软件模式系列著作 [7] 则是我们了解商业产品开发者如何开展工作的另一个很好的起点。
McBreen 使用统计数据的方式非同一般。他声称一个小项目大概为 100 人年，而一个大项目大概是 10,000 人年。McBreen 没有提供这些数字的来源，全然不像 Capers Jones 在 1995-1999 年期间所进行的调查。Jones 的数据涵盖了 5 到 20 人的项目。全面细致地读完 Jones 的著作之后，我们可以发现虽然项目的各种形态随着业务领域的不同而有所变化，但各个项目团队的大小分布相对而言是很窄的。
软件工程比喻的危险
第 15 章声称“软件工程对于某些项目来说可能是合适的，然而对于大多数商业软件的开发者而言，它并非一种合适的选择。”对于这里所谓的“商业软件开发者”，我猜 McBreen 大概是指销售给公众的软件（译注：读者可以考虑一下微软公司二十年来是如何通过软件工程发展壮大并赚钱的）。事实上，如果 McBreen 的本意是指机构的内部开发或具有特定目的的（purpose built）开发项目，那么这句话可能还有些道理。由于没有引用材料来支撑这种推测，所以我只能认为这仅仅是作者的一种主观看法。
接着，McBreen 援引了 NASA 关于“更快、更好、更便宜”的项目管理方法的报告。他在脚注中列举了该项研究，我建议读者们顺着链接找到那份完整的报告以及关于 MCO Mishap 的第一阶段报告，这两篇报道都把“人”列为确保任务成功的最重要因素，全然不像 McBreen 所描绘的那种软件工程实践。
McBreen 关于软件工程排斥经验证据（anecdotal evidence）的揣测无疑是错误的。例如，航天飞机建造业正是基于四种过程：标准化的（Normative）过程、理性的（Rational）过程、积极参与的（Participative）过程以及探索的（Heuristic）过程。如果 McBreen 先生在泛泛地得出“软件工程排斥经验证据”的结论之前，能够阅读一下 Rechtin [8] 关于航天飞机行业系统架构的有关书籍，他的作品恐怕更能令人信服。此外，MCO 报告原本长达 200 多页，并且还有几十项主要建议，McBreen 却根据自己的需要把这些结论浓缩成了只有两段话。即便这些报告的某些部分有充当政治工具的嫌疑，然而刻意“简化”其成果无疑是对行业专业精神的一种伤害。
McBreen 对阿里亚娜 5 号软件重用方面的讨论具有误导性。他引用的是一篇事故分析早期发布的新闻稿，可我们只要多花一点力气就可以找到大量的其他有关报告，更全面深入的材料读者可以参见 [4]。McBreen 的结论看似与这些更详尽的报告相吻合（浮点转换错误），然而阿里亚娜 5 号的真正问题是不恰当地加入了其飞行控制配置库当中的软件。从来就不该运行产生这一错误的软件，正是该配置管理问题最终导致了浮点转换错误。后来进一步的报告找到了 6 项错误：
- 未保护应进行差错处理的代码；
- 含有发射后无用的代码；
- 阿里亚娜 5 号的高初始加速度使得其累加起来的水平速度要比阿里亚娜 4 号快 5 倍，从而导致转换的变量溢出；
- 发生浮点转换错误后两个（冗余）处理器全部停机的根源在于阿里亚娜火箭的设计文化。该文化专注于可被执行同一软件的冗余硬件处理的随机错误，然而它却无法处理共因差错（CCF，Common Cause Fault）。NASA 航天飞机及容错过程控制系统均对这一状态进行了细致的处理。关于 CCF 相关问题及发生此类错误时的容错诊断等总体介绍可以参见 [5]；
- 在阿里亚娜 5 号发射前没有对含有错误的软件进行复测，而任务紧要系统中的重用同样也需要复测；
- 1992 年的时候由于认为 SRI 是完全合格的，所以决定把它们从测试循环中去掉。同时，不对真实设备进行失效模态的仿真，而只对模型进行仿真。事后证明这两项决策都是错误的。
McBreen 先生通过对阿里亚娜 5 号失败原因过度简化的分析，来支持其“重用在某种程度上是软件工程的最糟糕之处”的论点，此种报道手法在时尚传媒界并非鲜见。而事实上，阿里亚娜真正的失败原因与该项目特殊的软件管理规程有关，看来只有通过更加深入的研究，McBreen 才能让他的读者真正满意。
向软件工程学习
第 16 章探讨了如何向软件工程学习。在“size matters”这一段落中，McBreen 指出匠艺项目为 10 到 20 人年，然而 Jones 采集了广泛的从商用系统直到国防系统的不同应用领域数据 [1]，这些项目的工作量几乎是相同的（译注：这里说明了是否适用软件工程其实与项目的大小、类型无关）。McBreen 声称软件工程项目的规模为前者的 50 到 100 倍，却没有给出这些数字的依据。 接着，他把 SAFEGUARD 项目的数据作为估算的例子。既然该引用材料是 10 年前的，而该项目距今也已 20 多年，那么我们可以期待找到一个更时新的有关估算失败的实例，比如我会建议以 IRS、FAA 和 AX 飞机项目为例。
在我第二遍读此书的时候，到了这里，我便开始跳着读了。由于我出生于开发武器系统和实时容错产品，当看到 McBreen 先生对阿里亚娜 5 号案例中造成差错的真正原因缺乏理解，以及不恰当地运用其论著中的这一信息来得出应该用匠艺实践取代软件工程实践的结论时，我还是有所反应（对于一名评审者来说，这大概不是一种好的性格）。
第 17 章回顾了优良项目管理的一些指导方针，经理们应该反复地阅读这些内容。可惜 McBreen 在这里再一次地援引了 Borland 的匠艺项目。如果作者引用的材料更广泛些，就可以让读者拥有更好的基础来作出评判。这只是一点小小的批评，但反映出这本论著的视野恐怕偏窄。由于 Borland 项目采用代码行数而非功能点作为生产率指标，所以我们很难把该结果与更加丰富的 Jones 数据进行比对。推荐一本较新的项目管理指南：Anti-Patterns in Project Management , Brown, McCormick III, and Thomas, John Wiley & Sons, 2000。
第 18 章亮出了最令人难以置信的观点：“Java 有害于你的项目健康。Java 太新了，而且它是私有的”。我估计 McBreen 肯定没有做好功课，要么就是他的观点太偏激了，以至于他的读者们看到这条消息一定会惊呆的。我最近刚刚做完了一个很大的 CORBA/Java 项目，我可以作证 Java 是这个项目成功的主要贡献者。McBreen 列举的那个国际化及相关问题的例子好笨：他声称自己的浏览器能正确显示英文页面，但在显示日文页面的时候却让人想起了线路噪声。我建议他把浏览器自带的日文字符集装上——不就全都清楚了吗？（假定他懂日文）
该章提出的外包问题反映了真正的问题。人们发现，如果有一份清晰简洁的需求规约，外包往往能取得成功；没有这样一份规约，则会出现问题。如果坚持把软件匠艺作外包的解决方案，我想问——如果一位工匠（如 MacCready 那样）不怎么写文档，并且依赖于和客户的直接接触，那么这样的外包流程又如何进行下去呢？外包有时候是在别的大陆上由讲他国语言的熟练程序员完成的。如果外包的供应方要介入一个项目从需求直到生命周期支持的所有阶段，那么外包的定义已经被改变了。
结论与建议
我发现此书的确能够激发人们进行深入思考，尽管有时我在看到作者类似于上面的 Java 评论时总感到困惑。理解上的巨大差异可能是由于 MacBreen
缺乏那些领域的相关经验造成的，而这些差异很容易通过调查研究被填平。我认为这些差异还可能是由存在着缺陷的编辑审校造成的，不过那完全是另外一个问题了。
我乐意推荐此书，不过附带着一些保留和提醒。建议读者尽量把该书提出的观点放到一个适当的语境中，并问自己：这些观点适合我的领域吗？其中的一些想法适用于我遇到的具体问题吗？书中某个论点从我本人的经验和别人的经验来看真的合理吗？我是否在同事们相互传看的杂志中读到过类似的看法，或者这些观点根本就是作者刀劈斧砍之下的成果？
McBreen
向 SEI、Jones、Coplien、Highsmith、Cockburn 等表达了谢意, 然而在此书中他似乎忽略了先贤们的绝大部分贡献，把它们都遗忘在了书架上。
一些相左的观点
McBreen 的论著在科学的调查研究方面乏善可陈。当然这是我个人的看法，主要是因为我所受到的培训和工作经历主要来自于“硬科学”（分子物理实时数据分析和雷达/声纳信号处理等）。McBreen 认为软件界现在需要一种新方法，其他许多人也同样想到了。这里有几个链接可以填补空白：
- 国际软件工程网宣言 - http://www.iese.fhg.de/network/ISERN/pub/isern.manifesto.html 介绍了为改进软件工程方法实践需要作出哪些改变。
-
有用的资源：“软件工程的未来” - http://www.softwaresystems.org/future.html
既然 McBreen 很可能没有航天器设计领域的工作经历，那么有关阿里亚娜 5 号事实报道方面的缺陷是可以理解的。而那种认为 Java 用于商用开发令人无法接受的主张就显得很古怪了，McBreen 不是一直把自己定位为 OO 技术的先进培训教员吗？
参考文献
[1] Software Assessments, Benchmarks, and Best Practices , Capers Jones, Addison Wesley, 2000 以及 Assessment and Control of Software Risk , Capers Jones, Prentice Hall, 1994.
[2] 软件工程的定义其实有许多种，自然也有网站收集了这些定义。这里就是一个有助于本文讨论的链接 http://wwwsel.iit.nrc.ca/sedefn/SEdefn.html 你可以发现 McBreen 采用的 IEEE 定义仅是其中的一个，而且有点老了。
[3] 逃出疯人院, Alan Cooper, SAMS, 1999.
[4] http://www.niwotridge.com/Resources/Ariane5Failure.htm 通过指向阿里亚娜 5号材料的链接可以找到一份更专业的技术报告调查。可以发现有的时候，媒体们，甚至是技术媒体，在报道一个复杂的专题时造成的信息误导是多么令人震惊。
[5] http://www.niwotridge.com/PDFs/Fault%20Tolerance.pdf (860K). 参见 pp. 93 关于此复杂话题的概要讨论。
[6] 软件项目管理, Walker Royce, Addison Wesley, 1998.
[7] Process Patterns 以及 More Process Patterns , Scott Ambler, Cambridge University Press, 1998 and 1999.
[8] 软件架构艺术, 第 2 版 , Mark Maier and Eberhardt Rechtin, CRC Press, 2000. 该书的第一版发表于 1997 年。在新版中加入了有关分布式系统的新材料。Rechtin 是航天器设计过程的一个主要贡献者。