将辩论推回到40年前是不合理的，在1952年，甚至很难想象开发的次要问题不会占据开发工作的主要部分。
其次，Harel所设想50年代行业所处状态是不准确的：
当时已经不是构建大型复杂系统的时代，程序员的工作模式已经成为常规个人程序的开发（在现代的编程语言中，大概是100～200行代码）。在已有技术和方法学的前提下，这些任务是令人恐怖的，处处都是错误、故障和落后的完成期限。
接着，他阐述了在传统的小型个人程序中，那些假设的错误、故障和落后的最终期限如何在接下来的25年中，得到数量级的改进和提高。
但是，50年代该领域的实际情况并不是小型个人程序。在1952年，Univac还在使用大约8人开发的复杂程序处理1950年的人口普查13。其他机器则用于化学动力学、中子漫射计算、导弹性能计算等等14。汇编语言、重定位的链接和装载程序、浮点解释系统等，还经常被使用15。1955年，人们开发50～100人年的商用程序16。1956年，通用电气在路易斯维尔的设备车间使用着超过80,000指令的薪资系统。1957年，SAGE ANFSQ/7防空计算机系统已经运转了两年，这个系统分布在30个不同的地点，是基于通讯、自消除故障的热备实时系统17。因此，几乎无法坚持说个人程序的技术革命，能够用来描述1952年以来的软件工程上的努力。
银弹就在这里。Harel接着提出了他自己的银弹，一种称为“香草（Vanilla）框架”的建模技术。文中并没有对方法提供足够评估的详细描述，不过给出了一些论文和参考资料18。建模所针对的确实是软件开发的根本困难，即概念性要素的设计和调试，因此Vanilla框架有可能是革命性的。我也希望如此。Ken Brooks在报告中提到，在实际工作中应用时，它的确是一种颇有帮助的方法学。
不可见性。Harel强烈地主张软件的概念性要素本质上是拓扑的，这些关系可以用空间/图形方式来自然地表达：
适当使用可视化图形可以给工程师和程序员带来可观的成效。而且，这种效果并不仅仅局限于次要问题，开发人员思考和探索的质量也得到了改进。未来的成功系统的开发将围绕在可视化图形表达方式的周围。首先，我们会使用“合适的”实体和关系来形成概念，然后表达成一系列逐步完善的模型，不断地系统化阐明和精化设计概念。模型用若干可视化语
言的适当组合来描述，它必须是多种语言的组合，因为系统模型具有若干方面的内容，每方面象变戏法般产生不同类型的思维图像。
就使自己成为良好可视化表达方式而言，建模过程的某些方面并不会立刻出现改观。例如，变量和数据结构上的算法操作可能还是会采用文字性描述。
我和Harel颇为一致。我认为软件要素并不存在于三维空间中，因此并不存在概念性设计到图形简单两维或三维上的映射。他承认，我也同意——这需要多种图形，每种图形覆盖某个特定的方面，而且有些方面无法用图形来表达。
Harel采用图形来辅助思考和设计的热情彻底地感染了我。我一直喜欢向准程序员提问，“下个十一月在哪？”如果觉得问题过于模糊，接着我会问，“告诉我，你自己关于时间历法的模型。”优秀程序员具有很强的空间想象能力，他们常常有时间的几何模型，而且无需考虑，就能理解第一个问题。他们往往拥有高度个性化的模型。
Jone的观点——质量带来生产率
Capers Jones最开始在一系列备忘录里，而后在一本书里，提出了颇有洞察力的观点。很多和我有书信往来的人向我提到了他的观点，《没有银弹》如同当时的很多文章，关注于生产率——单位输入对应的软件产出。Jone提出，“不。关注质量，生产率自然会随着提高。19”他认为，很多代价高昂的后续项目投入了大量的时间和精力来寻找和修复规格说明中、设计和实现上的错误。他提供的数据显示了缺乏系统化质量控制和进度灾难之间的密切关系。我认同这些数据。不过，Boehm指出，如果一味追求完美质量，生产率会像IBM的航天软件一样再次下降。
Coqui也提出相似的主张：系统化软件开发方法的发展是为了解决质量问题（特别是避免大型的灾难），而不是出于生产率方面的考虑。
但是注意：70年代，在软件生产上应用工程原理的目标是提高软件产品的质量、可测试性、稳定性以及可预见性——而不是软件产品的开发效率。
在软件生产上应用工程原理的驱动力是担心拥有无法控制的“艺术家们”而可能导致的巨大灾难，他们往往对异常复杂系统开发承担责任20。
那么，生产率的情形如何？
生产率数据。生产率的数据非常难以定义、测量和寻找。Capers Jones相信两个相隔十年、完全等同的COBOL程序，一个采用结构化方法开发，另一个不使用结构化方法，它们之间的差距是3倍。
Ed Yourdon说，“由于工作站和软件工具，我看到了人们的工作获得了5倍的提高。”Tom DeMarco认为“你的期望——十年内，由于所有的技术而使生产率得到数量级的提高——太乐观了。我没有看到任何机构取得数量级的进步。”
塑料薄膜包装的成品软件——购买，而非开发。我认为1986年《没有银弹》中的一个估计被证实是正确的：“我相信，这个大众市场是 软件工程领域意义最深远的开发方向。”从学科的角度说，不管和内部还是外部客户软件的开发相比，大众市场软件都几乎是一个崭新的领域。当软件包的销量一旦达到百万或者即使只是几千，这时关键的支配性问题就变成了质量、时机、产品性能和支撑成本，而不再是对于客户系统异常关键的开发成本。
创造性活动的强大工具。提高信息管理系统（MIS）编程人员生产率最戏剧化的方法是到一家计算机商店去，购买理应由他们开发的商业成品。这并不荒唐可笑。价格低廉、功能强大的薄膜包装软件已经能满足要求，而以前这会要求进行定制软件包的开发。比起复杂的大型产品工具，它们更加像电锯、电转和砂磨机。把它们组合成兼容互补的集合，像Microsoft Works和集成更好的Claris Works一样，能够带来巨大的灵活性。另外，象供人们使用的组合工具箱，其中的某些工具会经常被使用，以致于熟能生巧。这种工具必须注重常人使用的方便，而不是专业。
Ivan Selin，美国管理系统公司主席，在1987年曾写信给我：
我有些怀疑你的关于软件包没有真正地改变很多 的观点。我觉得你太过轻易地抛开了你的观察所蕴涵的事实；你观察到——[软件包]“可能比以前更加通用和更加容易定制一些，但并不太多。”即使在表面上接受了这种论述，我相信用户察觉到软件包更加通用和易于本地化，这种感觉使用户更容易接受软件包。在我公司发现的大多数情况中，是[最终用户]，而不是软件人员，不愿意使用软件包，因为他们认为会失去必要的特性或功能。因此，对他们而言，易于定制是一个非常大的卖点。
我认为Selin是十分正确的——我低估了软件包客户化的程度和它的重要性。
面向对象编程——这颗铜质子弹可以吗？
本章一开始的描述提醒我们，当很多零件需要装配，而且每个零件可能很复杂时，如果它们的接口设计得很流畅，大量丰富的结构就能快速地组合在一起。
使用更大的零件来构建。面向对象编程的第一个特征是，它强制的模块化和清晰的接口。其次，它强调了封装，即外界无法看到组件的内部结构；它还强调了继承和层次化类结构以及虚函数。面向对象还强调了强抽象数据类型化，它确保某种特定的数据类型只能由它自身的相应函数来操作。
现在，无需使用整个Smalltalk或者C++的软件包，就可以获得这些特点中的任意一个——其中一些甚至出现在面向对象技术之前。面向对象方法吸引人的地方类似于复合维他命药丸：一次性（即编程人员的培训）得到所有的好处。面向对象是一种非常有前途的概念。
面向对象技术为什么发展缓慢？《没有银弹》后的九年中，对面向对象技术的期望稳步增长。为什么增长如此缓慢？理论过多。James Coggins，已经在The C++ Report做了四年 “The best of comp.lang.c++”专栏的作者，他提出了这样的解释：
问题是O-O程序员经历了很多错综复杂混乱的应用，他们所关注的是低层次，而不是高层次的抽象。例如，他们开发了很多象链表或集合这样的类，而不是用户接口、射线束模型或者有限元素模型。不幸的是，C++中帮助程序员避免错误的强类型检查，使得从小型事物中构建大型物体非常困难21。
他回归到基本的软件问题，主张一种解决软件不能满足要求的方法，即通过客户的参与和协作来提高脑力劳动的规模。他赞同自顶向下的设计：
如果我们设计大粒度的类，关注用户已经接触的概念，则在进行设计的时候，他们能够理解设计并提出问题，并且可以帮助设计测试用例。我的眼科客户并不关心堆栈，他们关心描述眼角膜形状的勒让德多项式。在这方面，小规模的封装带来的好处比较少。
David Parnas的论文是面向对象概念的起源之一，他用不同的观点看这个问题。他写信给我：
答案很简单。因为[O-O]和各种复杂语言的联系已经很紧密。人们并没有被告诉O-O是一种设计的方法，并向他们讲授设计方法和原理，大家只是被告知O-O是一种特殊工具。而
我们可以用任何工具写出优质或低劣的代码。除非我们给人们讲解如何设计，否则语言所起的作用非常小。结果是人们使用这种语言做出不好的设计，没有从中获得什么价值。而一旦获得的价值少，它就不会流行。
资金的先行投入，收益的后期获得。面向对象技术包含了很多方法学上的进步。面向对象技术的前期投入很多——主要是培训程序员用很新的方法思考，同时还要把函数打造成通用的类。我认为它的好处是客观实在的，并非仅仅是推测。面向对象应用在整个开发周期中，但是真正的获益只有在后续开发、扩展和维护活动中才能体现出来。Coggin说：“面向对象技术不会加快首次或第二次的开发，产品族中第五个项目的开发才会异乎寻常的迅速。22”
为了预期中的，但是有些不确定的收益，冒着风险投入金钱是投资人每天在做的事情。不过，在很多软件公司中，这需要真正的管理勇气，一种比技术竞争力或者优秀管理能力更少有的精神。我认为极度的前期投入和收益的推后是使O-O技术应用迟缓的最大原因。即使如此，在很多机构中，C++仍毫无疑问地取代了C。
重用的情况怎样？
解决软件构建根本困难的最佳方法是不进行任何开发。软件包只是达到上述目标的方法之一，另外的方法是程序重用。实际上，类的容易重用和通过继承方便地定制是面向对象技术最吸引人的地方。
事情常常就是这样。当某人在新的做事方法上取得了一些经验，新模式就不再象一开始那么简单。
当然，程序员经常重用他们自己的手头工作。Jone提到：
大多数有丰富经验的程序员拥有自己的私人开发库，可以使他们使用大约30％的重用代码来开发软件。公司级别的重用能提供70％的重用代码量，它需要特殊的开发库和管理支持。公司级别的重用代码也意味着需要对项目中的变更进行统计和度量，从而提高重用的可信程度23。
W.Huang建议用责任专家的矩阵管理来组织软件工厂，从而培养重用自身代码的日常工作习惯24。
JPL的Van Snyder向我指出，数学软件领域有着软件重用的长期传统：
我们推测重用的障碍不在生产者一边，而在消费者一边。如果一个软件工程师，潜在的标准化软件构件消费者，觉得寻找能满足他需要的构件，进行验证，比自行编写的代价更加昂贵时，重复的构件就会产生。注意我们上面提到的“觉得”。它和重新开发的真正投入无关。
数学软件上重用成功的原因有两个：（1）它很晦涩难懂，每行代码需要大量高智商的输入；（2）存在丰富的标准术语，也就是用数学来描述每个构件的功能。因此，重新开发数学软件构件的成本很高，而查找现有构件功能的成本很低。数学软件界存在一些长期的传统——例如，专业期刊和算法搜集，用适度成本提供算法，出于商业考虑开发的高质量算法（尽管成本有些高，但依旧适度）等——使查找和发现满足某人需要的构件比其他很多领域要容易。其他领域中，有时甚至不可能简洁地提出明确的要求。这些因素合在一起，使数学软件的重用比重新开发更有吸引力。
同样的原因，在很多其他领域中也可以发现相同的重用现象，如那些为核反应、天气模型、海洋模型开发软件的代码编制工作。这些领域都是在相同的课本和标准概念下逐步地发展起来的。
现在公司级别的重用情况如何？存在着大量的研究。美国国内的实践相对较少，有报道声称国外重用较多25。
Jones报告，在他公司的客户中，所有拥有5000名以上程序员的机构都进行正式的重用研究，而500名以下程序员的组织，只有不到10％着手重用研究26。报告指出，最具有重用潜质的企业中，重用性研究（而非部署）“是活跃和积极的，即使没有完全成功。”Ed Yourdon报告，有一家马尼拉的软件公司，200名程序员中有50名从事供其他人使用的重用模块的开发，“我所见到的个案非常少——是由于机构上因素而进行重用研究，而不是技术上的原因”。
DeMarco告诉我，大众市场软件包提供了数据库系统等通用功能，充分地减轻了压力，减少了处在重用模块边缘的开发。 “不管怎样，重用的模块一般是一些通用功能。”
Parnas写道：
重用是一件说起来容易，做起来难的事情。它同时需要良好的设计和文档。即使我们
看到了并不十分常见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。
Ken Brooks关于预测产品通用化的一些困难的评论：“我不断地进行修改，即使在第五次使用我自己的个人用户界面库的时候。”
真正的重用似乎才刚刚开始。Jones报告，在开放市场上仅有少量的重用代码模块，它们的价格在常规开发成本的1％～20％27。DeMacro说：
对整个重用现象，我变得有些气馁。对于重用，现有理论几乎是整体缺乏。时间证明了使模块能够重用的成本非常高。
Yourdon估计了这个高昂的费用：“一个良好的经验法则是可重用的构件的工作量是‘一次性’构件的两倍。28”在第一章的讨论中，我观察到了真正产品化构件所需的成本。因此，我对工作量比率的估计是三倍。
显然，我们正在看到很多重用的形式和变化，但离我们所期望的还远，还有很多需要学习的地方。
学习大量的词汇——对软件重用的一个可预见，但还没有被预言的问题
思索的层次越高，所需要处理的基本思考要素也就越多。因此，编程语言比机器语言更加复杂，而自然语言的复杂程度更高。高级语言有更广泛的词汇量、更复杂的语法以及更加丰富的语义。
作为一个科目，我们并没有就程序重用的实际情况，仔细考虑它蕴涵的意义。为了提高质量和生产率，我们需要通过经过调试的大型要素来构建系统，在编程语言中，这些函数的级别远远高于语句。所以，无论采用对象类库还是函数库的方式，我们必须面对我们编程词汇规模彻底扩大的事实。对于重用，词汇学习并不是思维障碍中的一小部分。
现在人们拥有成员超过3000个的类库。很多对象需要10到20个参数和可选变量的说明。如果想获得所有潜在的重用，任何使用类库编程的人员必须学习其成员的语法（外部接口）和语义（详细的功能行为）。
这项工作并不是没有希望的。一般人日常使用的词汇超过10,000个，受过教育的人远
多于这个数目。另外，我们在自然而然地学习着语法和非常微妙的语义。我们可以正确地区分巨大、大、辽阔、大量和庞大。人们不会说：庞大的沙漠或者辽阔的大象。
对软件重用问题，我们需要研究适当的学问，了解人们如何拥有语言。一些经验教训是显而易见的：
人们在上下文中学习，所以我们需要出版一些复合产品的例子，而不仅仅是零部件的库。
人们只会记忆背诵单词。语法和语义是在上下文中，通过使用逐渐地学习。
人们根据语义上的分类对词汇组合规则进行分组，而不是通过比较对象子集。
子弹的本质——形势没有发生改变
现在，我们回到基本问题。复杂性是我们这个行业的属性，而且复杂性是我们主要的限制。R.L.Glass在1988年的文字精确地总结了我在1995年的看法：
又怎么样呢？Parnas和Brooks不是已经告诉我们了吗？软件开发是一件棘手的事情，前方并不会有魔术般的解决方案。现在是从业者研究和分析革命性进展的时刻，而不是等待或希望它的出现。
软件领域中的一些人发现这是一幅使人泄气的图画。他们是那些依然认为突破近在眼前的人们。
但是我们中的一些——那些非常固执，以致于可以认为是现实主义者的人——把它看成是清新的空气。我们终于可以将焦点集中在更加可行的事情上，而不是空中的馅饼。现在，有可能，我们可以在软件生产率上取得逐步的进展，而不是等待不大可能到来的突破29。
《人月神话》的观点：是或非？（Propositions of the Mythical Man-Month: True or False？）
我们理解的也好，不理解的也好，描述都应该简短精练。
塞缪尔·巴特勒，讽刺诗
For brevity is very good, where we are, or are not understood.
SAMUEL BUTLER Hudibras
现在我们对软件工程的了解比1975年要多得多。那么在1975年版本的人月神话中，哪些观点得到了数据和经验的支持？哪些观点被证明是不正确的？又有哪些观点随着世界的变化，显得陈旧过时呢？为了帮助判断，我将1975年书籍中的论断毫无更改地抽取出来，以摘要的形式列举在下面——它们是当年我认为将会是正确的：客观事实和经验中推广的法则。（你也许会问，“如果这些就是那本书讲的所有东西，为什么要花177页的篇幅来论述？”）方括号中的评论是新增内容。
所有这些观点都是可操作验证的，我将它们表达成刻板的形式是希望能引起读者的思考、判断和讨论。
