The Mythical Man-Month Is Not A Myth

Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”.  It was coined by Fred Brooks in his well renowed 1975 book The Mythical Man-Month.

There was a recent project where unrealistic timelines were imposed on a team and the project was running late largely due to the Cone of Uncertainty – commitments were made early when least was known.  The team estimated the project would complete in 12 months. However, the project needed to be complete much earlier than that.  As a result, the project showed all the symptoms of a “death march” from day one – desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends (and public holidays), often causing burnout and by attempting to throw (enough) bodies at the problem with indifferent results.   Interestingly, the project was still delivered in 12 months despite all the overtime and adding more resources.

As an observer from the outside, it amazes me how many people overlook the negative productivity impact of actually adding more resources.  On face value, we seem to think if we double the team size it will simply mean we would double the workload of the team.

In reality, it takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time.  Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them.  This education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully.  Each new worker also needs to integrate with a team composed of multiple engineers who must educate the new worker in their area of expertise in the code base, day by day.

In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even have negative contributions – for example, if they introduce bugs that move the project further from completion.

Communication overheads increase as the number of people increases.  The number of different communication channels increases along with the square of the number of people; doubling the number of people results in four times as many different conversations. Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.

To reduce cost on the project, a significant number of resources were obtained from an offshore location which made things more complicated and accentuated the above issues. Due to reduced communication bandwidth, collaboration was even lower with the offshore team.

A senior external  consultant was bought in to help the team with some new technology.  He commended  the (original) team about the high quality code which enabled him to do his work effectively and to extend and maintain the code with low cost.  However, all the hard work the team originally put in that resulted in high quality and clean code were being lost with the addition of the new resources.  The need for new resources to be coding from day one resulted in poor quality output.  Not only did this result in increased defects, but also increased integration issues.

In my blog Don’t rely on overtime to salvage a plan last month I wrote about avoiding daily or frequent overtime as it affects efficiency, productivity, morale and quality.  Asking the team for mandatory overtime is a symptom of a serious problem on a project and does not address the root cause.  Don’t get me wrong, you can work some short and specific overtime and this can often help get the project out of a tight spot. However, if you come into work frequently and say –

“To meet our goals, we’ll have to work late again”, then you already have a problem that can’t be solved by working more hours”. (Beck, 2004)

So with constantly increasing scope but with a unrealistic fixed schedule, quality was being impacted.  Corners that were cut due to unrealistic pressures imposed on the team and excessive overtime came back to haunt the team later.  They were finding or making more bugs than before resulting in more delays and greater integration issues due to poor quality of work being provided by the offshore team.

Overtime just doesn’t yield the results promised by Gannt Charts which provide an oversimplified view of the software development process by only measuring the quantity of the hours spent on tasks without also taking into consideration the quality of the time (yes there is a difference).

Sometimes the biggest gains in productivity come from stopping to think about what you’re doing, why you’re doing it, and whether it’s a good idea. We need to work smarter, not harder and have the ability to hear unwelcome news and then address the real issues.

When trying to add new team members to address a tactical and fire-fighting need, we need to realize that an incremental person who, when added to a project makes it take more, not less time – nine women cannot make a baby in one month.