布鲁克斯定律
给一个已经延期的软件项目增加人手，通常会让它延期得更久。
显示原始英文内容
Brooks's Law
Adding manpower to a late software project makes it later.
Takeaways
- Simply throwing more developers at a project that's running behind schedule usually slows it down further initially.
- New people take time to get up to speed, consuming existing team members' time for training and coordination, which reduces overall productivity.
- Instead of hoping manpower will solve slippage, adjust the scope or timeline. Be wary of 'just hire more coders' as a solution to lateness.
Overview
Brooks's Law challenges the belief that a software development effort is perfectly divisible among people. In reality, adding a person to a project incurs training costs and increases the number of communication paths. This can outweigh that person's contribution for a while.
If a project is already late, adding new developers can cause further delays as they learn the system and may introduce new bugs. Brooks illustrated this with the observation that "the bearing of a child takes nine months, no matter how many women are assigned." The law doesn't say adding people never helps, but as a response to lateness, it's usually counterproductive.
Examples
A project is one month behind schedule, so management adds 3 new developers to a 5-person team. Over the next few weeks, progress slows. The original developers spend much of their time explaining the design and code to newcomers, and merging their work causes integration headaches. The project slips further, now two months late.
A complex bug required deep knowledge of the system. Adding more people didn't help because only the original dev understood it, and more debuggers only made things worse. Scaling a software team isn't linear. After a point, more members yield less and less output per person.
Origins
Frederick P. Brooks Jr., who managed the IBM OS/360 project, formulated this law based on painful experience. His book *The Mythical Man-Month* (1975) explores why software projects fail and where management assumptions break down.
The book famously challenged the notion that "man-months" are interchangeable. Brooks demonstrated through real-world examples why the assumption that 12 programmers can do in one month what one programmer does in 12 months fails in software development.
核心含义
软件工作很难被完全切成互不依赖的部分。新人需要学习领域和代码，老成员需要投入培训，新增人员还会增加沟通路径和集成冲突。项目越晚，这些成本越可能超过新增产出。
真正有效的应对方式通常是缩小范围、拆分风险、改善阻塞，而不是简单增加人数。
实践例子
一个五人团队已经延期，管理者再加入三名开发者。原成员花大量时间解释系统，新成员的代码又带来合并冲突，项目反而进一步推迟。
来源与边界
弗雷德·布鲁克斯在《人月神话》中总结了这条经验。新增人手并非永远无效：如果工作可以高度并行，或者人员在早期就加入，收益仍可能大于成本。