Let’s talk about Brooks's law.
🤔 Why you should care about it
“Adding manpower to a late software project makes it late” - Fred Brooks, American computer scientist and author of The Mythical Man-Month.
All CTOs and engineering leaders have to deal with late software projects. But when the delay impacts the business, they usually have more or less gentle pressure to catch up with the delay, even if it means adding more resources to the project. Unfortunately, nine women can’t make a baby in a month.
😫 Problem(s)
When adding new engineers to an ongoing project:
New engineers need to get up to speed —> sharing knowledge with new engineers takes time from existing resources; the more the knowledge-sharing period lasts, the longer it takes the new engineers to be fully productive.
More people means more overhead —> when new resources join a team or create a new team, it generates additional communication (meetings, discussions, Q&As) and more management time from team leaders.
Key resources become constraints —> in practice, there are always a few engineers who know everything about the project; even when more resources join the project, they still rely on those essential resources to perform some tasks, making them bottlenecks.
😃 Solution(s)
The Bermuda plan —> instead of adding more resources, the project leader removes non-key engineers (“sends them to Bermuda”). In this case, key engineers can fully work on the project and are now free from training, meetings and requests from others. This solution only works when the delay is mainly due to communication overhead.
The incremental approach —> instead of considering a project as a whole and tackling it from the start, it’s better to start with a subset of the desired solution (like a Minimum Viable Product) and improve it iteratively.
💡 Key Concepts
Man-days —> it is common in software engineering to share workload estimates in “man-days” (or “man-hours”, or “man-months”). The danger of this mental model is that it creates the illusion that more "men" will decrease the delay.
Ramp up time —> the time it takes for new team members to get up to become productive.
Communication overhead —> the time team members spend communicating with each other instead of getting productive work done.
Theory of Constraints —> management paradigm focusing on improving a system by organising it around its constraint ("a chain is no stronger than its weakest link).
😡 Detractors
“Brooks’s law considers all manpower equal, but it’s not true.” —> this is correct. Adding an engineer who’s very knowledgeable about the project or someone with a critical missing skill will most likely decrease the delay.
“Sometimes it’s OK to be late if it means shipping the project.” —> if the goal is to ship the project at all costs, it makes sense to add resources and take the necessary ramp-up time. Brookes’s law is only intended for leaders hoping to catch up with the delay.
📚 Top book
The Mythical Man-Month: Essays on Software Engineering - Frederick P. Brooks Jr.
⚙️ Top tool
📝 Top content
❓ Has anyone actually tried "The Bermuda plan" and if so, how did it go? - StackExchange --> a great thread on the Bermuda plan and Brooks's law, with insightful answers.
📼 Breaking Brooks’ Law with DevOps - Jason Yee --> a short video (0:05:00) on how to use DevOps to avoid encountering Brooks's law.
📝 The exceptions to Brooks’ Law - Scott Berkun --> six reasons where Brooks's law does not apply.