过去在软件生产率上取得的进展大多数来自消除非内在的困难，如笨拙的编程语言、漫长的批处理周转时间等。
像这些比较容易解决的困难已经不多了。
彻底的进展将来自对根本困难的处理——打造和组装复杂概念性结构要素。
最明显的实现这些的方法是，认为程序由比独立的高级语言语句、函数、模块或类等更大的概念结构要素组成。如果能对设计和开发进行限制，我们仅仅需要从已建成的集合中参数化这些结构要素，并把它们组装在一起，那么我们就能大幅度提高概念的级别，消除很多无谓的工作和大量语句级别的错误可能性。
Parnas的模块信息隐藏定义是研究项目中的第一步，它是面向对象编程的鼻祖。Parnas把模块定义成拥有自身数据模型和自身操作集的软件实体。它的数据仅仅能通过它自己的操作来访问。第二步是若干思想家的贡献：把Parnas模块提升到抽象数据类型，从中可以派生出很多对象。抽象数据类型提供了一种思考和指明模块接口的统一方式，以及容易保证实施的类型规范化访问方法。
第三步，面向对象编程引入了一个强有力的概念——继承，即类（数据）默认获得类继承层次中祖先的属性14。我们希望从面向对象编程中得到的最大收获实际上来自第一步，模块隐藏，以及预先建成的、为了重用而设计和测试的模块或者类库。很多人忽视了这样一个事实，即上述模块不仅仅是程序，某种意义上是我们在第1章中曾讨论过的编程产品。许多人希望大规模重用，但不付出构建产品级质量（通用、健壮、经过测试和文档化的）模块所需要的初始代价——这种期望是徒劳的。面向对象编程和重用在第16和17章中有所讨论。
人月到底有多少神话色彩？Boehm的模型和数据
很多年来，人们对软件生产率和影响它的因素进行了大量的量化研究，特别是在项目人员配备和进度之间的平衡方面。
最充分的一项研究是Barry Boehm对63个项目的调查，其中大多数是航空项目和25个TRW公司的项目。他的《软件工程经济学》（Software Engineering Economics）不但包括了很多结果，而且还有一系列逐步推广的成本模型。尽管一般商业软件的成本模型和根据政府标准开发的航空软件成本模型中的系数肯定不同，不过他的模型使用了大量的数据来支撑。我想从现在起，这本书将作为一代经典。
他的结果充分地吻合了《人月神话》的结论，即人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。特别的，他发现：15
第一次发布的成本最优进度时间，T = 2.5（MM）1/3。即，月单位的最优时间是估计工作量（人月）的立方根，估计工作量则由规模估计和模型中的其他因子导出。最优人员配备曲线是由推导得出的。
当计划进度比最优进度长时，成本曲线会缓慢攀升。时间越充裕，花的时间也越长。
当计划进度比最优进度短时，成本曲线急剧升高。
无论安排多少人手，几乎没有任何项目能够在少于3/4的最优时间内获得成功！当高级经理向项目经理要求不可能的进度担保时，这段结论可以充分地作为项目经理的理论依据。
Brooks准则有多准确？曾有很多细致的研究来评估Brooks法则的正确性，简言之，向进度落后的软件项目中添加人手只会使进度更加落后。最棒的研究发表在Abdel-Hamid和Madnick在1991年出版的一本颇有价值的书《软件项目动力学：一条完整的路》16（Software Project Dynamics：An Integrated Approach）中。书中提出了项目动态特性的量化模型。关于Brooks准则的章节提供了更详细的分析，指出了在各种假设下的情况，即何时添加多少人员将会产生什么样的结果。为了进行研究，作者扩展了他们自己一个中型规模项目的模型，假设新成员有学习曲线和需要额外的沟通和培训工作。他们得出结论“向进度落后的项目中添加人手总会增加项目的成本，但并不一定会使项目更加落后。”特别的，由于新成员总会立刻带来需要数周来弥补的负面效应，所以在项目早期添加额外的人力比在后期加入更
加安全一些。
Stutzke为了进行相似的研究，开发了一个更简单的模型，得出了类似的结果17。他对引入新成员进行了详细的过程和成本分析，其中包括把他们的指导人员调离原有的项目任务。他在一个真正的项目上测试了他的模型，在项目中期的一些偏移之后，他成功地添加了一倍人手，并且保证了原先的进度。相对于增加更多程序员，他还试验了的其他方法，特别是加班工作。在他的很多条实践建议中，最有价值的部分是如何添加新成员，进行培训，用工具来支持等等。特别值得注意的是，他建议开发项目后期增加的开发人员，必须作为团队成员，愿意在过程中努力投入和工作，而不是企图改变或者改进过程本身！
Stutzke认为更大型的项目中，增加的沟通负担是次要作用，没有对它建模。至于Abdel-Hamid和Madnick是否或者如何考虑这个问题，则不是很清楚。上面提到的两个模型都没有考虑开发人员必须重新安排的事实，而在实际情况中，我发现这常常是一个非常重要的步骤。
这些细致的研究使“异常简化”的Brooks准则更加实用。作为平衡，我还是坚持这个简单的陈述，作为真理的最佳近似，以及一项经验法则——警告经理们避免对进度落后的项目采取的盲目、本能的修补措施。
人就是一切（或者说，几乎是一切）
很多读者发现很有趣的是，《人月神话》的大部分文章在讲述软件工程管理方面的事情，较少涉及到技术问题。这种倾向部分因为我在IBM 360操作系统（现在是MVS/370）项目中角色的性质。更基本的是，这来自一个信念，即对于项目的成功而言，项目人员的素质、人员的组织管理是比使用的工具或采用的技术方法更重要的因素。
随后的研究支持了上述观点。Boehm的COCOMO模型发现团队质量目前是项目成功最大的决定因素，实际上是下一个次重要因素的4倍。现在，软件工程的大多数学术研究集中在工具上。我很欣赏和期盼强大的工具，同样我也非常鼓励对软件管理动态特征——对人的关注、激励、培养——的持续研究。
人件。近年来，软件工程领域的一个重大贡献是DeMarco和Lister在1987年出版的数据，《人件：高生产率的项目和团队》（Peopleware：Productive Projects and Teams）。
它所表达的观点是“我们行业的主要问题实质上更侧重于社会学（sociological）而不是科学技术（technological）。”它充满了很多精华，如“管理人员的职责不是要人们去工作，而是是创造工作的可能。”它涉及了如空间、布置、团队的餐饮等主题。DeMarco和Lister从他们的Coding War Games项目中提供的数据，显示了相同组织中开发人员的表现之间，和工作空间和生产率以及缺陷水平之间令人吃惊的关联。
顶尖人员的空间更加安静、更加私人、保护得更好以免受打断，还有很多 这对你真的很要紧吗 是否安静、空间和免受打搅能够帮助你的人员更好地完成工作，或者[换个角度]能帮助你吸引和留住更好的人员？
我衷心地向我的读者推荐这本书。
项目转移。DeMarco和Lister对团队融合给予了相当大的关注，团队融合是一个无形的，但是非常关键的特性。很多地点分散的公司，项目从一个实验室转移到另一个。从中，我认为团队融合正是管理上被忽视的因素。
我的观察和经验大约局限在六、七个项目转移中，其中没有一个是成功的。任务可以成功地转移，但是对于项目的转移，即使拥有良好的文档、先进的设计以及保留部分原有人员，新队伍实际上依然是重新开始。我认为正是由于破坏了原有团队的整体性，导致了产品雏形的夭折，项目重新开始。
放弃权力的力量
如果人们认同我在文中多处提到的观点——创造力来自于个人，而不是组织架构或者开发过程，那么项目管理面对的中心问题是如何设计架构和流程，来提高而不是压制主动性和创造力。幸运的是，这个问题并不是软件组织所特有，一些杰出的思想家正努力地致力于这项工作。E.F.Schumacher在他的经典《小就是美：人们关心的经济学》（Small is Beautiful：Economics as if People Mattered）中，提出了最大化员工创造力和工作乐趣的理论。他的第一个原理是引自Pope Pius XI教皇通谕Quadragesimo Anno中的“附属职能行使原理”：
向大型组织指派小型或者附属机构能够完成的职责是不公平的，同时也是正常次序的不幸和对它的干扰。对于每项社会活动，就其本质而言，应该配备对社会个体成员的帮助，
而不是去破坏和吸收它们 那些当权者应该确信遵守“附属职能行使”原理，能在各种各样的组织中维持更加完美的次序，越强和越有效的社会权威将会是国家更加融洽和繁荣的条件19。
Schumacher继续解释到：
附属职能行使原理告诉我们——如果较低级别组织的自由和责任得以保留，中心权威实际上是得到了加强；其结果是，从整体而言，组织机构实际上将“更加融洽和繁荣”。
如何才能获得上述的架构？ 大型组织机构由很多准自治单元构成，我们称之为准公司。它们中的每一个都拥有大量的自由，来为创造性和企业家职能提供最大的可能机会 。每个准公司同时具备盈亏帐目和资产负债表20。
软件工程中最激动人心的进展是将上述组织理念付诸实践的早期阶段。首先，微型计算机革命创造了新型的软件工业，出现了成百上千的新兴公司。所有这些小规模的公司热情、自由和富有创造性。随着很多小型公司被大公司收购，这个产业正在发生着变化，而那些大公司是否理解和保留小规模的创造性尚待分晓。
更不寻常的是，一些大型公司的高层管理已经开始着手将一些权力下放到软件项目团队，使它们在结构和责任上接近于Schumacher的准公司。其运作的结果是令人欣喜和吃惊的。
微软的Jim AcCarthy向我描述了他在解放团队上的经验：
每个队伍（30至40人）拥有自己的任务、进度，甚至如何定义、构建、发布的过程。团队由4或5个专家组成，包括开发、测试和书写文档等。由团队而不是老板对争论进行仲裁。我无法形容授权和由团队自行负责项目的成功与否的重要性。
Earl Wheeler，IBM软件业务的退休主管，告诉我他着手下放IBM部门长期集权管理权力的经验：
[近年来]关键的措施是将权力向下委派。这就像是魔术！改进的质量、提高的生产率、高涨的士气。我们的小型团队，没有中心控制。团队是流程的所有者，并且必须拥有一个流程。他们有不同的流程。他们是进度计划的所有者，因此感受到市场的压力。这种压力导致他们使用和利用自己的工具。
和团队成员个人的谈话，显示了他们对被委派的权力和自由的赞同，同时也反映出真正的下放显得多少有些保守。不过，授权是朝着正确方向迈出的一大步，它产生了像Pius XI所预言的好处：通过权力委派，中心的权威实际上是得到了加强；从整体而言，组织机构实际上更加融洽和繁荣。
最令人惊讶的新事物是什么？数百万的计算机
每位我曾交谈过的计算机带头人都承认，对微型计算机革命和它引发的塑料薄膜包装软件产业感到惊讶。毫无疑问，这是继《人月神话》后二十年中最重要的改变。它对软件工程意味着很多。
微型计算机革命改变了每个人使用计算机的方式。Schumacher在20年前，陈述了面对的挑战：
我们真正想从科学家和技术专家那里得到什么？我会回答：我们需要这样的方法和设备：
价格足够低廉，使几乎所有人都能够使用
适合小型的应用，并且
满足人们对创造的渴望21。
这些正是微型计算机革命带给计算机产业和它的用户（现在已覆盖到普通公众）的杰出特性。一般人现在不但可以买得起自己的计算机，而且还可以负担20年前只有国王的薪水才能买得起的软件。Schumacher的目标值得仔细思考，每个目标达到的程度值得品评，尤其是最后一个。在一个一个的领域中，普通人同专家一样可以应用新的自我表达方法。
其他领域中进步的部分原因和软件创造相近——消除了次要的困难。例如，文书处理方式曾经是很僵化的，合并更改内容需要重新打字，成本和时间都比较高昂。一份300页的手稿，常常每3到6个月就需要重新输入一遍，这中间，人们往往还不断地产生新文稿。另外，逻辑流程和语句韵律的修订很难进行。而现在，文书处理已经非常方便和流畅了22。
计算机同样给其他一些领域带来了相似的处理能力，绘画、制订计划、机械制图、音乐创作、摄影、摄像、幻灯、多媒体甚至是电子表格等。在这些领域中，手工操作都需要重
新拷贝大量的未改变的部分，以便在上下文中区别修改情况。现在我们能享受这样的好处，即立刻对结果进行修订和评估，无须失去思维的连贯性，就象分时带给软件开发的好处一样。
同样，新的、灵活的辅助工具增进了创造力。以写作为例，我们现在拥有拼写检查、语法检查、风格顾问、目录生成系统以及对最终排版预览的能力。
最重要的是，当一件创造性工作刚刚成形时，工作介质的灵活性使得对多种彻底不同的可选方案的探索变得容易。这实际上是一个量变引起质变的例子，即时间变化引起工作方式上的巨大变化。
绘图工具使建筑设计人员为每小时的创造性投资展现了更多的选择。计算机与合成器的互联，加上自动生成或者演奏乐谱的软件，使得人们更容易捕获创作的灵感。数字式相机，和Adobe Photoshop一起，使原先在暗室中需要数日的工作在几分钟内就可以完成。电子表格可以对大量“what if”的各种情况进行实验、比较。
最后，个人计算机的普遍存在导致了全新创造性活动介质的出现。Vannevar Bush在1945年提出的超文本，仅能在计算机上实现23。多媒体表现形式和体验更是如此——在计算机和大量价格低廉的软件出现以前，实现起来有太多的困难。至于现在并不便宜或普遍的虚拟环境系统，将成为另一个创造性活动的媒介。
微型计算机革命改变了每个人开发软件的方式。70年代的软件过程本身被微处理器革命和它所带来的科学技术进步所改变。很多软件开发过程的次要困难被消除。快速的个人计算机现在是软件开发者的常规工具，从而周转时间的概念几乎成为了历史。如今的个人计算机不仅仅比1960年的超级计算机要快，而且它比1985年的Unix工作站还要快。所有这些意味着即使在最差的计算机上，编译也是快速的，而且大内存消除了基于磁盘链接所需要的等待时间。另外，符号表和目标代码可以在内存中保存，从而高级别的调试无需重新编译。
在过去的20年里，我们几乎全部采用了分时作为构建软件的方法学。在1975年，分时才刚刚作为最常用的技术替换了批处理计算。网络使软件构建人员不仅可以访问共享文件，还可以访问强大的编译、链接和测试引擎。今天，个人工作站提供了计算引擎，网络主要提供了对文件的共享访问，这些文件作为团队开发的工作产品。客户－服务器系统则使测试用例检入、开发和应用的共享访问更加简单。
同样，用户界面也取得了类似的进步。和一般的文本一样，WIMP界面对程序文本提供
了更加方便迅捷的编辑方式。24行、72列的屏幕已经被整页甚至是双页的屏幕所取代，因此程序员可以看到所作更改的更多上下文。
全新的软件产业——塑料薄膜包装的成品软件
在传统软件产业的旁边，爆发了另一个全新的产业。产品以成千上万，甚至是数百万的规模销售。整套内容丰富的软件包可以以少于开发成本的价格获得。这两个产业在很多方面都不同，它们共同存在着。
传统软件产业。在1975年，软件产业拥有若干可识别的、但多少有些差异的组成部分，如今他们依然存在：
计算机提供商：提供操作系统、编译器和一些实用程序
应用程序用户：如公共事业、银行、保险、政府机构等，他们为自己使用的软件开发应用程序包。
定制程序开发者：为用户承包开发私用软件包，需求、标准和行销步骤都是与众不同的。
商业包开发者：那个时候是为专业市场开发大型应用，如统计分析和CAD系统等。
Tom DeMarco注意到了传统软件产业的分裂，特别是应用程序用户。
我没有料到的是：整个行业被分解成各个特殊的领域。你完成某事的方式更像是专业领域的职责，而不仅仅是通用系统分析方法、通用语言、通用测试技术的使用。Ada是最后一个通用语言，并且它已经慢慢变成了一门专业语言。
在日常的商业应用领域中，第4代语言作出了巨大的贡献。Boehm说，“大多数成功的第4代语言是以选项和参数方式系统化某个应用领域的结果。”这些第4代语言最普遍的情况是带有查询语言、数据库－通讯软件包的应用生成程序。
操作系统世界已经统一了。在1975年，存在着很多操作系统：每个硬件提供商每条产品线最少有一种操作系统，很多提供商甚至有两个。如今是多么的不同啊！开放式系统是基本原则。目前，人们主要在5大操作系统环境上行销自己的应用程序包（按照时间顺序）：
IBM MVS和VM环境
DEC VMS环境
Unix环境，某个版本
IBM PC环境，DOS、OS-2或者Windows
Apple Macintosh环境
塑料薄膜包装的成品软件产业。对于这个产业的开发者，面对的是与传统产业完全不同的经济学：软件成本是开发成本与数量的比值，包装和市场成本非常高。在传统内部的应用开发产业，进度和功能细节是可以协商的，开发成本则可能不行；而在竞争激烈的开发市场面前，进度和功能支配了开发成本。
正如人们所预期的，完全不同的经济学引发了非常不同的编程文化。传统产业倾向于被大型公司以已指定的管理风格和企业文化所支配。另一方面，始于数百家创业公司的成品软件产业，行事自由，更加关注结果，而不是流程。在这种趋势下，那些天才的个人程序员更容易获得认可，这隐含了“卓越的设计来自于杰出的设计人员”的观点。创业文化能够对那些杰出人员，根据他们的贡献进行奖励。而在传统软件产业中，公司的社会化因素和薪资管理计划总会使上述做法难以实施。因此，很多新一代的明星人物被吸引到薄膜包装的软件产业，这一点并不奇怪。
买来开发——使用塑料包装的成品软件包作为构件
彻底提高软件健壮性和生产率的唯一途径，是提升一个级别，使用模块或者对象组合来进行程序的开发。一个特别有希望的趋势是使用大众市场的软件包作为平台，在上面开发更丰富和更专业化的产品。如使用塑料包装的数据库和通讯软件包来开发货运跟踪系统，或者学生的信息系统等。而计算机杂志上的征文栏目提供了许许多多的Hypercard Stack、Excel模板、Minicard的特殊Pascal函数以及AutoCad的AutoLisp函数。
元编程。Hypercard Stack、Excel模板、Minicard函数的开发有时被称为元编程（metaprograming），为部分软件包用户进行功能定制的过程。元编程并不是新概念，仅仅是重新被提出和重新命名。在60年代早期，很多计算机提供商和信息管理系统（MIS）厂商都拥有小型专家小组，他们使用汇编语言的宏来装备应用编程语言。Eastman Kodak的MIS开发车间使用一种用IBM 7080宏汇编定义的自有应用语言。类似的，IBM的OS/360 队列远
程通讯访问方法中（Queued Telecommunications Access Method），在遇到机器级别指令之前，人们可以读到若干页汇编语言的通讯程序。现在元编程人员提供要素的规模是宏的若干倍。这种二级市场的开发是非常鼓舞人心的——当我们在期待C++类开发的高效市场时，可重用元程序的市场正在悄无声息地崛起。
它处理的确实是根本问题。因为包开发现象并没有影响到一般的MIS编程人员，所以对于软件工程领域并不是很明显。不过，它将快速地发展，因为它针对的正是概念结构要素打造的根本问题。成品软件包提供了大型的功能模块和精心定制的接口，它内部的概念结构根本无需再设计。功能强大的软件产品，如Excel或者4th Dimension实际上是大型的模块，而且它们作为广为人知、文档化、测试过的模块，可以用来搭建用户化系统。下一级应用程序的开发者可以获得丰富的功能、更短的开发时间、经过测试的组件、良好的文档和彻底降低的成本。
当然，存在的困难是成品软件是作为独立实体来设计，元程序员无法改变它的功能和接口。另外，更严肃地说，对于成品软件的开发者而言，把产品变成更大型系统中的模块似乎没有什么吸引力。我认为这种感觉是错误的，在为元程序员开发提供软件包方面，有一个未开拓的市场。
那么需要什么呢？我们可以识别出四个层次的软件用成品户：
直接使用用户。他们以简便直接的方式来操作，对设计者提供的功能和接口感到满意。
元程序员。在单个应用程序的基础上，使用已提供的接口来开发模板或者函数，主要为最终用户节省工作量。
外部功能作者，向应用程序中添加自行编制的功能。这些功能本质上是新应用语言原语，调用通用语言编写的独立模块。这往往需要命令中断、回调或者重载函数技术，向原接口添加新功能。
元程序员，使用一个和多个特殊的应用程序，作为更大型系统的构件。他们是需求并没有得到满足的用户群。同时，这也是能在构建新应用程序方面获得较大收获的用法。
对于成品软件，最后一种类型的用户还需要额外的文档化接口，即元编程接口（metaprogramming interface，MPI）。这在很多方面提出了要求。首先，元程序需要在整
个软件集的控制之下，而每个软件通常假设是受自己的控制。软件集必须控制用户界面，而应用程序一般认为这是自己的职责。软件整体必须能够调用任何应用程序的功能，就好像是用户使用命令行传递参数那样。它还应该像屏幕一样接受应用程序的输出，只不过屏幕是显示一系列字符串，而它需要将输出解析成适当数据类型的逻辑单元实体。某些应用程序，如FoxPro，提供了一些接收命令的后门接口（wormhole），不过它返回的信息是不够充分和未被解析的。这些接口是对通用解决方案需要的一个特殊补充。
拥有能控制应用程序集合之间交互的脚本语言是非常强有力的。Unix首先使用管道和标准的ASCII字符串格式提供了这种功能。今天，AppleScript是一个非常优秀的例子。
软件工程的状态和未来
我曾问过北卡罗来纳州大学化学系的系主任Jim Ferrell关于化学工程的历史以及和化学的区别的问题，于是他作了一个1小时的出色即兴演说，从很多产品（从钢铁到面包，到香水）的不同生产过程开始。他讲述了Arthur D. Little博士如何在1918年在麻省理工学院建立了第一个化学工程系，来发现、发展和讲授所有过程的共有技术基础。首先是经验法则，接着是经验图表，后来是设计特殊零件的公式，再后来是单个导管中热传导、质量转移和动量转移的模型。
如同Ferrell故事所展现的，在几乎50年后，我仍被化学工程和软件工程之间的很多相似之处所震动。Parans对我写的关于软件工程（software engineering）的文章提出了批评。他对比了电气工程和软件领域，觉得把我们所做的称为“工程”十分冒昧。他可能是正确的，这个领域可能永远不会发展成像电气工程那样的工程化领域，拥有精确的数学基础。毕竟，软件工程就像化学工程一样，与如何扩展到工业级别处理过程的非线性问题有关。而且，和工业工程类似，它总是被人类行为的复杂性所困扰。
不过，化学工程的发展过程让我觉得“27岁的”软件工程并不是没有希望的，而仅仅是不够成熟的，就好像1945年的化学工程。毕竟，在二次世界大战之后，化学工程师才真正提出闭环互联的连续流系统。
