人月神话知识笔记

本章为使用NoteBookLM生成的人月神话的关键观点

第一章 焦油坑

《人月神话》第一章“焦油坑”深刻地分析了软件开发的本质。以下是该章节的关键观点总结：

1. 软件开发的“焦油坑”隐喻

大型系统开发被比作史前的焦油坑。许多大型、强壮的团队在其中剧烈挣扎，虽然大多数能开发出可运行的系统，但极少数能满足目标、进度和预算的要求。问题的复杂性在于，虽然单个困难看似可以解决，但它们相互纠缠累积，使团队行动变得越来越慢。

2. 编程系统产品的演进与成本

作者指出，人们常误以为个人程序员的高生产率可以等同于产业化团队，这源于对产出物定义的误解。他将程序分为四个层级，其成本差异巨大：

• 程序（Program）：由作者在开发平台上运行，是车库中产出的基础产品。
• 编程产品（Programming Product）：可以被任何人运行、测试、修复和扩展，具备通用的风格、彻底的测试和完备的文档。其成本至少是独立程序的 3 倍。
• 编程系统（Programming System）：是功能上相互协作的程序集合，需遵循严格的接口规范和资源限制，并经过详尽的组合测试。其成本也至少是独立程序的 3 倍。
• 编程系统产品（Programming Systems Product）：同时具备上述两者的特征，是真正有用的目标产品。其开发成本高达独立程序的 9 倍。

3. 职业的乐趣

编程之所以迷人，是因为它满足了人类内心深处的创造渴望：

• 创建事物的纯粹快乐，如同上帝创造世界。
• 作品对他人的用处带来的满足感。
• 组装精妙部件并观察其运行的魔术般体验。
• 持续学习的非重复性工作特性。
• 在极其灵活的介质上工作：程序员像诗人一样在纯粹的思考和想象中建造“城堡”，且能产生实实在在的运行结果。

4. 职业的苦恼

软件开发同样充满固有的烦恼，从业者必须坦然面对：

• 追求绝对完美：计算机不容许任何字符或停顿的差错，否则“魔术”就会失效。
• 权威与责任的不匹配：目标和资源往往由他人设定，且必须依赖他人提供的、可能实现拙劣的程序和文档。
• 枯燥的调试工作：寻找琐碎 bug 是一项重复且辛苦的劳动，且调试的难度往往随进度呈非线性增长。
• 产品过时的风险：在投入大量心血后，产品在完成时可能已经因技术进步或竞争对手的领先而显得陈旧。

总而言之，编程是一个乐趣与苦恼共存的创造性活动。理解这一职业的本质，是在焦油坑中搭建桥梁、寻找切实可行方案的第一步。

第二章 人月神话

《人月神话》第二章（即全书的同名章节）深入探讨了软件项目进度的核心误区。以下是该章节的关键观点总结：

1. 软件进度落后的根源

作者认为，缺乏合理的进度安排是项目滞后的最主要原因。导致这一问题的五个因素包括：

• 盲目乐观：假设一切都会顺利运行。
• 混淆工作量与进度：错误地认为“人”和“月”可以互换。
• 估算缺乏信心：软件经理往往无法坚持合理的估算。
• 进度跟踪不力。
• 错误的反应：当进度偏移时，习惯性地采取增加人力的措施。

2. 程序员的乐观主义

编程人员普遍是乐观主义者，总是假设“这次它肯定会运行”。由于编程介质（思维与表现形式）极其灵活且易于驾驭，人们往往期待实现过程不会碰到困难。然而，人类的构思总是有缺陷的，因此 bug 的存在是必然的，而大型项目中多项任务“一切正常”的概率极低。

3. “人月”的神话

“人月”作为一个衡量工作规模的单位是具有欺骗性的，因为它暗示了人数和时间是可以相互替换的。

• 完全可分解的任务：仅适用于不需要成员间交流的工作（如收割庄稼）。
• 无法分解的任务：受限于次序，增加人手无效。例如，无论多少个母亲，孕育生命都需要十个月。
• 需要沟通的任务：软件开发本质是系统工作，沟通负担包括培训和相互交流。交流的工作量按 $n(n-1)/2$ 递增，这很快会抵消任务分解带来的好处。

4. 经验法则：进度的合理分配

作者提出了针对软件任务进度的经验法则，特别强调了测试的重要性：

• 1/3 计划（比寻常分配更多时间）。
• 1/6 编码（这是最容易估计的部分，仅占小比例）。
• 1/4 构件测试和早期系统测试。
• 1/4 系统测试（所有构件已完成后的最终测试）。
  注： 实际项目中，测试往往占据了进度的一半时间，但不预留足够系统测试时间的做法往往会导致项目后期的灾难。

5. 布鲁克斯法则（Brooks’s Law）

当项目进度落后时，增加人手往往会产生“副作用”：新员工需要老员工培训，且任务需要重新拆分，这会产生额外的沟通和测试成本。作者总结出一个著名的法则：

向进度落后的项目中增加人手，只会使进度更加落后。

总之，软件项目的时间依赖于顺序上的限制，而人数依赖于单个子任务的数量。不合理的紧迫进度安排不仅无法达成目标，反而会因顾此失彼而导致更大的灾难。

第三章 外科手术队伍

《人月神话》第三章“外科手术队伍”探讨了如何组织人员以高效地开发大型软件系统。以下是该章节的关键观点总结：

1. 程序员生产率的巨大差异

研究表明，优秀程序员与平庸程序员在生产率上存在数量级的差异。在对经验丰富的程序员进行测量时，最好的和最差的在生产率上平均为 10:1，而在运行速度和空间占用上也有 5:1 的惊人差距。

2. 大型项目的两难境地

• 小团队的优势：系统应该由尽可能少的人员开发，因为协作沟通成本是开发成本的主要组成部分，且小团队更容易保证产品的概念完整性。
• 大型系统的压力：对于真正意义上的大型系统（如 OS/360 需要 5000 人年），小型精干队伍的开发速度太慢，无法在技术过时前完成产品。
• 矛盾点：为了效率和概念完整性，需要少数干练人员；为了进度，又需要大量人手。

3. 外科手术队伍（Surgical Team）模式

为了调和上述矛盾，哈兰·米尔斯（Harlan Mills）建议将大型项目的每个部分交由一个以“外科手术方式”组建的团队处理，而不是一拥而上的开发模式。该团队的核心理念是：由一个人进行问题的分解和设计，其他人提供支持。

团队的具体角色分工包括：

• 外科医生（Surgeon）：即首席程序员。亲自定义技术说明书、设计、编码、测试并撰写文档。
• 副手（Co-pilot）：外科医生的后备，作为设计的思考者和评估者，了解所有代码。
• 管理员（Administrator）：处理财务、人员、场地和机器等事务，充当与其他机构的接口。
• 编辑（Editor）：负责根据外科医生的草稿分析、重新组织并生成最终文档。
• 程序职员（Program Clerk）：负责维护编程产品库、记录运行日志和归档。
• 工具维护人员（Toolsmit）：确保基本服务的可靠性，并构建团队所需的特殊工具。
• 测试人员（Tester）：设计测试用例并搭建测试平台。
• 语言专家（Language Specialist）：研究简洁、有效使用语言的方法。

4. 运作优势与扩展

• 概念一致性：由于系统主要是一个人（外科医生）思考的产物，且观点不一致时由其单方面统一，避免了平级队员间的妥协，从而实现了极高的概念完整性。
• 简化交流：专业化的角色分工使成员间的交流模式变得非常简单。
• 团队扩建：对于数千人年的项目，可以通过协调多个外科手术团队来实现。这种方式只需要协调几十个“外科医生”的思路，而整个系统的架构由一位系统结构师从上至下进行统一设计。

第四章 贵族专制、民主政治和系统设计

《人月神话》第四章“贵族专制、民主政治和系统设计”探讨了如何在大型项目中通过维持“概念完整性”来确保产品的易用性和质量。以下是该章节的关键观点总结：

1. 概念完整性（Conceptual Integrity）是核心

• 最重要的考虑因素：在系统设计中，概念完整性比任何其他因素都重要。为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提构倡独立且无法整合的系统。
• 易用性的衡量标准：软件的目的是使计算机更易用，因此**“功能与理解上复杂程度的比值”**是系统设计的最终测试标准。
• 一致性带来的简洁：简洁（Simplicity）和直白（Straightforward）源于概念完整性。系统中的每一个部分都应反映相同的原理、原则和一致的折衷机制。

2. 体系结构与实现的分离

• 体系结构（Architecture）：指完整且详细的用户接口说明，它规定了“发生了什么”（如编程手册、语言手册）。
• 实现（Implementation）：描述了“如何实现”这些功能（如内部数据流、内存分配、算法设计等）。
• 结构师是用户的代理人：结构师运用专业技术知识来支持用户的真正利益，而非仅仅维护销售或技术层面的利益。

3. 贵族专制与民主政治的辩证

• 必需的“专制”：为了获得系统的概念完整性，设计必须由一个人或极少数互有默契的人来实现。这在控制概念一致性方面确实是一种“贵族专制统治”。
• 实现者的创造性：虽然结构师定义了外部规格，但实现（Implementation）同样是一项具有高度创造性的活动。给定的体系结构规定实际上能增强而非限制实现小组的创造性，使他们能更专注于解决具体的实现难题。
• 纪律与规则的益处：外部约束往往能催生更好的设计。正如巴赫在受限的形式下创作一样，严格的体系结构限制能使产品拥有更精良的结构。

4. 并行开发与“等待”误区

• 实现人员无需空等：一个常见的误解是，在体系结构说明书完成前，实现人员只能坐等。实际上，一旦有了功能雏形和成本目标，体系结构、设计实现和物理实现这三个阶段可以并行执行。
• 实现者的早期工作：在外部说明完成前，实现人员可以设计模块边界、表结构、算法以及开发各种工具。
• 垂直划分的效率：相比于水平分割工作，这种基于职能的垂直划分（体系结构与实现分离）不仅能提高概念完整性，还能大幅减少交流成本，缩短整体开发和测试时间。

5. 历史教训：OS/360 的决策错误

作者通过 OS/360 的教训指出，为了让庞大的开发团队有事可做而过早让他们介入技术说明的编制，是一个极其昂贵的错误。这种做法不仅没能按时完成任务，还因缺乏概念完整性导致了系统开发和调试成本的大幅增加。

第五章 画蛇添足

《人月神话》第五章“画蛇添足”探讨了软件设计师在面对第二个项目时容易陷入的过度设计陷阱。以下是该章节的关键观点总结：

1. 第二系统效应（The Second-System Effect）

• 最危险的系统：对于一个设计师来说，第二个系统通常是最危险的。
• 产生的诱因：在设计第一个系统时，结构师往往比较谨慎和克制。由于对任务不够了解，他们会将许多产生出来的“润色”功能暂时搁置，留待“下一个”项目。
• 特征：当开始第二个项目时，结构师由于拥有了初次的成功经验，会表现得充满信心。这种信心往往导致他们将之前所有推迟的想法一股脑地塞进新系统中，导致系统变得臃肿、华而不实且过度设计。
• 案例分析：
  • IBM 709：在简洁成功的 704 基础上开发，其指令集过于丰富，以至于只有一半操作被常规使用。
  • OS/360：典型的“第二次开发”例子，包含了许多极其精炼但由于基本理念（如多道程序、动态分配）变更而显得过时的技术，如复杂的链接编辑器和 TESTRAN 调试程序。

2. 结构师与开发人员的交互准则

为了约束架构师的创造性热情，需要建立和谐的交流机制：

• 建议而非支配：结构师必须牢记，创造性和发明性的实现责任由开发人员承担。结构师可以提供实现建议，但不应强行支配。
• 保持低调与灵活：结构师应准备好为说明建议实现方法，但也要随时准备接受其他能达到目标的方法，并在必要时放弃自己的建议。
• 尊重实现成本：开发人员往往对体系结构的修改持反对意见，因为在实现过程中，任何微小的特性修改都可能带来意料之外的巨大成本。

3. 如何避免“画蛇添足”

• 有意识的自我约束：结构师无法跳过第二个系统，但可以意识到其中的危险，运用约束准则来避免功能修饰。
• 功能价值分配：为每个功能设定具体的内存占用（m 字节）和执行时间（n 微秒）预算。这些数值在物理实现期间可充当指南和警示。
• 项目经理的职责：
  • 尽量坚持起用拥有两个系统以上开发经验的结构师。
  • 保持警觉，不断提出问题，确保系统的基本概念和目标在详细设计中得到完整体现，而非被琐碎的功能堆砌所掩盖。

总之，这一章告诫设计者和管理者：经验是一把双刃剑，必须警惕因成功带来的盲目自信，从而在后续产品中加入过多不必要的复杂性。

第六章 贯彻执行

《人月神话》第六章“贯彻执行”主要讨论了在大型软件项目中，如何确保成百上千名开发人员能够理解并遵循结构师的设计决策，从而维持系统的概念完整性。以下是该章节的关键观点总结：

1. 手册：文档化的规格说明

• 核心工具：手册是产品的外部规格说明，描述了用户可见的每一个细节，它是结构师的主要产物。
• 内容边界：手册必须定义所有界面和用户可见的功能，但应避免描述内部实现，以给开发人员留出创造空间。
• 精确性高于一切：手册的风格必须清晰、完整且准确。为了保证一致性，虽然构思可以集体讨论，但书面规格说明应由一到两个人完成。

2. 形式化定义与记叙性文字

• 互补性：由于自然语言容易产生歧义，应配合使用形式化定义（如巴科斯范式、APL等）。形式化定义精确、完整，而记叙性文字负责解释原因、提供例子和展示结构。
• 标准设定：若同时使用两种方式，必须明确指定其中一种为标准，另一种为辅助说明。
• 避免过度规定：使用现有的实现作为定义（如“问机器”）虽然快捷，但会导致“副作用”也变成定义的一部分，从而限制了未来优化和不同算法的使用。

3. 沟通机制：会议与日志

• 周例会：由结构师、实现人员和市场人员参与，重点在于创新解决问题。首席结构师拥有最终决策权，以避免妥协和拖延。
• 年度大会：在手册冻结前举行，处理积压的小问题。这种大规模会议能让所有人参与决策过程，使决策更容易被理解和接受。
• 电话日志：结构师应记录并每周发布所有关于规格说明的疑问及权威解答，确保所有实现人员得到的反馈是一致的。

4. 强制执行的手段

• 多重实现：当一个体系结构有多个同时进行的实现（如 System/360 的不同机型）时，不同团队间的兼容性压力会强制大家严格遵守手册，因为修改机器的成本比修改手册更高。
• 直接整合：利用编程工具（如宏或共享声明文件）来定义模块接口，强制实现人员在编译时包含这些声明，确保语法一致性。
• 独立的产品测试小组：测试小组作为“顾客的代理人”，根据规格说明检查产品。他们是发现设计决策未被正确贯彻的最后一道防线，应与设计工作同时开始实施。

总结来说，第六章强调了文档的精确性、决策的权威性以及沟通的系统化是确保大型项目不偏离设计初衷的关键。

第七章 为什么巴比伦塔会失败

《人月神话》第七章“为什么巴比伦塔会失败？”通过巴比伦塔的典故，深入探讨了大型项目中沟通（Communication）与组织（Organization）的关键作用。以下是该章节的关键观点总结：

1. 巴比伦塔失败的管理教训

巴比伦塔工程具备清晰的目标、充足的人力、材料、时间和技术，但最终却彻底失败了。其失败的核心原因在于交流的缺乏，这导致了成员间无法合作。当合作无法进行时，工作便陷入停顿，随之而来的是争辩、沮丧和群体猜忌，最终导致项目崩溃。

2. 大型编程项目中的交流

在软件开发中，由于各小组可能会在不告知他人的情况下修改程序的功能、规模或速度，这种“左手不知道右手在做什么”的现象会导致进度灾难、功能不合理和系统缺陷。为了实现有效交流，团队应通过以下途径：

• 非正式途径：充分利用电话沟通和清晰定义的内部关系。
• 会议：举行常规技术陈述会议，澄清细小误解。
• 项目工作手册：建立正式且结构化的文档管理体系。

3. 项目工作手册（Project Workbook）

项目工作手册是项目所有文档的组织结构，涵盖目的、外部规格说明、接口说明、技术标准等。

• 作用：它用于组织技术说明并控制信息的发布，确保信息能准确到达需要的人手中。
• 维护机制：随着项目规模扩大，文档量呈非线性增长。有效的维护需要使用活页夹（便于更换变更页）、计算机编辑系统以及微缩胶片或电子化查询系统来减轻归档和空间压力。
• 不同观点：作者也提到了 Parnas 的观点，即通过精确定义接口来实现“信息隐藏”，让程序员只关注自己负责的部分以提高效率。

4. 编程项目的组织架构

良好的组织目的是减少不必要的交流和合作数量，其方法是人力划分和限定职责范围。一个高效的小组子树应具备任务、产品负责人、技术主管、进度、人力划分和接口定义这六个要素。

5. 关键角色的区分与配合

项目成功的核心在于区分两种性质不同的角色：

• 产品负责人（Producer）：主要负责组建团队、划分工作、争取资源、制订进度以及与外部沟通，其工作重点是管理性的。
• 技术主管（Technical Director/Architect）：负责设计构思、系统划分子部分、保证概念完整性和解决技术问题，其工作重点是技术性的。

这两种角色的关系有三种组合模式：

1. 同一个人担任：仅适用于 3-6 人的极小型队伍。
2. 产品负责人为总指挥，技术主管为副手：适合大型项目，但需要负责人预先声明并全力支持主管的技术权威。
3. 技术主管为总指挥，产品负责人为副手：这是作者认为对小型团队最好的选择（如外科手术队伍），由负责人（奴隶）处理所有行政琐事，让技术天才专注于设计。

第八章 胸有成竹

《人月神话》第八章“胸有成竹”探讨了如何估算系统编程任务的工作量和时间进度，揭示了生产率在不同环境和任务复杂程度下的巨大差异。以下是该章节的关键观点总结：

1. 小型项目数据的局限性

作者强调，独立小型程序的数据完全不适用于“编程系统产品”。

• 估算误区：如果仅仅根据编码阶段来推算整个项目，会导致荒谬的结果，因为编码仅占总工作量的 1/6。
• 不可类比性：小型项目的生产率（如每年 3.5 万到 8 万行代码）包含了很少的计划、文档和系统集成工作，将这些数据外推到大型系统就像用百米冲刺速度推算马拉松成绩一样毫无意义。

2. 工作量与规模的非线性关系

研究表明，工作量并不是随程序规模线性增长的，而是规模的幂函数。

• 指数关系：根据 SDC 的研究，工作量大约等于“常数 × 指令数量的 1.5 次方”。这意味着随着系统变大，每增加一行代码所需投入的平均成本会迅速上升。

3. Portman 的数据：实际技术工作时间

查尔斯·波特曼（Charles Portman）发现，团队落后进度的原因往往是对有效工作时间的假设不切实际。

• 50% 规律：日志记录显示，编程团队每周实际上只有 50% 的时间用于真正的编程和调试。
• 时间损耗：其余 50% 的时间被机器宕机、无关的琐碎工作、会议、文书工作、疾病和请假等占用。

4. Aron 与 Harr 的数据：交互与复杂度的影响

不同类型的任务和团队交互程度会导致生产率的剧烈波动：

• 交互程度影响：乔尔·阿伦（Joel Aron）指出，交互极少的项目生产率可达 10,000 指令/人年，而交互较多的项目则降至 1,500 指令/人年。
• 任务复杂度差异：约翰·哈尔（John Harr）的数据显示，**控制程序（操作系统）的生产率约为 600 指令/人年，而语言翻译器（编译器）**约为 2,200 指令/人年。
• 复杂度估算准则：编译器的复杂度通常是批处理程序的 3 倍，而操作系统的复杂度又是编译器的 3 倍。

5. Corbato 的数据：高级语言的生产率优势

通过对 MULTICS 项目的研究，作者得出了关于高级语言（如 PL/I）的重要结论：

• 语句生产率固定：无论使用何种语言，程序员每人年能产出的经调试的语句行数是相对固定的（约 1,200 行语句）。
• 5 倍生产率提升：由于高级语言的一行语句通常对应 3 到 5 行汇编指令，因此使用适当的高级语言可以将编程生产率提高 5 倍。

总结而言，估算软件项目时必须考虑任务的复杂度、团队间的交互开销以及实际有效工时，并意识到高级语言是提升生产率的有力工具。

第九章 削足适履

《人月神话》第九章“削足适履”主要探讨了程序空间（内存和外部存储）的管理与控制。作者指出，虽然硬件在进步，但软件的规模和空间占用依然是核心成本。以下是该章节的关键观点总结：

1. 程序空间是一种核心成本

• 内存租金昂贵：对于用户而言，程序占据的空间也是主要开销。作者通过 IBM APL 系统的例子说明，内存的租用费用往往远超软件本身的使用费。
• 整体评价标准：不应仅因为软件规模大就批评它，关键在于它提供的易用性和性能是否值得投资在内存上的租金。
• 设置规模目标：由于规模直接关系到成本，开发人员必须像硬件商控制元器件数量一样，设定明确的规模目标并加以控制。

2. 规模控制的经验与教训

• 不仅是核心程序：不仅要为常驻内存的程序设定目标，还要为总体规模和后台存储（如磁盘）的访问次数设定预算,。
• 功能与规模挂钩：在设定模块空间预算的同时，必须确切定义其功能。否则，程序员为了达标可能会将原本属于自己的代码（如缓冲区）推给其他模块，导致系统稳定性和安全性受损。
• 防止局部优化：大型项目中，成员容易陷入“为了完成小任务而优化”的误区，忽略对系统的整体影响。系统结构师必须保持持续警觉，培养开发人员面向用户和系统整体的态度。

3. 空间缩减的技能与策略

• 功能与尺寸的交换：通过减少用户可选项目的精细程度（如将选项分组）来节省空间。
• 空间与时间的折衷：通常情况下，空间越多，运行速度越快。项目经理应通过培训和开发公共单元构件库（如队列、搜索例程）来帮助团队达成最佳折衷,。
• 公共库的多样性：公共库中对于同一项功能，应至少有两个版本的实现：一个是运行速度快的，另一个是短小精炼的。

4. 数据表现形式是编程的根本

• 战略性突破：精炼、高效的程序往往源于数据或表的重新表达，而不仅仅是算法的改进。
• 数据结构胜过流程图：作者提出了著名的观点：如果看到数据表，程序结构通常会变得清晰易懂，而仅看流程图往往会让人感到迷惑。
• 根本解决之道：由于空间不足而苦恼的程序员，最有效的办法往往是跳出代码逻辑，通过分析实际情况来重新思考和设计程序的数据表现形式。

总而言之，这一章强调了数据结构在软件设计中的核心地位，并指出通过严格的预算控制和系统整体视角，可以有效地在有限的空间内实现复杂的功能。

第十章 提纲挈领

《人月神话》第十章“提纲挈领”的核心思想是：在海量的文档中，只有少数关键文档是项目管理工作的枢纽，它们是经理们最重要的个人工具。以下是该章节的关键观点总结：

1. 文档是管理工作的核心工具

• 澄清思路：准备文档的过程是项目经理集中考虑并使各种讨论意见明朗化的核心时刻。如果不形成文字，项目往往会陷于无休止的混乱。
• 监控与预警：文档的跟踪维护是项目监督和预警的机制。它们不仅是检查列表，还可以作为状态控制和汇报的基础数据。

2. 软件项目的关键文档清单

项目经理无论项目规模大小，都应建立正式的基础数据文档，其核心关注点在于时间、地点、人物、做什么、资金。关键文档包括：

• 做什么：目标（Objectives）：定义待满足的需求、资源约束和优先级。
• 做什么：产品技术说明（Specifications）：以建议书开始，以用户手册和内部文档结束，其中速度和空间说明是关键部分。
• 时间：进度表（Schedule）。
• 资金：预算（Budget）：预算会迫使技术决策的制定，促使管理层澄清策略决定。
• 地点：工作空间分配（Space Allocation）。
• 人员：组织架构图（Organization Chart）：它与接口说明相互依存。

3. 康威定律（Conway’s Law）

作者引用康威定律指出：设计系统的组织架构受到产品的约束限制，生产出的系统是这些组织机构沟通结构的映射。这意味着一开始的组织架构图往往不是正确的，项目组织必须为系统设计的变化做好准备。

4. 为什么要推行正式文档？

• 决策的确定性：书面记录能使分歧明朗化，强迫人们做出细小的决定，从而形成清晰、确定的策略。
• 高效沟通：项目经理的主要职责是沟通而非单纯的决策。书面计划是唯一精确且可沟通的，能确保团队每个人都向着相同的方向前进。
• 数据基础：文档作为数据基础和检查列表，通过周期性回顾，经理能清楚项目的状态及哪些部分需要调整。

5. 文档不应成为负担

虽然项目经理大约 80% 的时间用于沟通（倾听、讲授、讨论），但这些少量的关键文档封装了经理的工作。如果能尽早认识到它们的普遍性和重要性，就能将文档作为工具友好地利用，而不是将其视为繁重的任务。

第十一章 未雨绸缪

《人月神话》第十一章“未雨绸缪”探讨了软件开发中不可避免的变更以及如何为此做好准备。以下是该章节的关键观点总结：

1. 预先计划抛弃原型（为舍弃而计划）

• 试验性工厂的启示：化学工程师早就发现，在实验室成功的反应过程无法直接在工厂规模实现，必须经过“试验性工厂”来积累规模化运作的经验。
• 第一版通常不合用：软件系统的第一个版本往往太慢、太大或难以使用，除了重新开始之外没有更好的办法。
• 不可避免的选择：管理者的选择不是“是否构建并抛弃一个试验性系统”，而是“是预先计划抛弃它，还是将其直接发布给用户”。
• 发布原型的代价：将原型发布给用户不仅会让用户感到痛苦，还会分散开发人员精力并损害产品声誉。

2. 唯一不变的就是变化本身

• 变更的必然性：变化是软件开发与生俱来的特性，而非异常情况。
• 用户需求的变化：开发人员交付的是“用户满意程度”，而用户的需求和感受会随着程序的构建和使用而不断演变。
• 软件的不可见性：软件易于掌握的特性和不可见性，导致其面临永恒的需求变更压力。

3. 为变更设计系统与组织

• 系统层面的准备：应采用细致的模块化、可扩展函数、精确定义的接口以及完备的文档来应对变化。
• 技术手段：使用高级语言和自文档技术能减少变更引起的错误，同时应采用变更阶段化（如版本号和冻结日期）来管理修改。
• 组织架构的灵活性：团队必须具备灵活性，管理人员和技术人才应根据能力相互培养和互换，以减少社会地位带来的沟通障碍。
• 外科手术队伍的优势：这种组织模式由于接口最少，使系统在最大程度上易于修改和重新安排任务。

4. 软件维护的“退化”规律

• 前进两步，后退一步：程序维护主要涉及修复设计缺陷，但每次修复都有 20% 到 50% 的几率引入新的错误。
• 回归测试的必要性：由于修复会产生副作用，每次修改后必须重新运行先前的所有测试用例，这导致维护成本极高。
• 系统的熵增（无序度增加）：随着版本更新，受影响的模块以指数级别增长，所有的修改都倾向于破坏系统架构并增加混乱程度。
• 重新设计的终点：当系统变得面目全非、修复工作失去根基时，崭新的、对于原有系统的重新设计就变得完全必要了。

第十二章 干将莫邪

《人月神话》第十二章“干将莫邪”主要探讨了编程工具的开发、管理和选择对提高项目生产率的重要性。作者认为，项目经理必须为工具的开发分配资源，并制定统一的工具使用策略。以下是该章节的关键观点总结：

1. 摒弃个人工具集，建立公共工具库

• 个人化的弊端：程序员习惯私自收藏编辑器、排序等工具，但这会妨碍团队沟通，且随着机器和语言的变化，这些工具的寿命很短。
• 公共工具的效率：开发和维护通用的编程工具效率更高。项目经理应为通用工具的开发分配资源，并为每个团队配备专门的工具维护人员（Toolsmith），负责管理通用工具并编制团队需要的专业工具。

2. 目标机器与辅助机器的分离

• 目标机器（Target Machine）：软件最终服务的对象。在硬件开发初期，目标机器往往不稳定且稀缺。
• 辅助机器/辅助平台（Vehicle Machine）：提供编译、汇编、模拟等服务的可靠机器。
• 仿真装置（Simulators）的重要性：当目标硬件不可靠或尚未生产出来时，运行在稳定辅助平台上的仿真装置能提供可靠的调试环境。虽然它不一定精确，但其一致性让开发人员能专注于查找软件 bug，而不是怀疑硬件错误。

3. 机器时间的分配策略

• 分块分配优于零散周转：传统的批处理周转（如每天四次）会让团队陷入等待和指责。作者建议采用**连续的时间块（如 4-6 小时）**分配给小组。
• 生产率提升：连续的精力集中能减少思考时间，提高调试效率。这种“冲刺”式的工作方式虽然可能降低机器利用率，但能大幅提高人的生产率。

4. 受控的程序库管理

为了管理成千上万的代码模块，必须建立正式的程序库系统，将其划分为不同访问权限的子库：

• 开发库（Playpen）：程序员个人的试验区域，可以自由处置，不受限制。
• 系统集成子库（Integration Sub-library）：一旦准备集成，代码拷贝交由集成经理管理，未经批准原作者不得更改。
• 当前版本子库（Current Version Sub-library）：已发布的正式版本，不可更改，作为新模块集成和测试的基准。
• 核心理念：这种机制实现了变更的受控以及开发与集成/发布的正式分离。

5. 核心生产力工具：高级语言与交互式编程

• 高级语言（HLL）：由于高级语言能减少语法和语义错误，并提供更好的诊断机制，使用适当的高级语言（如 PL/I）可将编程生产率提高 5 倍。
• 交互式编程（Interactive Programming）：解决了调试周期长的问题。数据显示，对于系统软件开发，交互式编程的生产率至少是批处理方式的 2 倍。
• 文档系统：计算机化的文本编辑系统是节省劳动力、确保护册进度的关键工具。

总结而言，这一章强调项目经理不应吝啬在工具上的投入，应通过专业的工具维护人员、分层次的程序库管理以及高级语言与交互式工具的结合，来克服大型项目中的沟通与调试瓶颈。

第十三章 整体部分

《人月神话》第十三章“整体部分”主要探讨了如何将经过测试的构件集成并构建成一个可靠的系统。以下是该章节的关键观点总结：

1. 剔除 bug 的设计

• 概念完整性是基础：系统各部分开发者假设之间的不匹配是致命 bug 的主要来源，通过维持概念完整性可以直接减少这类问题的产生。
• 精确的产品定义：许多失败源于产品定义不精确。在编写代码前，应将规格说明提交给测试小组进行完整性和明确性的检查。
• 自顶向下的设计（Top-down Design）：将设计视为一系列精化步骤，从粗略的任务定义开始，逐步分解为细化的算法和数据表达方式。这种方法能带来清晰的结构，实现模块独立性，并允许测试尽早开始。
• 结构化编程：通过使用 DO WHILE 和 IF-THEN-ELSE 等受限的控制结构，避免无限制的 GO TO 语句导致的逻辑错误。

2. 构件单元调试

• 调试的历史演进：调试经历了从早期精细计划的本机调试，到追求机器利用率的内存转储和快照技术，再到现代的交互式调试。
• 交互式调试的有效利用：虽然交互式调试具有实时性，但如果不进行预先计划，其效率会大打折扣。作者建议每 2 小时的终端会话应对应 2 小时的桌面工作，用于清理日志和准备下一次测试用例。

3. 系统集成调试

• 使用经过调试的构件：系统集成应在每个部分都能正常运行之后开始。不提倡“合在一起尝试”或依赖“文档化的 bug”来逃避彻底的单元测试。
• 搭建充分的测试平台：辅助测试代码可能占到产品代码的一半，包括伪构件（dummy component）、涵盖典型记录的微缩文件以及专用的辅助程序。
• 严密的变更控制：必须有专人负责控制构件的变更和版本替换。建立受控的程序拷贝库（最终锁定版、测试修复版、个人开发版）。
• “紫色线束”手法：借鉴硬件调试经验，在发现 bug 时先设计快速补丁（显著标记）以维持测试，随后再进行正式、文档化的源代码修改。
• 一次添加一个构件：拒绝一次性添加多个构件的诱惑，坚持有序地、逐个地添加新构件并进行回归测试，以便更容易定位新出现的错误。
• 阶段化（量子化）定期变更：变更应定期发布，而不是持续波动，从而为其他团队提供一个稳定的调试平台。

总结而言，成功的系统集成需要自顶向下的规范化设计、系统化的构件调试以及极其严谨的集成变更控制。

第十四章 祸起萧墙

《人月神话》第十四章“祸起萧墙”探讨了项目进度如何从微小的偏移演变成灾难性的延迟，并提出了监控和控制进度的具体方法。以下是该章节的关键观点总结：

1. 进度落后的本质：一天一天的滞后

• 白蚁肆虐而非龙卷风：重大的进度灾难很少源于单一的重大变故，而往往是由许多难以察觉的小延迟累积而成的。
• 难以弥补的微小偏移：人员生病、硬件故障、天气原因或临时会议，每件事可能只让进度落后半天或一天，但由于这些小事频繁且持续发生，整个项目会慢慢陷入泥潭。

2. 建立具体的里程碑

• 可度量性原则：里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
• 拒绝模糊的百分比：不应使用“编码完成了 90%”或“调试完成了 99%”这类模糊的描述，因为这些阶段往往没有明显边界。
• 切实的标准示例：有效的里程碑包括“结构师和实现人员签字认可的规格说明”、“100% 源代码编制完成并输入磁盘库”、“通过了所有的测试用例”等。

3. 应对“进度落后”的心理与借口

• 估算的盲点：研究显示，过低的估算在接近结束前通常不会有太大变化，这会导致坏消息在最后时刻才爆发，彻底碾碎团队士气。
• PERT图与关键路径：为了反驳“其他部分反正也会落后”的推诿借口，必须使用 PERT（计划评审技术） 或 关键路径法。它能明确显示哪些任务位于关键路径上，以及某个任务落后多少时间会影响最终交付日期。

4. 信息的透明化与“地毯下面”的污垢

• 一线经理的顾虑：一线经理常倾向于掩盖进度偏差，试图私下解决而不惊动老板，导致真实的进度数据无法上传。
• 区分状态会议与行动会议：老板必须区分**“状态数据”和“行动计划”**。老板应约束自己，不要对经理能自行解决的细小状态偏差过度反应，以鼓励团队提交真实的评估结果。
• 掀开地毯的方法：通过频繁的里程碑评审和 PERT 图来监控真实状态，确保每个人都知道“当时游戏的分数是多少”。

5. 计划和控制小组（Plan and Control Group）

• 区分计划日期与估计日期：计划日期是项目整体的协调目标，而估计日期是底层经理根据现有资源对实际完成时间的最佳判断。项目经理应关注使估计更加精确，而非使其更符合心意。
• 早期的预警系统：大型项目应设立专门的计划和控制小组（1至3人），负责处理文书工作、更新里程碑和 PERT 图。他们作为老板的延伸，充当“早期预警系统”，防止项目以“一次一天”的方式落后一整年。

第十五章 另外一面

《人月神话》第十五章“另外一面”主要探讨了软件文档编制的目的、内容以及实现文档与代码同步的有效方法。以下是该章节的关键观点总结：

1. 文档的多重面貌与必要性

• 沟通的桥梁：计算机程序不仅是传达给机器的指令，更是向用户诉说意图的“故事”。
• 对抗记忆衰退：即使是个人使用的程序，文档也是必要的，因为作者会随着时间推移遗忘逻辑细节。
• 软件产品的核心：对于公共应用程序，向用户呈现的面貌（文档）与提供给机器的内容同等重要。

2. 不同层次的文档需求

根据用户的不同目的，文档应分为三个级别：

• 使用程序：应包含目的、环境、范围、实现功能/算法、输入输出格式、操作指令、选项、运行时间和精度校验。这部分文档（约3-4页）应在程序编制前书写。
• 验证程序：必须附带测试用例，包括常规数据、边界合法数据和非法数据，以确保拷贝正确安装及后续修改后的稳定性。
• 修改程序：为后续开发者提供内部结构概述，包括流程图/结构图、算法详细描述、文件规划、数据流说明以及对预见性修改的讨论。

3. 对流程图的反思

• 被过分吹捧：逐一记录的详细流程图对于有经验的程序员来说是过时且令人生厌的，它更适合启蒙初学者。
• 一页纸原则：只有一页纸规模的、表达程序基本结构或步骤的流程图才是真正有用的。
• 高级语言的替代作用：随着块结构和高级语言的使用，文字列表和良好的代码结构已经使大部分流程图变得冗余。

4. 自文档化（Self-documenting）的程序

• 解决同步难题：维护独立文档与代码的同步非常费力，且文档往往无法及时反映代码变动。
• 合并文件策略：将记叙性文档直接整合到源代码中，能确保开发人员即时得到资料，并直接推动文档的维护。
• 具体实现技巧：
  • 命名与声明：利用标签、声明语句和助记符名称传达意义，并用注释完善变量声明。
  • 格式与结构：使用缩进表现嵌套关系，通过空格提高可读性。
  • 段落注释：插入记叙性的段落注释而非逐行注释，以提供总体把握。
  • 外部引用：引用标准算法书籍以节省空间并增强读者信心。

5. 现代技术的支持

• 高级语言的优势：高级语言和在线系统的普及为自文档化提供了经济和技术上的合理性。
• 减少负担：自文档化方法通过减少冗余输入和物理介质约束，将文档编制的重担降到了最低。

总结而言，这一章主张通过自文档化的技术，将文档编制从一项繁重的任务转变为程序设计中自然、直接且不可或缺的一部分。

第十六章 没有银弹

《人月神话》第十六章“没有银弹”是软件工程史上的名篇，其核心观点是：没有任何技术或管理上的进展，能够独立地许诺在十年内使软件生产率、可靠性或简洁性获得数量级（10倍）的进步。

以下是该章节的关键观点总结：

1. 软件活动的两种性质：根本与次要

布鲁克斯将软件开发任务分为两类：

• 根本任务（Essence）： 打造由抽象软件实体构成的复杂概念结构，包括数据集合、关系、算法和功能调用。这是软件开发中最困难的部分，涉及规格化、设计和测试这些概念结构。
• 次要任务（Accident）： 使用编程语言表达这些抽象实体，并在空间和时间限制内将其映射成机器语言。过去几十年的巨大进步（如高级语言、分时系统）主要解决了这些次要障碍。

2. 软件不可规避的内在特性（根本困难）

由于软件具有以下四个固有属性，导致其开发始终非常困难：

• 复杂度（Complexity）： 软件实体的规模可能比任何人类创造的其他实体都要复杂，且不同部分以非线性方式交互。
• 一致性（Conformity）： 软件必须遵循人为设计的接口和系统，这些惯例往往毫无规则、随时间变化且无法通过再设计简化。
• 可变性（Changeability）： 软件面临永恒的需求变更压力，因为它易于修改，且其生命周期往往长于硬件平台。
• 不可见性（Invisibility）： 软件没有空间的形体特征，难以通过几何抽象来可视化，这严重阻碍了设计过程和团队沟通。

3. 对所谓“银弹”的怀疑

作者分析了当时被寄予厚望的技术，认为它们大多只解决了次要困难，无法带来数量级的提升：

• 高级语言（如Ada）和面向对象编程： 虽然提升了抽象层次，减少了表达上的次要复杂度，但并未解决设计本身的复杂度。
• 人工智能： 语音或图像识别对编程实践差异很小；专家系统虽然能传播优秀实践，但其前提是必须先拥有专家并能提取其知识。
• 图形化编程与程序验证： 软件本质上难以可视化，而数学验证虽然重要，但不仅工作量巨大，且无法保证没有错误，更无法解决需求不明确的问题。

4. 针对根本问题的现实方案

布鲁克斯提出了四种虽然不是“银弹”，但颇具前途的改进方法：

• 购买而非自行开发： 最彻底的解决方案是不开发任何软件。商用软件包通过共享开发成本，能有效提高生产率。
• 需求精炼与快速原型： 软件开发最困难的是决定“做什么”。通过快速原型可以让用户测试一致性和可用性，从而迭代出真实需求。
• 增量开发（增长而非搭建）： 软件系统应该有机地“发育”，先跑通一个仅有伪子系统的空壳，再逐步添加功能。这种模式能显著推动士气并减少风险。
• 培养卓越的设计人员： 卓越设计师的产出往往是一般人的十倍。机构应像培养管理人员一样，有意识地识别、导师化并回报杰出的技术设计人才。

这一章强调，软件开发的进步是逐步取得的，需要持续不懈的努力和规范化的过程，而不是寄希望于某种一蹴而就的魔法。

第十七章 再论没有银弹

《人月神话》第十七章“再论《没有银弹》”是作者在原论文发表九年后，针对各界的反馈、辩论以及软件工程的新发展进行的重新审视和回应。以下是该章节的关键观点总结：

1. 核心概念的澄清：必要性与次要性

• 术语澄清：作者再次强调，“次要（Accident）”并非指偶然发生，而是指“附带的”或“从属的”实现过程。
• 必要（Essence）部分：指构思抽象概念结构（如数据集合、关系、算法）的思维活动。
• 次要（Accident）部分：指将这些概念在实际介质（编程语言、内存空间等）中实现的过程。
• 现实比例：作者认为表达部分的工作量已下降到总工作的一半以下。如果次要部分不足总工作的 9/10，即使完全消除次要困难，生产率也无法获得数量级（10倍）的提升。

2. 软件困难的本质：复杂性

• 根本困难：软件的复杂性、一致性、可变性和不可见性是其固有属性，并非由于编程技术欠缺，而是概念结构本身就具备这些特点。
• 复杂性的分类：并非所有复杂性都是不可避免的。部分复杂性源于应用本身，部分源于实现手段（如数据结构和算法）。
• 应对方案：通过层次化（模块或对象）和增量化（保持系统持续运行）来全力解决复杂性问题。

3. 对“银弹”候选项的重新评价

• 购买而非开发（软件包）：作者坚持认为大众市场软件是软件工程领域意义最深远的开发方向。购买成品软件能将开发成本分摊到海量用户身上，是提高生产率最有效的方法。
• 面向对象编程（OOP）：
  • 被视为一颗**“铜质子弹”**。它通过封装、继承和强类型化解决了高级别的次要困难，允许设计人员表达内在特性。
  • 发展缓慢的原因：OOP 需要极高的前期投入（培训和打造通用类），收益往往在后续开发（如产品族的第五个项目）中才体现出来。
  • 误区：人们往往将其视为工具而非设计方法。如果不懂得如何设计，语言的作用非常小。
• 软件重用：
  • 重用成本高：开发一个可重用构件的工作量大约是“一次性”构件的 3 倍。
  • 词汇量挑战：重用意味着程序员必须学习成千上万个类和函数的语法与语义，这类似于学习一种自然语言，学习成本巨大。

4. 质量与生产率的关系

• 质量带来生产率：作者认同 Capers Jones 的观点，即关注质量自然会提高生产率，因为大量的后续投入是用于修复设计和实现中的错误。
• 管理驱动力：软件工程方法的发展很大程度上是为了追求软件产品的质量和可预见性，以避免由于“艺术家”式开发导致的不可控灾难，而不仅仅是为了提高效率。

5. 结论：回归现实主义

• 没有魔术：软件开发是一件棘手的事情，不存在一蹴而就的魔法。
• 稳步进展：与其等待“空中的馅饼”，不如将焦点集中在可行的事情上。软件生产率的提高将是持续开拓、规范化和增量化改进的共同结果，而非依赖于某种单一的技术突破。

作者最后指出，与其寻找能够点石成金的“点金石”，不如接受软件开发的内在规律，通过辛勤劳动和规范化过程逐步取得进步。

第十八章 人月神话的是或非

《人月神话》第十八章“《人月神话》的观点：是或非？”是对全书核心法则与客观事实的总结性回顾。作者布鲁克斯（Brooks）将 1975 年版中的核心论断以摘要形式重新列举，旨在通过后续的数据和经验来验证这些观点的有效性。以下是该章节总结的关键观点：

1. 软件开发的本质与成本

• 编程系统产品的复杂度：开发一个真正的编程系统产品所需的工作量，是供个人使用的独立构件程序的 9 倍。
• 职业的乐趣与苦恼：编程满足了人类创造事物的渴望，但也伴随着必须追求完美、依赖他人不可控程序以及产品易过时等固有苦恼。
• 软件的复杂性：软件系统可能是人类创造中最错综复杂的事物，这种复杂性是其本质特征。

2. 核心管理法则：人月神话与布鲁克斯法则

• 人月是神话：用“人月”作为衡量工作规模的单位具有欺骗性，因为它暗示人员数量和时间可以互换，但事实上任务分解会增加沟通成本（培训及相互交流）。
• 布鲁克斯法则（Brooks’s Law）：向进度落后的项目中增加人手，只会使进度更加落后。增加人手会带来任务重新分配的中断、新人的培训以及额外的沟通负担。
• 进度的合理分配：建议的进度安排比例为 1/3 计划、1/6 编码、1/4 构件测试、1/4 系统测试。

3. 设计的核心：概念完整性

• 最重要的考虑因素：概念完整性是系统设计中最重要的考虑因素。
• 体系结构与实现分离：为了获得完整性，必须由一个人或具有共识的小型团队完成设计（贵族专制统治），并将体系结构（外部说明）与具体实现（内部设计）分离。
• 第二系统效应：设计师设计的第二个系统通常是最危险的，往往存在过分设计的倾向（如 OS/360）。

4. 团队组织与沟通

• 外科手术队伍：小型精干的队伍是最好的。对于大型项目，通过一位“首席程序员”领导的外科手术式团队，既能保持产品完整性，又能减少沟通量。
• 交流的必要性：项目失败往往源于缺乏交流。团队应通过正式的项目工作手册（记录所有文档）和非正式途径（如周会、邮件）进行沟通。
• 信息隐藏的争议：1975 年时，作者曾不认同 Parnas 的信息隐藏观点（认为每个人应看到所有资料），但在后来的反思中承认 Parnas 是正确的。

5. 变更管理与项目控制

• 为舍弃而计划：由于第一个开发的系统通常不合用，管理上的原则应该是预先计划抛弃原型，并在过程中进行重新设计。
• 软件熵与维护：程序维护本质上是修复设计缺陷和新增功能。随着版本增加，系统会变得越来越无序，维护成本受用户数影响巨大。
• 祸起萧墙：项目进度通常以“一次一天”这种难以察觉的方式落后。
• 里程碑管理：里程碑必须是具体的、特定的、可度量的事件，且需区分“计划日期”（老板的期望）和“估计日期”（基层的实际判断）。

6. 文档与工具

• 提纲挈领：少数关键文档（目标、规格说明、进度、预算等）是经理最重要的管理工具。
• 自文档化：为了易于维护，应将文档（如名称、声明、段落注释）合并至源程序中，而不是作为独立文档保存。
• 高级语言与交互式编程：高级语言能提升生产率（约 5 倍）并减少 bug，而交互式编程能将调试生产率至少提高两倍。

第十九章 20年后再论人月神话

《人月神话》第十九章“20 年后的人月神话”是作者在原书出版 20 周年后撰写的反思，探讨了哪些观点经受住了时间的考验，哪些需要修正，以及行业发生了哪些巨变。以下是该章节的关键观点总结：

1. 核心观点的坚守：概念完整性与结构师

• 概念完整性是质量的核心：作者依然坚信，产品对用户而言易用性的最重要因素是其概念完整性。
• 结构师的必要性：为了获得完整性，必须委派一名产品结构师作为用户的代理，负责产品的概念模型和所有功能说明。即便在大型项目中，也要通过递归的方式保持体系结构的一致性。

2. 对“开发第二个系统”的反思

• 盲目功能（Featuritis）：在面向大众市场的软件包设计中，结构师极易陷入为了增加竞争力而不断堆砌功能、牺牲性能和易用性的诱惑中。
• 明确定义用户群：由于用户群庞大且不确定，结构师应通过猜测或假设用户属性的频率分布来使设计图像明朗化，而非保持模糊。

3. WIMP 界面的成功

• 隐喻的力量：WIMP（窗口、图标、菜单、指针）界面通过“桌面比喻”成功实现了概念完整性，并通过连贯的扩展（如拖放、回收站）提供了强大的易用性。
• 功能与易用性的平衡：通过菜单服务新手，通过快捷键服务专家，实现了从初学者向熟练用户的平滑过渡。

4. 彻底推翻瀑布模型：增量开发与进化

• 瀑布模型的谬误：作者承认原书第 11 章“未雨绸缪”隐含了瀑布模型的假设，即系统可以一次性构建完成，这在实践中是错误的。
• 增长而非搭建：软件系统应像生物一样发育成长（Growing），先构建一个可运行的框架，再逐步添加功能。
• 微软的“每晚重建”：这种高频率的集成与测试是增量开发的一种成功实践，确保了项目的“心跳”和士气。

5. 关于信息隐藏：向 Parnas 认错

• Parnas 是正确的：作者在 20 年后承认，他在第 7 章中反对 Parnas 关于“信息隐藏”的观点是错误的。
• 封装是唯一途径：代码模块应通过定义良好的接口进行封装，内部结构对外部不可见，这是提高软件设计水平和应对变更的唯一途径。

6. 人件与组织管理

• 人是最重要的因素：研究证实，团队质量是项目成功的最大决定因素，其影响远超工具和技术。
• 放弃权力的力量：授权给准自治的小型团队，不仅能激发创造力，还能通过“附属职能行使原理”使整个组织更加繁荣。

7. 软件产业的巨变：成品软件包

• 买来开发：微型计算机革命带来的最重要变化是塑料薄膜包装软件的兴起。软件成本不再是开发成本，而是开发成本与销量的比值。
• 元编程（Metaprogramming）：利用现有的强大软件包（如 Excel、数据库）作为构件进行二次开发，是处理软件根本困难（构思复杂概念结构）的最有效途径。

总结： 软件工程的“焦油坑”依然存在，但 20 年的经验告诉我们，进步来自于增量开发、重视人才、提倡封装以及通过重用成品软件来提升概念级别。