弗雷德·布鲁克斯本周去世了。根据你的年龄，你可能知道他是计算机领域的泰斗，也可能知道他是计算机科学教科书中一些经典语录的作者。事实上，他两者兼具。
布鲁克斯领导开发了IBM的System/360和OS/360 ，这两款系统是计算机发展史上的革命性里程碑，也是几乎所有现代系统的先驱。在这些大型项目中，布鲁克斯积累了许多关于如何组织软件项目的宝贵经验，并就此发表了论文和演讲。
那句著名的格言“给一个已经延期的软件项目增加人手只会让它更晚”（布鲁克斯定律）出自他的著作《人月神话》，这本书几乎每个计算机科学从业者都至少听说过。他在书中提出的核心论点是，很多项目并不会因为增加人手而受益。
如果你在砌沙袋墙，人手越多，装沙袋和堆垛就越紧张，只要沙子和沙袋供应充足，增加人手就能加快进度。但软件项目就不同了。如果你想在月底前交付代码，突然往项目里塞100个工程师只会让情况更糟。
对于许多管理者或日常工作并非从事 IT 行业的人来说，这可能不太符合直觉，但仔细想想，其中的原因其实很合理：
上手时间：在了解当前使用的工具和库、学习这些工具和库、理解代码布局、获得必要的权限、了解团队规范（从编码风格到提交要求等）之前，我无法为代码库做出贡献。所有这些都需要时间，尤其是现有工程师的时间。当现有工程师向我演示如何提取数据或我们将使用哪些数据库客户端库时，他们自己是不会编写代码的。
组合爆炸：一旦项目启动运行，我就需要与其他所有工程师沟通协作。项目只有四个人时，这不算什么大问题。但当团队人数达到 20 人甚至 200 人时，仅仅是让每个人都了解项目进展和保持沟通就耗费了越来越多的时间。人们可能会认为，有了如此琳琅满目的沟通工具，这应该会容易得多。的确，现在更容易了——你可以发送电子邮件或 Slack，而无需再打印备忘录。但问题是，其他人还得花时间阅读这些备忘录！
并非所有任务都能拆分：有些任务需要一到几个人集中精力完成，因为他们拥有专业化的领域特定技能。正如布鲁克斯所说，“九个女人一个月也生不出一个孩子”。增加人手就相当于对人员进行长时间的复杂领域培训。这并非指大学里能学到的知识或通用的计算机科学知识，而是指已经构建的高度复杂的系统，或者某个应用领域的所有专业知识都仅限于团队内部的情况。
《人月神话》一书提供了更多真知灼见，内容涵盖软件工程的诸多领域。布鲁克斯——一位妙语连珠的作家——曾说过，这本书是软件工程的圣经，因为“人人都引用它，有些人读它，而只有少数人真正遵循它”。
布鲁克斯曾获得图灵奖，享年91岁。
