Programming – Brook’s Law

It happened again; that moment when your sprint is behind and then you’re asked if adding more developers would help complete tasks faster than doing it with your current group. My answer would usually consist of me rambling and trying to use various metaphors to convey that adding more people won’t help. While I know there are times when adding more people would be beneficial, but most times, it causes more chaos and adds extra development time. However, I’ve finally found a principle that explains exactly what I mean – Brook’s Law.

According to techopedia, Brook’s Law is a software development principle coined by Fred Brooks in The Mythical Man-Month which states “Adding manpower to a late software project makes it later.”. The metaphor that is often used in tandem with this is “…while it takes 1 woman 9 months to make one baby, 9 women can’t make a baby in 1 month”. Basically, adding more people won’t help.

From my personal experiences, this scenario happens a lot. From an outside perspective, it may seem intuitive to decrease development time by splitting tasks, however there are variables that work against this. Here are a few examples:

Lack of Organization

When adding more people to the team, I often find assumptions are overlooked. For example, when people assume that the new devs know what they need to know or when people assume tasks are already divvied up, nothing works according to plan. Then, at the end of an agile sprint, people are left wondering why nothing actually happened. The answer is simple, there is a need to take some time and reorganize what is going on because of the new variables that were added and the new path we want to take. However, by taking this time to reorganize, it also takes time away from what could be utilized for coding.

Disruption of Flow

This mostly a pet-peeve thing for me, but 9 out of 10 times, I am (or my current team is) already in the flow of development; meaning I’m in the “zone” and getting things done. Having to stop disrupts the mind and it’s hard to get back into that “zen-mode“. For me, it is synonymous to Newton’s first law of motion – “An object at rests stays at rest and an object in motion stays in motion with the same speed and in the same direction unless acted upon by an unbalanced force.” Having to stop to reorganize, worry, and having to do some form of knowledge share this late in the game is the unbalanced force that throws me off my game.

Worries

Okay – another pet-peeve of mine. When I already have a grasp on what tasks need to be completed, how they should be done, and who will do them – I worry a lot when things alter that knowledge/process; it’s like I have no idea what is going on anymore. I understand requirements and task priorities constantly change, but if I am worrying if our next build is going to deploy, that affects my bandwidth and concentration.

Knowledge Transfer

This is probably one of the biggest time consumers when we’re late in the game and adding people. If we’re already lacking organization, feeling the pressure of time, and having to explain everything from the origin of the project, that equals a lot of time. Don’t get me wrong, I absolutely love helping and teaching others, but there is a time and place for that. If we’re getting pressured to complete tasks by EOD, do you really think there’s enough time for a lesson in Project X 101?

So, what I’ve found from writing this blog is that I have some weaknesses that I need to work on, lol. However, if you are stuck in the same boat as me when trying to explain why we should just stay how we’re doing things because adding more people may “muck” up the process, just mention Brook’s Law. If you happen to be managing a team and someone mentioned this to you, just chill out and believe in your current squad, they got it.

Happy coding!