人月神话-17

部分指它的实现过程。- 121 ------------------------ Page 134-----------------------现实问题。对我而言（尽管不是所有人），关键论点的正确与否归结为一个现实问题：整个软件开发工作中的哪些部分与概念性结构的精确和有序表达相关，哪些部分是创造那些结构的思维活动？根据缺陷是概念性的（例如未能识别某些异常），或者是表达上的问题（例如指针错误或者内存分配错误）等，可以将这些缺陷的寻找和修复工作进行相应的划分。在我看来，开发的次要或者表达部分现在已经下降到整个工作的一半或一半以下。由于这部分是现实的问题，所以原则上可以应用测量技术来研究6。这样，我的观点也可以通过来更科学和更新的估计来纠正。值得注意的是，还没有人公开发表或者写信告诉我，次要部分的任务占据了工作的9/10。《没有银弹》无可争辩地指出，如果开发的次要部分少于整个工作的9/10，那么即使不占用任何时间（除非出现奇迹），也不会给生产率带来数量级的提高。因此，必须着手解决开发的根本问题。由于《没有银弹》，Bruce Blum 把我的注意力引向Herzberg、Mausner 和Sayderman7等人在1959 年的研究。他们发现动机因素可以提高生产率。另一方面，环境和次要因素，无论起到多么积极的作用，仍无法提高生产率。但是在产生负面影响时，它们会使生产率降低。《没有银弹》认为很多软件开发过程已经消除了以下负面因素：十分笨拙的机器语言、漫长的批处理周转时间以及无法忍受的内存限制。因为是根本困难所以没有希望？1990年BradCox 的一篇非常出色的论文《这就是银弹》（There Is a Silver Bullet），有说服力地指出重用和交互的构件开发是解决软件根本困难的一种方法8。我由衷地表示赞同。不过，Cox 在两点上误解了《没有银弹》。首先，他断定软件困难来自“编程人员缺乏构建当今软件的技术”。而我认为根本困难是固有的概念复杂性，无论是任何时间，使用任何方法设计和实现软件的功能，它都存在。其次，他（以及其他人）阅读《没有银弹》，并认定文中的观点是没有任何处理软件开发中根本困难的希望——这不是我的本意。作为本质上的困难，构思软件概念性的结构本身就有复杂性、一致性、可变性及不可见性的特点。不过实际上，每一种困难产生的麻烦都是可以改善的。复杂性是层次化的。例如，复杂性是最严重的内在困难，并不是所有的复杂性都是不可避免的。我们的很多软件，但不是全部，来自应用本身随意的复杂特性。来自一家国际管理咨询公司，MYSIGMA Lars Sodahl 的Lars Sodahl 和合作伙伴曾写道：- 122 ------------------------ Page 135-----------------------就我的经验而言，在系统工作中所遇到的大多数困难是组织结构上的一些失误征兆。试图为这些现实建模，建立同等复杂的程序，实际上是隐藏，而不是解决这些杂乱无章的情况。Northrop 的Steve Lukasik 认为即使是组织机构上的复杂性也不是任意的，可能容易受到策略调整的影响。我曾作为物理学家接受过培训，因此倾向于用更简单的概念来描述“复杂”事物。现在你可能是正确的，我无法断定所有的复杂事物都容易用有序的规律表达……同样的道理，你不能断定它们不能。……昨天的复杂性是今天的规律。分子的无序性启迪了气体动力学理论和热力学的三大定律。现在，软件没有揭示类似的规律性原理，但是解释为什么没有的重担在你的身上。我不是迟钝和好辩的。我相信有一天软件的“复杂性”将以某种更高级的规律性概念来表达（就像物理学家的不变式）。我并没有着手于Lukasik 提倡的更深层次的分析。作为一个学科，我们需要更广泛的信息理论，它能够量化静态结构的信息内容，就像针对交互流的香农信息论一样。这已经超越了我的能力。作为对Lukasik 的简单回应，我认为系统复杂性是无数细节的函数，这些细节必须精确而且详细地说明——或者是借助某种通用规则，或者是逐一阐述，但决不仅仅是统计说明。仅靠若干人不相干的工作，是不大可能产生足够的一致性，能用通用规律进行精确描述。不过，很多复杂性并不完全是因为和外部世界保持一致，而是因为实现的本身，例如数据结构、算法、互联性等。而在更高的级别开发（发展）软件，使用其他人的成果，或者重用自己的程序——都能避免面对整个层次的复杂性。《没有银弹》提出了全力解决复杂性问题的方法，这种方法可以在现实中取得十分乐观的进展。它倡导向软件系统增加必要的复杂性：层次化，通过分层的模块或者对象。增量化，从而系统可以持续地运行。- 123 ------------------------ Page 136-----------------------Harel 的分析David Harel，在1992 年的论文《批评银弹》（Biting the Silver Bullet）中，对已出版的《没有银弹》进行了很多最仔细的分析。悲观主义 vs. 乐观主义 vs. 现实主义。Harel 同时阅读了《没有银弹》和 1984 年Parnas 的文章《战略防卫系统的软件问题》（Software Aspects of Strategic DefenseSystems10），认为它们“太过黯淡”。因此，他试图在论文《走向系统开发的光明未来》（Towarda Brighter Future for System Development）中展现其明亮的一面。Cox 同Halel一样认为《没有银弹》一文过于悲观，从而他提出“但是，如果从一个新视点去观察相同的事情，你会得到一个更加乐观的结论”。他们的论调都有些问题。首先，我的妻子、同事和我的编辑发现我犯乐观主义错误的几率远远大于悲观主义。毕竟，我的从业背景是程序员，乐观主义是这个行业的职业病。《没有银弹》一文明确地指出“我们看看近十年来的情况，没有银弹的踪迹……怀疑论者并不是悲观主义者……虽然没有通天大道，但是路就在脚下。”它预言了如果1986 年的很多创新能持续开拓和发展，那么实际上它们的共同作用能使生产率获得数量级的提高。随着1986～1996 十年过去了，这个预言即使说明了什么，那也是过于乐观，而不是过于悲观。就算《没有银弹》总体看来有些悲观，那么到底存在什么问题？是否爱因斯坦关于任何物体运动的速度无法超过光速的论断过于“黯淡”或者“令人沮丧”呢？那么哥德尔关于某些事物无法计算的结论，又如何呢？《没有银弹》一文认为“软件的特性本身导致了不大可能有任何的银弹”。Tuski 在IFIP大会上发表了一篇论文作为出色的回应，文中指出：在所有被误导的科学探索中，最悲惨的莫过于对一种能够将一般金属变成金子的物质，即点金石的研究。这个由统治者不断地投入金钱，被一代代的研究者不懈追求的、炼金术中至高无上的法宝，是一种从理想化想象和普遍假设中——以为事情会像我们所认为的那样——提取出的精华。它是人类纯粹信仰的体现，人们花费了大量的时间和精力来认可和接受这个无法解决的问题。即使被证明是不存在，那种寻找出路和希望能一劳永逸的愿望，依然十分的强烈。而我们中的绝大多数总是很同情这些明知不可为而为之的人，因此它们总是得以延续。所以，将圆形变方的论文被发表，恢复脱发的洗液被研制和出售，提高软件生产率的方法被提出并成功地推销。- 124 ------------------------ Page 137-----------------------我们太过倾向于遵循我们自己的乐观主义（或者是发掘我们出资人的乐观主义）。我们11太喜欢忽视真理的声音，而去听从万灵药贩卖者的诱惑 。我和Turski 都坚持认为这个白日梦限制了向前的发展，浪费了精力。“消极”主题。Harel 认识到《没有银弹》中的消极来自三个主题：根本和次要问题的清晰划分独立地评价每个候选银弹仅仅预言了十年，而不是足够长的时间“出现任何重大的进步。”第一个主题，它是整篇文章的主要观点。我仍然认为上述划分对于理解为什么软件难以开发是绝对关键的。对于应该做出哪些方面的改进，它也是十分明确的指南。至于独立地考虑不同的候选银弹，《没有银弹》并非如此。各种各样的技术一个接一个地被提出，每一种都过分宣扬自身的效果。因此，依次独立的评估它们是非常公平的。我持反对态度的并不是这些技术，而是那种它们能起到魔术般作用的观点。Glass、Vessey 和12Conger 在他们1992年的论文中提供了充足的证据，指出对银弹的无谓研究仍未结束 。关于选择10 年还是40 年作为预言的期限，选择较短的时间是承认我们并没有足够强的能力可以预见到十年以后的事情。我们中间有谁可以在1975 年预见到80 年代的微型计算机革命吗？对于十年的期限，还有其他的一些原因：各种银弹都宣称它们能够立刻取得效果。我回顾了一下，发现没有任何一种银弹声称“向我的秘方投资，在十年后你将获得成功”。另外，硬件的性能/价格比可能每十年就会有成百倍的增长，尽管这种比较不很合适，但是直觉上的确如此。我们确信会在下一个40 年中取得稳步的发展。不过，以40 年代价取得数量级的进展，很难被认为是不可思议的进步。想象的试验。Harel 建议了一种想象的试验，他假设《没有银弹》是发表在1952 年，而不是1986 年，不过表达的论断相同。他使用反证法来证明将根本和次要问题分开是不恰当的。这种观点站不住脚。首先，《没有银弹》一开始就声称，50年代的程序开发中曾占支配地位的次要困难，如今已经不存在了，并且消除这些困难已经产生了提高若干数量级的效果。- 125 ------------------------ Page 138-----------------------将辩论推回到40 年前是不合理的，在1952 年，甚至很难想象开发的次要问题不会占据开发工作的主要部分。其次，Harel 所设想50年代行业所处状态是不准确的：当时已经不是构建大型复杂系统的时代，程序员的工作模式已经成为常规个人程序的开发（在现代的编程语言中，大概是100～200行代码）。在已有技术和方法学的前提下，这些任务是令人恐怖的，处处都是错误、故障和落后的完成期限。接着，他阐述了在传统的小型个人程序中，那些假设的错误、故障和落后的最终期限如何在接下来的25年中，得到数量级的改进和提高。但是，50 年代该领域的实际情况并不是小型个人程序。在1952 年，Univac 还在使用大约8 人开发的复杂程序处理1950年的人口普查13。其他机器则用于化学动力学、中子漫射计算、导弹性能计算等等14。汇编语言、重定位的链接和装载程序、浮点解释系统等，还15 16经常被使用 。1955 年，人们开发50～100 人年的商用程序 。1956年，通用电气在路易斯维尔的设备车间使用着超过80,000 指令的薪资系统。1957年，SAGEANFSQ/7 防空计算机系统已经运转了两年，这个系统分布在30 个不同的地点，是基于通讯、自消除故障的热备实时系统17。因此，几乎无法坚持说个人程序的技术革命，能够用来描述1952 年以来的软件工程上的努力。银弹就在这里。Harel 接着提出了他自己的银弹，一种称为“香草（Vanilla）框架”的建模技术。文中并没有对方法提供足够评估的详细描述，不过给出了一些论文和参考资料18。建模所针对的确实是软件开发的根本困难，即概念性要素的设计和调试，因此Vanilla框架有可能是革命性的。我也希望如此。Ken Brooks在报告中提到，在实际工作中应用时，它的确是一种颇有帮助的方法学。不可见性。Harel强烈地主张软件的概念性要素本质上是拓扑的，这些关系可以用空间/图形方式来自然地表达：适当使用可视化图形可以给工程师和程序员带来可观的成效。而且，这种效果并不仅仅局限于次要问题，开发人员思考和探索的质量也得到了改进。未来的成功系统的开发将围绕在可视化图形表达方式的周围。首先，我们会使用“合适的”实体和关系来形成概念，然后表达成一系列逐步完善的模型，不断地系统化阐明和精化设计概念。模型用若干可视化语- 126 ------------------------ Page 139-----------------------言的适当组合来描述，它必须是多种语言的组合，因为系统模型具有若干方面的内容，每方面象变戏法般产生不同类型的思维图像。……就使自己成为良好可视化表达方式而言，建模过程的某些方面并不会立刻出现改观。例如，变量和数据结构上的算法操作可能还是会采用文字性描述。我和Harel 颇为一致。我认为软件要素并不存在于三维空间中，因此并不存在概念性设计到图形简单两维或三维上的映射。他承认，我也同意——这需要多种图形，每种图形覆盖某个特定的方面，而且有些方面无法用图形来表达。Harel 采用图形来辅助思考和设计的热情彻底地感染了我。我一直喜欢向准程序员提问，“下个十一月在哪？”如果觉得问题过于模糊，接着我会问，“告诉我，你自己关于时间历法的模型。”优秀程序员具有很强的空间想象能力，他们常常有时间的几何模型，而且无需考虑，就能理解第一个问题。他们往往拥有高度个性化的模型。Jone 的观点——质量带来生产率Capers Jones最开始在一系列备忘录里，而后在一本书里，提出了颇有洞察力的观点。很多和我有书信往来的人向我提到了他的观点，《没有银弹》如同当时的很多文章，关注于生产率——单位输入对应的软件产出。Jone 提出，“不。关注质量，生产率自然会随着提高。19”他认为，很多代价高昂的后续项目投入了大量的时间和精力来寻找和修复规格说明中、设计和实现上的错误。他提供的数据显示了缺乏系统化质量控制和进度灾难之间的密切关系。我认同这些数据。不过，Boehm指出，如果一味追求完美质量，生产率会像IBM 的航天软件一样再次下降。Coqui也提出相似的主张：系统化软件开发方法的发展是为了解决质量问题（特别是避免大型的灾难），而不是出于生产率方面的考虑。但是注意：70 年代，在软件生产上应用工程原理的目标是提高软件产品的质量、可测试性、稳定性以及可预见性——而不是软件产品的开发效率。在软件生产上应用工程原理的驱动力是担心拥有无法控制的“艺术家们”而可能导致的巨大灾难，他们往往对异常复杂系统开发承担责任20。- 127 ------------------------ Page 140-----------------------那么，生产率的情形如何？生产率数据。生产率的数据非常难以定义、测量和寻找。Capers Jones 相信两个相隔十年、完全等同的COBOL 程序，一个采用结构化方法开发，另一个不使用结构化方法，它们之间的差距是3倍。Ed Yourdon 说，“由于工作站和软件工具，我看到了人们的工作获得了5 倍的提高。”Tom DeMarco认为“你的期望——十年内，由于所有的技术而使生产率得到数量级的提高——太乐观了。我没有看到任何机构取得数量级的进步。”塑料薄膜包装的成品软件——购买，而非开发。我认为1986 年《没有银弹》中的一个估计被证实是正确的：“我相信，这个大众市场是……软件工程领域意义最深远的开发方向。”从学科的角度说，不管和内部还是外部客户软件的开发相比，大众市场软件都几乎是一个崭新的领域。当软件包的销量一旦达到百万或者即使只是几千，这时关键的支配性问题就变成了质量、时机、产品性能和支撑成本，而不再是对于客户系统异常关键的开发成本。创造性活动的强大工具。提高信息管理系统（MIS）编程人员生产率最戏剧化的方法是到一家计算机商店去，购买理应由他们开发的商业成品。这并不荒唐可笑。价格低廉、功能强大的薄膜包装软件已经能满足要求，而以前这会要求进行定制软件包的开发。比起复杂的大型产品工具，它们更加像电锯、电转和砂磨机。把它们组合成兼容互补的集合，像Microsoft Works 和集成更好的Claris Works 一样，能够带来巨大的灵活性。另外，象供人们使用的组合工具箱，其中的某些工具会经常被使用，以致于熟能生巧。这种工具必须注重常人使用的方便，而不是专业。Ivan Selin，美国管理系统公司主席，在1987年曾写信给我：我有些怀疑你的关于软件包没有真正地改变很多……的观点。我觉得你太过轻易地抛开了你的观察所蕴涵的事实；你观察到——[软件包]“可能比以前更加通用和更加容易定制一些，但并不太多。”即使在表面上接受了这种论述，我相信用户察觉到软件包更加通用和易于本地化，这种感觉使用户更容易接受软件包。在我公司发现的大多数情况中，是[最终用户]，而不是软件人员，不愿意使用软件包，因为他们认为会失去必要的特性或功能。因此，对他们而言，易于定制是一个非常大的卖点。