人月神话
The Mythical Man-Month
Brooks法则说给落后项目加人会让它更慢——但真正的洞察不止于此：他证明「人月」是个致命的会计错觉，人和月在概念性创造活动里根本不可互换。
- 加人不是不能加，是不能在晚期加：新人ramp-up成本+任务重分成本+沟通成本呈n(n-1)/2爆炸式叠加
- 第二个系统才是最危险的系统：第一个项目谨慎保守，第二个项目信心爆棚容易过度工程
- 没有银弹的论证是结构性的：复杂度/一致性/可变性/不可见性是软件的本质属性，工具只能压缩次要成本
核心观点
9个女人不能在1个月内生出孩子：人月是致命的会计错觉
12个人月的活可以12人1月做，也可以4人3月做——这个换算假设本身就是错的。人和月在软件这种概念性创造活动里根本不可互换，因为沟通成本、任务分解成本、学习曲线都不是线性可加的。
无论多少个母亲，孕育一个生命都需要十个月。
— Frederick P. Brooks Jr.给落后项目加人只会让它更落后：三层成本同时叠加
新员工需要有经验的员工培训，这本身就占用了老员工的时间；已划分好的工作要重新分解，部分已完成的工作会被浪费；沟通成本按n(n-1)/2增长——三个人的沟通量是两个人的三倍，四个人是六倍。这三层成本乘性叠加，越到项目后期加人越是灾难。
第二个系统才是最危险的，不是第一个
程序员做第一个项目时谨慎保守，因为不确定自己的能力边界；做第二个项目时信心爆棚，把第一次被压抑的所有想法全部塞进去。OS/360用26字节的常驻例程去处理一个本可以留给操作员手动解决的闰年问题，就是典型的过度工程案例。
- 把v1里所有被压抑的功能想法全部塞进v2
- 让同一个人无约束地设计第二个大系统
- v2启动前设一个功能上限，超出部分推到v3验证
- 让至少两个有经验的架构师互相制衡
没有银弹：软件的复杂度是本质属性，工具只能压缩次要成本
任何技术或管理进展都不可能在十年内让生产力提升一个数量级。复杂度、一致性、可变性、不可见性是软件与生俱来的性质，工具改进只能减少「敲键盘、查文档」这类次要成本，无法消灭「我到底想要什么系统」这类本质困难。
| 成本类型 | 定义 | 能否被工具消灭 |
|---|---|---|
| 次要复杂度 | 敲代码/查文档/写样板 | 可以——IDE/AI辅助能压缩 |
| 本质复杂度 | 系统需求本身的复杂性 | 不能——需要人类持续思考 |
概念完整性比正确性更重要：一致的烂方案胜过不一致的好方案
宁可省略一些不规则的改进特性，也不要接受无法整合的系统，即便那些设计各自都很出色。概念完整性要求设计必须由一个人或极少数有默契的人主导，这是一种「无需道歉的贵族专制」——多头设计会让系统迅速失去内在一致性。
概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
— Frederick P. Brooks Jr.免费部分到这里。墙内还有：
本书与另外 4 本书的观点交锋 · 应用篇
金句摘录
「Adding manpower to a late software project makes it later.」
「Plan to throw one away; you will, anyhow.」
「There is no silver bullet.」
常见问题
这本书讲了什么？
Brooks法则说给落后项目加人会让它更慢——但真正的洞察不止于此：他证明「人月」是个致命的会计错觉，人和月在概念性创造活动里根本不可互换。
适合谁读？
从核心观点看，适合想搞清楚「9个女人不能在1个月内生出孩子：人月是致命的会计错觉」这类问题的人。
最核心的一个观点是什么？
9个女人不能在1个月内生出孩子：人月是致命的会计错觉