《人月神话》初版是 1975 年。我读的是二十周年纪念版，那也已经是三十年前的事了。一本讲软件项目管理的书能活这么久，本身就是个不太光彩的事实——它还没过时，说明我们还在犯同样的错。
我想挑三个印象最深的判断，然后回答一个问题：为什么明知故犯。
一、向延期的项目增加人手，只会让它更晚
这就是著名的布鲁克斯定律。理由并不玄乎：新人需要培训，需要有人带；更要命的是沟通路径的增长。三个人之间有三条沟通路径，四个人是六条，十个人是四十五条，这是平方级的增长，而人力的增加是线性的。过了某个点，加人带来的沟通成本就超过了它带来的产出。
我经历过一次教科书级的验证。一个赶不上日期的活儿，临时从别处借了三个人来。头两周，原班四个人里有两个几乎全职在给新人讲上下文，实际产能不升反降。等新人真能独立干活的时候，日期已经过去了。
二、没有银弹
作者把软件的困难分成两类：本质复杂性和附属复杂性。附属复杂性来自工具、语言、环境，可以被技术进步消灭；本质复杂性来自问题本身——需求的模糊、概念结构的纠缠、必须可变的要求，它不会因为你换了更好的工具而减少。他的预言是：没有任何单一技术能在十年内让生产率提高一个数量级。
这几十年里，被宣称为银弹的东西排着队出现。它们大都确实有用，但有用的部分基本都落在附属复杂性那一侧。而“把需求想清楚”这件事，至今仍然只能靠人坐下来慢慢想。
三、概念完整性比功能丰富更重要
这是我最晚才理解的一条。作者说，一个由少数人设计的、略显简陋但概念统一的系统，好过一个汇集了所有人聪明想法、功能更多却风格分裂的系统。因为用户学的不是功能表，是一套心智模型；心智模型一旦不统一，功能越多越难用。
我做过一件后来很后悔的事：为了让每个提意见的人都满意，我把一个小工具的配置项从五个加到了十七个。功能确实都在，但没人会用了，包括半年后的我自己。
那么，为什么还在犯
我的答案是：因为这些错误的正确解法在当下是不可见的，而错误解法是可见的。
项目要延期了，需要向上交代。此时“加三个人”是一个立刻能被看见、能被汇报、能被理解成“我们正在积极应对”的动作。而正确的动作——重排优先级、砍掉一部分范围、承认日期本来就不现实——全都是需要说坏消息的动作。前者的成本发生在未来，而且很难归因到某个人头上；后者的成本立刻落在说话的人身上。
所以布鲁克斯定律不是一个认知问题，是一个激励问题。写在书里的道理人人都懂，但懂道理和愿意承担说真话的代价，是两码事。这大概也是为什么这本书四十多年了还要一版一版重印：它治的不是无知，是怯懦，而后者比前者顽固得多。