For God’s Sake, Forget Brooks’ Law and Staff More People!!!
In 1975, Frederick P. Brooks wrote one of the most influential books in the software engineering field, The Mythical Man-month. Within this book, the essay with the same name, The Mythical Man-month, is cited the most by many software managers, but unfortunately, it is much less often read or understood. Basically, the most significant proposition of the essay (known as Brooks’ Law) is
Adding manpower to a late software project makes it later
Brooks based his law on the following observations
- Because many software development tasks (such as debugging) are inherently not partitionable, more people assigned into a certain indivisible task does not make the work done faster (as a woman can give birth in 9 months, 9 women cannot give birth in 1 month)
- As software construction is complex, a lot of training is necessary for new members before they can be really productive with their assigned tasks
- As the number of team members increase, the overhead of communication increases exponentially (i.e. n(n-1)/2 communication lines with n is the total number of team members)
In other words, staffing more people in a project demands more training time, communication overhead, and proper work distribution (not always possible if the total number of atomic subtasks are less than the total number of team members), and thus, might well make a late project later.
While these are perfectly valid observations, it is easier to be applied incorrectly than correctly. Let’s look at the example below (note that I have simplified the example by assuming many fixed parameters, however, certain adjustments to these parameters will not result in a different conclusion)
A two-people project is supposed to be finished in 5 months (and thus 20% of the total work is to be done each month). At the end of the first month, only 10%, instead of 20%, gets done. Knowing this fact, the project manager has two choices:
- Practicing Brooks’ Law and avoid adding new programmers to the team. As correct as it often is, the “yesterday weather” theory of the XP community turns out to be true: the team continues to produce 10% each month and that makes the project finish in 10 months, which is a schedule overrun of 100%
- Ignore Brooks’ Law, adding a talented programmer to the team, setting clear goals and expectations to all members, assigning tasks, including mentoring and training, properly. In the second month, due to training and catch-up efforts, the team can only produce 5%. In subsequent months, as the new-hire gets up to speed, the team can produce 15% per month. That makes the project finish in about 7.5 months
In other words, although the project is later than the original plan of 5 months, it is still better than if no new member is added, which will require 10 months to complete.
Does the example above implies that Brooks’ law has a flaw? Not really! The key thing here is to consider the following factors
- When project is really late. In the above example, some managers will immediately conclude that the project is late (because 20% should have been done in the first month, instead of 10%) while in fact it is not. It is NOT late if you can only finish 10% of the work when, say, 20% or 30% is expected, since there is still a lot of time for the team to make proper adjustments to complete the remaining 90%. However, depending on the particular project, it can be too late if you have finished 90% of the work and want to shorten the schedule - Brooks’ Law might cast in by that point
- Who you staff into the team. No matter how many members you staff into your team, if they are all mediocre programmers, your project will be yet another loser. Period. Hiring talented programmers will reduce training time significantly since they know how to do their job well. Hiring those with good teamworking attitude may reduce communication overhead while boosting up the productivity of the whole team
- How the team composition can be optimized. Even if the total number of atomic subtasks is less than the total number of team members (which is rare given the size and complexity of most software we are developing today and may only be true at the very last moment of the project), if the team is well organized and tasks are well assigned, then there would be little wasted effort and communication overhead
During the early days of my career, I had been in a late project in which we produced much less than expected during our first three milestones, but the project turned out to be a success because the manager simply did not care about Brooks’ Law and was able to staff into the team a talented senior developer, who helped refactor the whole codebase to make it more maintainable as well as coached many team members, including me, to make them more productive. The project would not have been successful if Brooks’ Law was applied. Unfortunately, I know many managers who avoid adding new members just because they think their project is late (funny, this is usually the exact same reason why they think of the idea of adding more people in the first place) and blindly follows Brooks’ Law, thinking that they are the best managers ever. Some even quote the “giving birth” example as an argument for not adding people, regardless of the fact that their team members are burdened with a lot of work and stressed out due to constant overtime. To these managers, my advice is:
For God’s sake, forget Brooks’ Law and staff more people!!!
Sometimes, doing the opposite of something is the most effective way to learn deeply about it…
During 1 month of work, both programmers should have a better understanding of why they are late.
Will this project require twice the work they thought it would?
I have seen many environments where projects are “consistently late” but developers give good estimates to begin with, however management says “10 months is too long - cut corners and do it in 5 months” and then is surprised when the project takes 12 month, the last 6 spent fixing “cut corners”.
Did the team waste 2 weeks troubleshooting an install (Reporting services and TFS come to mind)? This problem is unlikely to be repeated.
What this comes down to is either the team is working slower than expected, or there is more work than expected. If there is more work than expected, you need to adaquately staff for it, or at least know you are working with less resources than what you should have. In that case, adding staff will help if that is an option.
If work is going slower than expected, you need to find out why. Consider buying better tools, better equipment (monitors and RAM come to mind), providing better insentives. If your expectations are reasonable, and there are no obvious problems, you may be better replacing a programmer than adding one.
Yes Brooks’ Law is beatable, but I doubt it’s doable by anyone.
Does the first month being late automatically means the rest of the month will also be late? This depends on who you have, how much knowledge they already have accumulated, etc. I don’t think that automatically translate into the first choice.
Also, few people will claim the project is late right after first month. In my experience, many project team will not say they are late until it is too late to save the project.
Adding people in the “late” juncture is one of the most obvious solutions that managers choose, because unlike construction projects, many software tasks are not fully partitionable. Brooks’ Law is meant to educate managers on using more people wisely. Your past managers seem to heed the warnings, which is a good thing.
And I’ve seen project managers who do not know who Brooks is, let alone understanding the meaning behind Brooks’ law (i.e. understand software practices) - their chances of beating the law is next to nil.
But again, this all depends on people, as you said.
@Brad:
Thanks a lot for your comments.
This occurs when people got confused between “target” and “estimation” (the terms Steve McConnell used in his book, Software Estimation: Demystifying the Black Art): some folks set out target, forcing the members to follow regardless of the result of effort estimation, and then later get angry when the goals cannot be achieved.
Your opinion about the need to separate the between situations in which there are more work than expected and in which the team underperform in order to have appropriate actions is great and I totally agree with it!!!
@Yin-So:
Thanks a lot for your comments.
No, it does not. The team would likely be more productive in later months then the first months. But as I said, I tried to make the example simple with many fixed parameters. However, when you add the knowledge accummulation factor to the progress of both options, #2 would still deliver faster than #1.
I can understand that. However, in some projects I’ve been working on, we perform estimation and planning for all iterations of the whole project, each with clear-cut deliverables and assumptions. If the goals of an iteration cannot be met, it is considered “late” and the team must adjust the project plan accordingly (e.g. extend schedule, staff more people etc.) and provide all kinds of explanation to the boss and the client. (And yes, I know this sound like a bad development process since we plan so many things up-front, we cannot escape from it since the projects are fixed-fee and both my boss and the client need to know the dates and they are very unhappy when we miss any dates.)
One particular project that I know was supposed to be done by 3 people within 5 months, after that 5 months, only 60% of the work was done and it was rescheduled to the next year - when being asked about the option adding more people to make the project finish sooner, the product manager said “No, we are already late, and it’s not good to add more people when we are late. Don’t you know Brooks’ Law?”. This story is one of the “inspiration” for me to write this post
So true! In addition, for some others (like the product manager I mentioned above), I just wish they never know about Brooks at all
Brooks’ Law is mostly applicable near the end of the project. When there is one month to go and the project is late, then it is a bad time to add more people.
If you can find out after the first month itself that you are running late, then thats the perfect time to add more people, because the new team members do not have to spend much time catching up with the existing team members.
A related article ‘Exceptions to Brooks’ Law’:
http://www.scottberkun.com/blog/?p=195
Interesting points.
I interpret Brooks’ Law to be more about avoidance of additional communications overhead during a time crunch to mitigate risk of additional lateness. To quote myself from a while back..
Applied to a team communications system of N people, the worst-case number of total communications channels is when everybody talks to everybody else. This can be expressed by N(N-1)/2. In other words, a given person in the team (the Nth person) is communicating with everyone else (N-1 people).
A problem with large horizontal teams is that as N increases, the communications overhead of being able to operate potentially increases exponentially. As a member of a 5 person team, for example, communicating with 4 others is not a big deal. You are able to mentally understand what other people are doing and how others communicate with each other (in all 10 different relationships). If this team grows to 15 people, however, communicating is not as simple. In the worst case, not only do you have to communicate with 14 other peers, there are now 105 relationships between people you may have to be aware of to stay “in the loopâ€. The worst part may be that the majority of the information going across those channels may be directly irrelevant to you job, but since it’s relevant to the team as a whole, you spend the time and mental cycles to process it.
Now, this is all worst-case abstract theory, but it does highlight the scaling problems of communication in teams of changing size. As your team changes, you need to reevaluate the way it works to keep operating overhead due to excess or insufficient communication down to a minimum.
@Siddharta: even if there is supposed to be only one month left, if we have, say, 50% work left to be done, then should it be considered late? I would say it should not and one can still staff more people to have the remaining 50% done faster.
Thanks for the link, Scott Berkun offers really good points in his post.
@Preston: you made a great point. n(n-1) is the number of possible communication channels, it’s the manager’s job to minimize the communication overhead and reduce unnecessary channels while being able to maintain the effectiveness of the information flow in the project.