Can mob programming break Brooks's Law?

by Jeff Langr

December 01, 2021

“Fred Brooks,” courtesy Wikimedia - license here

Brooks Law

Adding manpower to a late software project makes it later. So states the eponymous Brooks’s Law, declared by Frederick Brooks in his 1975 book The Mythical Man-Month. Seems plausible: If we’re near a project’s due date, we’re not very likely to ramp up a new person enough to speed up delivery in time. Instead, we will slow down as we try to onboard the new developer, and thus deliver later.

Iterative and incremental development (IID) processes, such as agile software development, play on this presumed-axiom: We can potentially add a new team member and avoid delivering late, if and only if we do so soon enough (i.e. before the project is considered late). Thus the interest in delivering a small increment early, then using data from that partial effort (“what portion of the work is done?”) to estimate a new done date. We can fix things if we adapt the moment we sense a problem. Brooks’s Law remains valid, because we’re not late in the game.

Mob programming, in which the team works on one thing at a time, might be able to bust Brooks’s Law. In an ideal 3-4 person mob, each person has learned (though maybe not remembered) virtually everything pertinent about the project as it progresses, by virtue of the short rotations and strong-style navigation that mob programming requires.

Someone joining the mob late in the project almost immediately brings value, by providing expertise and a third-party perspective that the team likely needs. Short rotations and strong-style navigation, bolstered by everyone’s extensive knowledge of what’s going on, help rapidly ramp up the new team member. They can thus begin to feed back team useful recommendations almost immediately to the team.

While it may not speed up delivery for all initiatives, a late addition to a mob programming team is highly unlikely to make it later by slowing the team down. Brooks law: possibly broken. Minimally, this means we are no longer bound by the project calendar in terms of when we can onboard new folks who bring value that we need. (And given the challenge in finding quality developers nowadays, this is a significant win.)

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.