人月神话 The Mythical Man-Month: Essays on Software Engineering

• 最佳意象：史前焦油坑里，恐龙、猛犸、剑齿虎越挣扎陷得越深——没有哪一只脚是拔不出来的，但"同时挣扎的诸多因素叠加"让一切越来越慢。大型软件就是这样的焦油坑：很多团队最终都能弄出"能跑的系统"，但少有人达成目标、按期、不超预算。
• 核心主张：车库里两个人写出的"程序"，和工业团队交付的"编程系统产品"，不是一回事。后者贵 9 倍。
• 论据（Figure 1-1）：从一个自用"程序"出发——
  • 向"编程产品（programming product）"演化（可被他人运行/测试/修改/扩展，需泛化输入、充分测试、完整文档）：×3；
  • 向"编程系统（programming system）"演化（接口受约束、资源受预算、要与其他组件组合测试，case 数组合爆炸）：×3；
  • 两者叠加 = 编程系统产品，×9。
• 顺带：列举编程的 五乐（造物之乐、被人用之乐、解谜之乐、常学常新之乐、在"纯思想"这种可塑介质里创作之乐）与 五苦（必须完美、目标受制于人、要依赖别人烂代码、调试线性收敛拖到最后、产品未成已近过时）。
• 对 AI 的钩子：人们说"AI 一晚写出一个 App"——那通常是左上角的"程序"。把它变成可上线、可维护、能和现有系统组合的"系统产品"，那 ×9 的工作量 AI 并没替你免掉。

全书最著名的一章。开篇断言："软件项目因缺少日历时间而失败的，比所有其他原因加起来还多。"

为什么估算总是错？ Brooks 给了五个原因，根子是两条：① 程序员都是乐观主义者（"这次一定能跑通""我刚修好最后一个 bug"），默认"一切都会顺利"；② 把"工作量（effort）"和"进度（progress）"混为一谈，背后是"人和月可互换"的假设。

人月为什么是神话——四张图讲清"可切分性"：

• 关键推理：沟通负担 = 培训（随人数线性增长，不可切分）+ 相互沟通（随 n(n−1)/2 即 平方级 增长）。3 人的两两沟通是 2 人的 3 倍，4 人是 6 倍……软件天然是"复杂相互关系"的系统活，沟通成本很快盖过分工省下的时间——于是落到 Figure 2-4：加人=拖慢。
• 测试要留够时间：Brooks 的经验配比是 1/3 计划、1/6 编码、1/4 组件测试与早期系统测试、1/4 系统测试。"调试占一半"远超常人预期；而系统测试在最末段，坏消息总是又晚又突然。
• "没骨气的估算"：因为没有量化依据，经理常屈从于客户/老板想要的日期。解药：一边行业要积累并公开生产率/缺陷数据，一边个人要有"礼貌而固执"的脊梁骨为估算辩护。

再生式进度灾难（Regenerative Schedule Disaster）——一个具体推演：

• 推演结论：加人会触发"培训消耗老手时间 + 任务从 3 份重切成 5 份（已做的部分作废）+ 系统测试拉长"的 再生循环，越救越晚。正确动作通常是 重新排期（"不要小步慢挪"） 或 砍范围。
• Brooks 定律（被作者自称"粗暴地过度简化"）：给一个已经延期的软件项目增加人手，只会让它更晚。

• 真实数据：Sackman/Erikson/Grant 研究发现，同一批有经验的程序员，最好与最差的生产率差约 10:1，速度/空间差约 5:1，且 经验与表现毫无相关。既然少数高手抵得上一群人，又能少很多沟通，人越少越好。
• 困境：可"小而精的团队对真正的大系统太慢"。OS/360 高峰期 1000 多人、约 5000 人年；10 人精英队就算样样快 7 倍，也要 10 年才做完——做完时产品已过时。
• Harlan Mills 的方案：把团队组织成 外科手术队 而非"杀猪队"——一个人主刀（首席程序员/surgeon：亲自定规格、设计、编码、测试、写文档），其余人全力放大他的产出：
  • 副驾（copilot）：能做任何部分、是设计的思考与评估伙伴，但不对代码负责，是"灾难保险"；
  • 管理员、编辑、两名秘书、程序文书、工具匠、测试员、语言律师……共 10 人，七名专业人员，但 系统出自一个（至多两个"心意合一/uno animo"的）头脑。
• 关键洞察：手术队靠 专业分工 换来 极简的沟通结构 和 概念完整性。规模化的秘诀是"把定设计的头脑数除以 7"——200 人只需协调 20 个主刀的头脑。Mills 的精髓是把编程"从私人艺术变成公共实践"：所有运行结果对全队可见，所有程序与数据是团队财产而非私产。

全书思想内核所在。开篇用 兰斯大教堂（Reims） 作引子：它八代工匠各自克制、牺牲部分己见，才有了整座建筑的统一与连贯——这种 设计完整性 带来的感动，不亚于任何局部的精彩。

• 头号主张："概念完整性是系统设计中最重要的考量。" 宁可让系统 省掉某些不规整的功能与改进，也要让它只反映 一套设计理念——一个有许多好但互不协调的点子的系统，不如一个略少功能但浑然一体的系统。
• 检验标准：好设计不是"功能最多"也不是"最简单"，而是 功能 / 概念复杂度之比 最高——即"易用性"。OS/360 以功能多自豪、PDP-10 的分时系统以简洁自豪，但以易用为尺都只抓了一半。简单（simple）还不够，还要直截了当（straightforward）——不需要靠晦涩的组合技巧去表达常见意图。
• 怎么兼顾"统一"与"赶工需要很多手"：① 架构与实现分离；② 上一章的手术队结构。
  • 架构（architecture）= 完整、详尽的"用户界面"规格（对机器是编程手册，对编译器是语言手册）。架构师是 用户的代理人。
  • Blaauw 的名言式区分："架构讲发生什么（what），实现讲怎样做到（how）。" 例：钟表的架构是表盘/指针/旋钮，孩子学会后看手表和教堂钟都会读时；内部机芯是实现。
• 贵族制争议：架构师是不是凌驾于"平民实现者"之上的精英？Brooks 答 "是，也不是"——
  • 是：必须有少数人控制概念，"这是一种无需道歉的贵族制"。
  • 不是：定外部规格并不比设计实现更有创造性，只是 不同的 创造性工作；产品的性价比主要取决于实现者，正如易用性主要取决于架构师。
  • "形式即解放（Form is liberating）"：约束有益于艺术。预算过于宽裕的建筑最糟；巴赫每周一首限定形式的康塔塔并未扼杀创造力。外部给定架构反而 释放 实现组的创造力——他们立刻聚焦于没人解决的部分。
• 百万美元的教训（实现者等待期做什么）：OS/360 决策时，架构经理说他 10 个人能写好规格但要 10 个月；控制程序经理说他 150 人能边做边定、按期完成，否则那 150 人要闲坐 10 个月。Brooks 选了后者——结果 既晚了 3 个月、质量还差，概念不统一让系统更难造、更难改，调试多花约一年。"实现者会闲着"是个幻觉：架构、实现、实现层(realization)三阶段 可以并行启动。

• 核心主张：一个架构师设计的"第二个系统"是他一生中最危险的系统。 第一个系统他谨慎克制（因为不确定）；做第二个时，第一次被他忍住没用的"花边、修饰、点子"全冒出来，倾向于 过度设计——奥维德所谓"积少成多，终成一大堆"。
• 论据：IBM 709（704 的第二系统）指令集臃肿到只有约一半常用；Stretch 计算机被 Strachey 评为"极其精巧、极其复杂、极其有效，却同时粗糙、浪费、不优雅"。OS/360 是大多数设计者的第二系统——典型的第二系统效应。
• 更隐蔽的一种：去精修一种 已被基本假设变化淘汰 的技术。例：OS/360 的链接编辑器把"静态覆盖（overlay）"技术做到登峰造极，却恰逢"多道程序 + 动态内存分配"成为常态——是"最后也最精美的恐龙"。
• 解药：架构师无法跳过第二系统，但可 自觉警惕，给每个小功能 赋值（能力 x 不值超过 m 字节内存、n 微秒）作为纪律；项目经理则坚持用 至少做过两个系统的资深架构师。

问题：10 个架构师如何让 1000 个实现者都"听到、理解、照做"？S/360 硬件项目摸索出一整套技术，对软件同样适用。

• 手册（the Manual）：是产品的 外部规格，架构师的主产出。要 精确、完整、细致，且 同样小心地界定"哪些是故意不规定的"（Blaauw 写的 S/360 兼容性附录是典范）。手册不能描述用户看不到的东西——那是实现者的自由。只能由一两支笔来写，以保证无数"小决定"前后一致。
• 形式定义 vs 散文定义："永远不要带两个航海钟出海——带一个或三个。" 二者并存时必须有一个是标准、另一个是派生描述。
• 直接并入（Direct Incorporation）：把接口声明做成编译期包含（宏 / PL/I 的 %INCLUDE），强制各实现引用同一份声明——改接口只需重编译。（这是后来 Mac 把界面做进 ROM、强制统一的思想原型。）
• 会议与法庭：每周架构例会（强调"先创造方案、后决策"，争不下由首席架构师拍板，决议立即广发）；每半年/一年开一次"秋季大会"清理积压的小分歧（一次约 200 项），靠计算机文本编辑让每人每早拿到更新版手册。
• 多重实现 + 电话日志 + 产品测试：同时造多个实现，是最好的"规格强制执行者"（手册和某台机器不符时通常改手册更便宜，但有多重实现时就不一定了）；鼓励实现者打电话问架构师，但 答复要记录并发给所有人；独立的产品测试组是"项目经理每天的对手与挚友"。

• 管理审计：巴别塔有清晰使命、充足人力物力、足够时间、成熟技术——唯独缺了沟通，及其后果：组织。语言一乱，协调即崩，工程就停。
• 大项目里的沟通：灾难、功能错配、系统 bug，都因"左手不知右手在干嘛"——各队会悄悄改自己程序的功能/大小/速度，及对输入输出的假设。解药是 尽可能多渠道沟通：非正式电话、定期项目会（技术简报）、正式项目工作手册（workbook）。
• 项目工作手册："不是另一份文档，而是强加在项目本就要产出的所有文档上的一种结构。" OS/360 的手册一度厚达 5 英尺、日更 2 英寸，后改 微缩胶片 省了百万美元；放今天作者说该用 共享电子笔记本（带变更条、修订日期、LIFO 变更摘要）。
  • 这里第一次出现 Parnas 的信息隐藏 提议（程序员只看接口、被屏蔽于他人模块内部）。1975 年的 Brooks 斥之为"灾难的配方"（认为暴露接口错误才能促其修正）——这一判断他 20 年后彻底翻案（见第 19 章）。
• 组织：组织的目的是 减少必要的沟通，靠 分工与专业化。树形组织反映的是"权责"（一仆不能侍二主），但 沟通结构是网，不是树，故需要各种"虚线"机制。每个子树要有：使命、生产者（producer）、技术总监/架构师（technical director）、进度、分工、接口定义。生产者管对外/资源/进度，总监管设计/概念完整性——两种才能很不同；三种搭配（同一人 / 生产者为主 / 总监为主）都可奏效（书中用海因莱因小说《卖月亮的人》生动演示了"总监为主、配一个'万事代理'"）。

• 核心主张：不能 用"估编码时间 × 系数"来估总工作量（编码只占约 1/6）；也不能 用孤立小程序的数据外推到系统产品（如同用百米速度外推说人能 3 分钟跑完一英里）。
• 关键事实：工作量随程序规模 呈幂律，即使只有"人与自己记忆"的沟通。多份研究（Nanus-Farr、Weinwurm）给出指数 ≈ 1.5。

• 多组真实数据相互印证：
  • Portman（ICL）：团队总是慢一半，根因是每周只有 约 50% 工时真正花在编程调试上（其余被开会、杂事、宕机、病假吞掉）——估算时对"人年有效工时"假设太天真。
  • Harr（贝尔 ESS）：控制程序 ≈ 600 字/人年，翻译器 ≈ 2200 字/人年；OS/360 数据吻合（控制程序 600–800、翻译器 2000–3000 指令/人年）。
  • Brooks 的复杂度经验法则：编译器比普通批处理应用难 3 倍，操作系统比编译器再难 3 倍。
  • Corbató（MIT MULTICS）：用 PL/I 得到 1200 行/人年——但"行"对应 3–5 个"字"。由此两条结论：生产率以"基本语句条数"计大致恒定；用合适的高级语言可把生产率提高约 5 倍。

• 主张：除运行时间外，程序占用的内存空间是主要成本，必须像硬件控制元件数一样去 设定空间预算、控制规模、发明压缩技术。"规模本身不坏，不必要的规模 才坏。"
• OS/360 的血泪教训：
  • 只设了"常驻内存"预算却没设 总规模 / 后备存储访问 预算——程序员一超内存就拆 overlay，结果总量更大、还疯狂访盘（类似页抖动），Fortran H 模拟编译只有 5 条语句/分钟。教训：总量预算 + 访问预算都要设。
  • 先设空间预算、后分配功能——大家把缓冲、控制块"扔过墙"塞进邻居/系统空间，破坏了安全性。教训：规定模块多大时，必须同时规定它到底要做什么。
  • 沟通差导致每人"挣表现分"、各自次优化而忘了用户整体。培养"全系统、用户导向"的态度，可能是编程经理最重要的职能。
• 空间技艺：先是 功能换空间 的取舍（选项打包 vs 细粒度可选）；再是 空间-时间权衡（多给空间换更快）；最重要的是 发明——"精瘦快"的程序几乎总来自 战略性突破（新算法，或更常见的——重做数据/表的表示）。名句："给我看你的流程图而藏起表，我仍会一头雾水；给我看你的表，通常就不需要流程图了。"——表示（representation）是编程的本质。

• 假说：在纸张的汪洋里，少数几份文档 会成为整个项目管理的关键支点，是经理最重要的个人工具。
• 三类组织对照：计算机产品（目标、规格/手册、进度、预算、组织图、空间、估算-预测-定价）、大学系（目标、课程、学位要求、研究计划、课表、预算、空间、人员分配）、软件项目——结构惊人相似，因为任何管理任务关心的都是 what / when / how much / where / who。
• Conway 定律 在此出现："设计系统的组织，被约束着产出复制其自身沟通结构的设计。" 推论：组织图最初反映的是第一版（几乎必错）的设计；若系统要能改，组织也必须能改。
• 为何要正式文档：① 只有写下来，缺口与矛盾才暴露（写作=做出几百个小决定）；② 文档把决策传达给全员（经理的日常主要是沟通而非决策）；③ 文档是检查表与数据库。Brooks 不信"管理总信息系统"那套幻想——经理只有约 20% 时间需要外部信息。

• 化工类比：实验室工艺不能一步搬进工厂，要先建 中试厂（pilot plant）。软件同理——第一个造出来的系统几乎总是勉强能用（太慢/太大/太难用），必然要重做。
• 名言式主张："准备扔掉一个吧——反正你一定会扔。" 真正的管理问题不是"要不要造一个会被扔的系统"（你一定会），而是"要不要把这个会被扔的，交付给客户"——交付throwaway只换来用户的痛苦、重设计期的分心、和难以洗刷的坏名声。
• 唯一不变的就是变化：要把 变化当成常态 而非意外。Cosgrove 洞见——程序员交付的是"满足用户需求"，而 需求本身和用户对需求的认知都会在开发中改变。软件的可塑与不可见，使其格外暴露于持续变更。
• 为变化而设计：模块化、子程序化、精确的接口定义与文档、标准调用序列、表驱动、高级语言 + 自文档化、变更量子化（编号版本 + 冻结日期）。
• 为变化而组织（Figure 11-1）：比"为变化设计系统"更难。要让人能在技术/管理岗间流动；用 双阶梯（管理 vs 技术，台阶等价）破除"资深人太宝贵不该写代码""管理岗更体面"的社会偏见——而且 从技术转管理同级不能加薪、要叫"调动"不叫"晋升"；反向则要加薪，以矫正文化惯性。手术队结构是对这一问题的"长远答案"。

两步进一步退（程序维护）：

• 软件维护与硬件维护 本质不同：不是清洁润滑，而主要是 修设计缺陷 + 加功能，且通常对用户可见。维护成本通常 ≥ 开发成本的 40%，且 用户越多、发现的 bug 越多。
• Betty Campbell 的曲线（Figure 11-2）：新版本初期老 bug 回潮、新功能暴雷，平稳几月后 bug 率 再次爬升——因为用户到了新的熟练台阶，开始把新功能用透，逼出更隐蔽的 bug。
• 致命规律：修一个缺陷有 20–50% 概率引入另一个，所以是"两步进、一步退"，每次修完理论上要重跑 全部回归测试。
• 一步进一步退（系统熵增）：Lehman/Belady 发现，随版本号增加，模块总数线性增长，但 被改动的模块数呈指数增长——所有修补都在破坏结构、增加熵。"事物在开端时总是最好"（帕斯卡）。系统构建是 降熵 过程（故亚稳态），维护是 增熵 过程，再高明也只能延缓其最终滑向"无法修复的混乱"，直到必须从头重写。

• 主张：项目工具不该像老钳工各藏一套私货。共用的通用工具 利于沟通、利于复用；同时也要 承认专用/个人工具的需求（故每队配一名工具匠）。
• 目标机 vs 载体机（Figure 12-1）：目标机时间在新机初期稀缺，使用量呈"长期闲置→骤然爆满→趋平"的怪曲线。OS/360 的教训：与其精细调度、互相抢机、彼此抱怨，不如 按大块时间整段分配给某个子队——机器利用率也许略低，但 生产率大涨（持续专注减少思考时间）。"系统调试历来像天文学一样是通宵活"，三代机器过去这条规律不变，因为它最高产。
• 载体机与数据服务：新机需要 逻辑模拟器（更早可用，且比早期真硬件更 可靠——"可靠 ≠ 精确"，关键是天天一个样）；编译器/汇编器跑在可靠载体上、为目标机产码。
• 程序库管理（OS/360 的得意之作）：分三级——playpen（个人试验区，随便改）→ 系统集成子库（经理才能授权改）→ 当前发布子库（神圣不可侵）。两个要点：控制（程序副本归经理、唯其能授权变更）与 正式分隔/晋级。这是"一项不可或缺的管理技术"。

• 两件当年没用、却势不可挡的工具（Figure 12-2）：高级语言 与 交互式编程。
  • 高级语言：生产率与调试双赢（更少 bug、更易找、易插快照）；对"做不到/码太大/太慢"三大经典反对，Brooks 认为已基本失效（"我很难想象我会用汇编去造一个编程系统"）。当年唯一合理候选是 PL/I（此判断后已过时）。
  • 交互式编程：调试是系统编程里又难又慢的部分，慢周转是调试的克星——交互式的逻辑"势不可挡"。Harr 数据显示交互式 至少让系统编程生产率翻倍。二者合用（高级语言 + 在线）才是"一对真正锋利的工具"。

• 主题：怎样让程序"能用"、怎样测试、怎样把测好的组件集成为可靠系统。
• 把 bug 设计掉：
  • 概念完整性（4–6 章）直接消除最隐蔽的"系统 bug"（不同组件作者假设不匹配）。Vyssotsky："许多许多失败，恰恰出在那些从未被真正说清的方面。"
  • 测试规格本身：写一行代码前，规格就该交给 外部测试组 审完整性与清晰度——开发者自己做不到（"他们不会告诉你看不懂，而会愉快地凭空脑补填上空隙")。
  • 自顶向下设计（Wirth 的逐步求精）：Brooks 称为"这十年最重要的新编程形式化"，能从四个方面避 bug，且"知道何时该推倒重来"。
  • 结构化编程（Dijkstra 等）：把控制结构当"控制结构"来想（DO WHILE / IF-THEN-ELSE 块），而非零散跳转——是一大进步（但过度教条地禁绝所有 GO TO 也没必要）。
• 组件调试的四阶段轮回：上机调试 → 内存转储（dump）→ 快照（snapshot）→ 交互式调试。Brooks 提醒：交互式时代反而丢了"上机时代"的 预先规划 习惯（Gold 实验：每次会话第一次交互的进展是后续的 3 倍）——"用好终端，桌前 2 小时配机上 2 小时"。
• 系统调试：要 用调试好的组件（别"拼起来试"或"已知 bug 不修就上系统测"——都是一厢情愿）；搭足够多脚手架（可达产品代码的一半）；控制变更（S/360 的"紫线"技巧：临时修用紫线醒目标记并记日志，正式修才进图纸）；一次加一个组件；变更量子化（Lehman/Belady：量子要么大而稀疏、要么小而频繁，后者更易失稳——Brooks 说他绝不冒险用后者；但 1995 年微软证明"每晚重建"能把"小而频繁"做成）。

• 千古名问："一个项目怎么会晚一年？……一天一天地晚。" 灾难往往不是龙卷风而是白蚁——日复一日不起眼的半天、一天滑坡，悄然累积。
• 里程碑还是磨盘（Milestones or Millstones）：里程碑必须是 具体、可度量、刀锋般清晰的 100% 事件（"编码 90% 完成"能持续半个编码期，是假里程碑；"规格已被架构师与实现者签署""调试版通过全部用例"才是真的）。清晰比"老板易核查"更重要——里程碑够利，人就无法自欺，也就不会软化坏消息。
• "反正那块也晚"：用 关键路径 / PERT 图 破解这个泄气借口——它显示谁在等谁、谁在关键路径上、某活动还能拖多久才会进入关键路径。"绘制 PERT 图的过程本身就是它最有价值的部分"——第一张总是糟糕的，做第二张时你会不断发明。需要 hustle（拼劲） 这种提前一步、跑得比必要更快的非物理才能。
• 扫到地毯下（Under the Rug）：一线经理倾向于自己扛、不报忧（怕老板一插手就夺了他的职权）。老板需要两类信息——需行动的例外与用于了解的状态——要 明确区分"状态评审会"与"问题行动会"，并克制自己别在听状态时就抓起电话下命令（否则保证再无人敢如实汇报）。Vyssotsky 的妙招：报告里同时带 "计划日期"（老板的） 和 "估计日期"（最低层经理的），老板"手别碰估计日期"。一个小小的 计划与控制（Plans & Controls）组 对大项目极其值钱——它是"一天一天丢掉一年"的预警系统。

• 主张：程序有两张脸——对机器的（代码）和 对人的（文档）。对产品而言，后者 同等重要。作者坦承多年苦口婆心劝学生写文档失败，后来学 Watson 老爹卖收银机的故事——改"劝"为"示范怎么做"，才奏效。
• 三层文档：给 使用者（散文描述，最缺的是"总览"——只见树木不见森林；列了 9 项：目的/环境/输入域与输出域/功能与算法/输入输出格式/操作说明/选项/运行时间/精度与校验）；给 信任者（测试用例：主线、勉强合法的边界、勉强非法的边界三类）；给 修改者（内部结构总览：结构图/算法/文件布局/pass 结构/预留的钩子与坑）。

• 流程图的诅咒：流程图是"被严重过度推销的文档"。多数程序根本不需要，很少有程序需要超过一页。逐框详图是"过时的累赘"——在高级语言里每个框就是一条语句（Figure 15-2），框可删、箭头多余、只剩 GO TO，而好的块结构本就没几个 GO TO。"我从没见过哪个有经验的程序员会在写程序前先画详细流程图"——流程图几乎都是 事后 补的，这恰恰说明它没用。一页纸的 程序结构图（Figure 15-1） 倒是很有用，且不需遵守 ANSI 流程图标准。

• 自文档化程序（Figure 15-3）：数据处理的基本原理教我们别维护两份需同步的独立文件——但我们恰恰在"机器可读的程序"和"人可读的文档"之间犯这个错。解法是 合并：把文档并进源代码。用本就必须存在的 标签、声明、有意义的命名 承载文档，用 空格与缩进 表现层次，用 段落注释（尤其模块头）讲清"为什么（why）"而非只是"怎么样"——目的（purpose）才是理解的钥匙。书中给了 12 条具体技巧（见图）。自文档化在"高级语言 + 在线系统"下威力最大。

1986 年 IFIP 论文，全书被引用最多、争议最大的一章。核心预言：未来十年内，不会有任何单一的技术或管理突破，能让软件生产率（或可靠性、简单性）提升一个数量级。

• 本质（essence）vs 附属（accident）（仿亚里士多德）：
  • 本质：软件实体是"交织概念的构造"（数据集、数据项关系、算法、函数调用）。真正难的是规格、设计、测试这个概念构造本身，而非把它表示成代码、再检验表示是否忠实。语法错只是"绒毛"，概念错才是大头。
  • 附属：把抽象概念表示成语言、再映射到机器（受空间/速度约束）等"今天碰巧难、但非本质难"的部分。
• 关键算式逻辑：过去的大突破（高级语言、分时、统一编程环境）攻克的都是 附属 难点，且各有自然上限。除非附属难点占总工作量 >9/10，否则把它压到 0 也换不来一个数量级的提升——而它显然没占到 9/10。所以必须转向攻 本质。
• 软件本质的四大固有属性：
  • 复杂性（Complexity）：软件按尺寸算是人造物里最复杂的（没有重复元件——重复的都被抽成子程序了），状态数比硬件多几个数量级，且随规模 非线性 增长。沟通难、不可靠、难用、难扩展、安全漏洞……都源于此。这是本质复杂，抽象掉它往往就抽掉了本质。
  • 一致性/迁就（Conformity）：物理学家相信自然有统一规律；软件工程师面对的却是 人为的、任意的复杂——必须迁就一堆"由不同的人而非上帝设计"的外部接口/制度。
  • 可变性（Changeability）：所有成功的软件都会被改（用户在边界外发明新用法 + 软件比承载它的机器活得更久）。软件是"纯思想"，无限可塑，改动门槛低反而招来无穷变更。
  • 不可见性（Invisibility）：软件无内在几何，无法像建筑平面图那样可视化——它是 多张叠加的有向图（控制流、数据流、依赖、时序、命名空间），且多半非平面、非层次。这既阻碍单脑设计，更severely阻碍多脑沟通。
• 逐个否决候选银弹：Ada/高级语言（只是又一次高级语言，最大红利在第一次跃迁时已吃掉）、面向对象（只移除更高阶的附属难点，对本质复杂无能）、AI、专家系统（最大贡献是把顶尖程序员的经验普及给新手）、"自动编程"（不过是"比当前更高级的语言"的委婉说法）、图形化编程（流程图本就是软件的烂抽象）、程序验证（只能证明"符合规格"，而最难的恰是把规格搞对）、环境与工具、工作站——结论都是 只能带来边际收益。
• 攻本质的有希望方向（乐观面）：
  • 买 vs 造：最激进的解法是 根本不造。大众市场软件的兴起是"软件工程最深远的长期趋势"——开发成本被 n 份拷贝摊薄，等于把开发者生产率乘以 n。
  • 需求精化 + 快速原型："造软件最难的单一环节，是精确决定要造什么。" 客户其实不知道自己要什么，也不可能在造出并试用若干版本前就把需求说全说对——所以要 迭代式地提取与精化需求。
  • 增量式生长（grow, not build）：向自然学习——大脑是 长 出来的，不是 造 出来的。Mills 主张：先让系统能跑（哪怕只调用一堆空子程序），再一点点长出血肉，每一阶段都有可运行的系统。Brooks 说这"过去十年里最彻底地改变了我自己的实践"，士气效果惊人。
  • 培养伟大的设计者：好实践可教，能把"差"提到"好"；但"好→伟大"靠的不是方法论而是 天才（如 Salieri 与 Mozart，差距近一个数量级）。激起狂热粉丝的系统，都出自一个/极少数伟大头脑（Figure 16-1）。所以最重要的努力是"想办法培养伟大设计者"，把他们当作和优秀经理同等稀缺、同等值得培养奖励的资源。

对九年间各方反驳的回应与澄清。

• 澄清术语："accident"取亚里士多德古义，指"附带/非本质"，不是"偶然/不幸"。
• 这是个事实问题：争论归结为——今天软件总工作量里，"概念构造"与"表示构造"各占几成？Brooks 估计附属部分已降到 约一半或更少；而 没有任何人公开主张它高达 9/10，所以"必须攻本质"的结论不可动摇。
• "悲观"之辩：怀疑不是悲观。引 Turski 的雄辩——找软件生产率的"银弹"，无异于炼金术士找"点金石"，是"一厢情愿的纯萃取"；接受"有些问题无解"很难，但 空想会阻碍真实进步、浪费精力。Brooks 自陈是"乐观病"患者（程序员的职业病）。
• Jones 的洞见：别盯生产率，盯质量，生产率会随之而来——晚而贵的项目把多出的时间都耗在找改错误上。
• 对面向对象/复用的最新观察：OO 是"多种维生素一次吃下"（模块化+封装+继承+抽象数据类型），很有前途但 成长缓慢——病根是 成本前置、收益后延（第五个同族项目才"快得发烫"），需要"管理上的勇气"这种比技术能力稀缺得多的东西。复用"说起来比做起来容易得多"，要好设计 + 极好文档；还有个"被预见却没被预见"的拦路虎——复用即学习庞大词汇表（类库上千成员），要借鉴人类习得语言的方式（在句子语境中、在使用中增量学习）。
• 立场不变：复杂性是我们的行当，也是限制我们的东西；停止空想，转向 可得的渐进式改进。

• 这章是什么：Brooks 把全书 剥去论据、提炼成一条条可操作、可证伪的"命题"（按章编号，如 2.11=Brooks 定律），并用 方括号加注 1995 年的看法。他自嘲："如果全书就这么点东西，为什么用了 177 页来说？" 这等于 作者亲手做的"全书提要 + 勘误表"，是回查和检验论点的最佳索引。
• 几条最值得记的自我标注/更新：
  • 7.15 → 7.15 翻案：原文"Parnas 的（信息隐藏）提议是灾难的配方"——加注："我已被 Parnas 彻底说服，完全改变了看法。"
  • 8.4：原说工作量随规模指数 ≈1.5；加注 Boehm 的数据并不同意，约在 1.05–1.2。
  • 11.2 / 11.13 / 12.13 / 12.16：beta 版/编号版本已成常规；高级语言与交互式 已普遍采用；"唯一候选 PL/I" 已不再成立。
  • 9.10 / 9.13：随虚拟内存与廉价内存普及，许多"空间换时间"的精细决策 已过时。
• 通读这一章，能在 10 分钟内复盘全书骨架，并清楚 哪些经久不衰、哪些被时代淘汰。

1995 年的长篇回望，回答三问：当年写对了什么、什么过时了、软件世界真正的新东西是什么。也是全书 作者自我纠错最集中 的一章。

• 仍然正确、且"今天更确信"的核心：概念完整性 + 架构师。
  • 概念完整性是产品质量的中心；设立系统架构师是迈向它最重要的单一步骤。架构师是"导演"、经理是"制片人"。
  • 架构与实现分离；大产品要 架构师递归（主架构师切子系统，各子系统再有自己的架构师）。
  • Brooks 教了 20 多遍软件工程实验课后，坚持连 4 人小队都要分设"经理"和"架构师"——即便对小队略显极端，但确实有效。
• 第二系统效应的当代形态：面向大众用户集做"通用工具"比做"专用工具"更难（要给众多需求赋权重）。最大诱惑是 功能炎（featuritis）——不断加边际功能，牺牲性能与易用（点名 Word 6.0"功能塞满、又大又慢"）。解药：明确写下"用户集"的画像与各属性的频率分布——架构师应该去 猜/假设 一套完整频率，"宁可明确而错，也不要含糊"。（并澄清第 5 章"危险的第二系统"与第 11 章"准备扔的第二次尝试"是两个不同的"第二"，并不矛盾。）
• WIMP 界面的胜利：是"靠采用熟悉心智模型（桌面隐喻）达成概念完整性"的绝佳范例（重叠窗口、拖放、图标、回收站都直接源自隐喻）。难点在"动词怎么表达"——选了菜单；又用 快捷键（command-z/x/c/v/s） 让新手→高手 平滑过渡。Mac 把界面做进 ROM 强制第三方统一——正是第 6 章"直接并入"思想的成功印证。（但 Brooks 预言 WIMP 一代后会过时，动词将由 语音 表达。）
• 大纠错一：瀑布模型是错的（Figure 19-1）：

• "准备扔掉一个"诊断对、药方错——它隐含了 瀑布（顺序）模型。瀑布的根本谬误：假设项目 一次走完，错误都只在"实现层"、能边测边补；于是把 系统测试/用户测试压到最后，等全部造完才发现"用户用着别扭/性能不可接受"。"下游的经验与想法必须像鲑鱼一样 逆流而上"，往往要在落地成代码前 迭代两三轮架构-实现。
• 大纠错二：增量式生长更好（Figure 19-2 / 19-3）：

• Mills 的做法：先建实时系统的 轮询主循环 + 一堆空 stub，编译、测试，让它"正确地空转"；再逐个充实输入/输出模块……每一阶段都有可运行（且已测）的系统。好处：极早就能让真实用户测试；可采用 "按预算造（build-to-budget）" 策略，绝对防止进度/预算超支（代价是可能功能不足）。Brooks 说改教增量式开发后，"那第一张画面、第一个能跑的系统"对团队士气有 电击般 的效果。

• Parnas 家族（Figure 19-3）：把产品设计成一 族 相关产品，预判横向扩展与后续版本，把最不易变的决策放树根——最大化复用，也契合增量式生长。
• 微软"每晚构建"：增量式的逻辑极致——每晚重建整个系统并跑测试，"构建周期成了项目的心跳"，构建一断就全停修复；"它给团队对自己的信誉，而信誉决定士气"。
• 大纠错三：关于信息隐藏，"Parnas 对，我错了"：第 7 章 Brooks 主张"全员看全部"（Mills 的"编程是公开过程"），斥 Parnas 的封装为灾难配方。20 年后他 认输："信息隐藏（今天体现为面向对象）是提升软件设计层次的唯一途径"——它对变化稳健，更契合"为变化而设计"。这也是从 模块封装 → 抽象数据类型 → 面向对象（继承） 这条研究主线的起点。
• 量化验证"人月神话"：Boehm 对 63 个项目的研究 坚实地证实了 人月的非线性：
  • 最优首发工期 T = 2.5 × (人月)^(1/3)（最优工期随工作量的 立方根 增长）；
  • 工期比最优 长 时成本缓升（人有多少时间就用多少）；比最优 短 时成本陡升；
  • 几乎没有项目能在最优工期的 3/4 以下完成，不管投入多少人——这给软件经理对抗"不可能的进度承诺"提供了硬弹药。
  • 对 Brooks 定律的严肃建模（Abdel-Hamid/Madnick、Stutzke）结论：加人总是更贵，但不总是更晚——越早加越安全，且新人必须是"愿意融入现有流程、而非来改流程"的团队型选手。Brooks 表示仍坚持那句"粗暴简化"的定律作为最佳零阶近似。
• 人几乎就是一切：全书偏重管理而非技术，是因为 人的素质、组织与管理，远比工具或技术路线更能决定成败。Boehm 的 COCOMO 发现 团队质量是成功的最大因素，比第二大因素强 4 倍。盛赞 DeMarco/Lister《Peopleware》——"我们工作的主要问题与其说是技术的，不如说是社会学的"；安静、私密、足够的空间与生产率/缺陷率强相关。
• 放权的力量：创造力来自个人而非结构。引 Schumacher《小的是美好的》与教皇通谕的"辅助性原则"——中心通过向下放权反而会赢得真正的权威，整个组织更幸福繁荣。微软、IBM 的特性团队（拥有自己的功能集、进度甚至流程）印证了这一点。
• 最大的意外：几百万台计算机——微机革命与盒装（shrink-wrapped）软件业是这二十年最关键的变化。它改变了所有人用计算机、造软件的方式，并催生 "买 + 造"（用大众软件包当"组件"搭定制系统）与 元编程（metaprogramming） 这一真正"攻本质"的新模式。

• 原结语（1975）：软件系统是人类所造之物中 最复杂（按不同零件种类计） 的；软件工程的焦油坑会 长期黏稠 下去。
• 1995 结语：Brooks 13 岁读到哈佛 Mark I 落成、读到 Vannevar Bush 的超文本设想而入迷，一生以此为业。"能靠做自己本就愿意免费去做的事谋生，是上帝给少数人的特权，我深怀感恩。" 从机械到真空管到晶体管到集成电路——他的 Mac PowerBook 已比当年最快的 Stretch 超算 快上千倍、便宜五千倍。"不仅终点遥不可见，步伐也毫不放缓。我们还有许多未来的喜悦。"