项目已经延期三个月。会议室里有人说，再招五个人吧。

另一个人抬头，语气像念出的咒语：

布鲁克斯定律，给延期项目加人，只会让它更延期。

于是招聘暂停，会议结束，所有人都显得很懂软件工程。

这就是软件工程「定律」最舒服、也最危险的用法，它只需要一句话，就能把一团烂麻似的现实压扁。需求是不是还在变？新来的五个人负责的是不是能独立切出去的模块？代码库有没有文档？接口是否稳定？原团队到底缺人，还是缺决策？先别问。弗雷德·布鲁克斯已经说过了。

问题在于，布鲁克斯说的比这句复杂得多。

《人月神话》里的布鲁克斯定律，确实写得很狠，向一个已经延期的软件项目增加人手，会使它更加延期。但原文紧接着讨论的是软件工作里无法并行的部分，新人需要理解系统，需要被带教，需要和原团队建立沟通路径；有些任务不是九个女人一个月就能生出一个孩子，哪怕项目经理把排期表画成瀑布也没用。

布鲁克斯甚至在给出那句名言前加了一句，这是「极度过度简化」。这句免责声明后来在传播时掉得比日志里的 debug 级别还快。

所以，布鲁克斯定律不是「人越多越慢」，更不是「招聘无用」。它描述的是一个很具体的失配，项目已经落后，剩下的关键工作又高度依赖既有上下文和顺序关系，此时把陌生人塞进来，沟通和培训的成本可能先于产出到来。

如果你把五个人放进一个马上要上线、边改边冒烟的核心支付链路，布鲁克斯大概率会点头。如果你让他们接手已经边界明确的测试基础设施、数据迁移工具、独立后台、文档和自动化脚本，事情未必如此。前者是在往一辆时速 120 公里的车里换司机；后者更接近多开几条已经铺好的辅路。

一句定律本身没有说错。问题在于它把「何时成立」藏在了名字后面。

帕金森定律常被项目管理者拿来给短 deadline 加一层理论镀膜，「工作会扩张，填满所有可用时间，所以工期要压紧。」

听起来像管理学版重力定律。给你一周，需求就会做一周；给你三天，大家就会神奇地在第三天交付。

可 西里尔·诺思古德·帕金森 1955 年写的原文（帕金森定律），讨论的是英国行政体系的扩张，语气里带着讽刺。他观察到的是官僚机构如何制造彼此的工作，不是一项关于软件研发周期的随机对照试验。

把它迁移到软件行业不是不可以。范围膨胀、过度打磨、迟迟不做决策、为了「顺手」重写半个模块，这些现象谁都见过。但从「团队会拖延或扩张范围」跳到「所以压缩工期能提高效率」，中间少了好几页内容。

工期压短，有时会迫使团队砍掉伪需求；有时也会让测试、设计和迁移方案全部被砍掉。前一种叫聚焦，后一种叫把债务改名为下个季度的风险。两者都可能按时上线，PPT 上看不出区别。

霍夫施塔特定律更诚实一点。它说，事情总比你预期更久，哪怕你已经考虑了霍夫施塔特定律。它来自 霍夫施塔特 对复杂任务估时的自指式吐槽，而不是一条估算模型。

它的价值不在于让你放弃估时，恰恰相反，它提醒你，估时该从「我们有哪些未知」开始，开发要几天是后面才有答案的事。要接第三方支付，文档读完了吗？旧数据脏到什么程度？权限模型有没有遗留规则？上线是否需要双写和回滚？如果这些问题都没搞清楚，工期后面硬加 30%，也不叫留余量。

康威定律是这批名言里最值得认真对待的一条，但也最容易被用成万能解释。

它原始的判断是，设计系统的组织会受到自身沟通结构约束，产出的系统结构会成为这种沟通结构的副本。这个观察有直觉基础，两个团队如果长期各管一摊、接口靠工单和排期维持，最终很容易在系统边界上留下厚重的适配层、审批流和数据复制。

后续研究并非没有支持。一些研究发现，组织耦合方式与产品模块化程度之间存在关系；也有研究指出，在软件项目里，这种对应关系并不总显著，或者并不必然影响项目结果。

这才是康威定律该有的位置，它是一副有用的观察镜头，不是一台架构预言机。

一个团队按前端、后端、数据库分工，系统未必必然长成三层单体。一个公司按业务域组织，也未必自动获得优雅的微服务。组织结构会制造阻力、信息边界和协调成本，但架构还会被历史代码、部署方式、数据一致性要求、监管边界、团队能力和产品节奏共同塑形。

把康威定律说成「架构必然是组织结构的镜像」，是把「受约束」偷换成了「被决定」。

工程里这种偷换特别常见。因为「受影响」听起来很软，「必然如此」听起来很像掌握了宇宙密码。

古德哈特定律如今常被引用成，

当一个度量成为目标，它就不再是好度量。

这句话很适合贴在 OKR 会议室门口。代码行数被当 KPI，大家开始造行；关闭工单数量被当 KPI，工单开始被拆碎；可用性被当 KPI，告警阈值忽然变得异常宽容。

方向没问题。但原始表述更窄，当一个被观察到的统计规律被施加控制压力时，它会趋于失效。古德哈特讨论的是货币政策中的统计关系；今天广泛流传的那句，是后来更易传播的转述。

这点细节不只是考据癖，因为「只要量化就会失真」也是一种偷懒。没有指标，团队可能靠声量决策；只有一个指标，团队会优化这个指标；有多个相互牵制的指标，外加抽样检查、定性复盘和对指标副作用的监控，情况又不同。

古德哈特定律真正应该逼人问的，从来不是「要不要 KPI」。要问的是，「这个指标一旦和奖金、晋升、资源绑定，人们最容易用什么方式把它做漂亮？而这种漂亮，会不会刚好伤害我们本来想要的东西？」

如果一个团队给出了答案，它已经比在复盘里甩出「古德哈特定律」四个字强得多。

软件工程特别容易生产这种句子，原因不神秘。

第一，软件项目的变量太多，实验太难做。你很难像物理学家一样，把两个完全相同的团队放进完全相同的组织、需求和市场条件里，只改变「是否中途加人」这一个变量。于是大量重要经验只能来自案例、复盘、长期观察和失败记录。

第二，工程师的日常工作又需要快速决策。你不能每次讨论组织拆分、排期、重构、指标设计，都先做一篇系统综述。短句是认知缓存，它帮人迅速记住一个曾经反复伤人的模式。

第三，命名会制造权威。把「项目后期加人有风险」叫作「布鲁克斯定律」，它立刻从一个需要继续讨论的判断，变成了一个仿佛不该顶嘴的结论。人名、引号和一个「定律」，是技术圈最便宜的认证章。

所以我不反对这些定律。没有它们，团队很容易重复踩一些已经被前人踩烂的坑。

我反对的是另一件事，把它们当作停止思考的许可证。

「布鲁克斯定律」后面该接的问题是，这个项目还有多少工作可并行？

「康威定律」后面该接的问题是，我们现在的沟通边界，究竟在哪些接口上制造了成本？

「古德哈特定律」后面该接的问题是，指标会诱导出什么行为？

「霍夫施塔特定律」后面该接的问题是，我们究竟不知道什么？

如果一句定律没有把讨论带到这些问题上，它就不再是经验压缩，它变成了工程版占卜。

软件工程缺的从来不是更响亮的名言。

缺的是有人在名言被念出来以后，愿意多追问一句，它在这里，到底适不适用？