The Mythical Man-Month

The Mythical Man-Month

This week we will break the rule of covering two essays per week (maybe it was a poor plan) and re-read the essay The Mythical Man-Month. The Mythical Man-Month is the essay that provides the book with its title, and more importantly establishes Brooks Law (we will explore this law in a few paragraphs). In my opinion, if Fred Brooks stopped with this essay his ideas would still would have shaped how work is (or at least should be) approached in IT organizations. The ideas in this essay are easy to trace in contemporary project management and in its influence in lean and Agile principles.

In the essay, The Mythical Man-Month, Brooks begins by postulating that much of the problems experienced in large software-centric projects are caused by a lack of calendar time. When calendar time is constrained, leaders and teams often make a number of mistakes. Those mistakes include compressing testing, not planning for things to go awry or adding people or teams to a project in an often vain attempt to make a date. Often these techniques generate the opposite impact, they make the project later or reduce quality. In the essay, Brooks identifies problems that the lack of calendar time can generate in projects. He explores four of those five in detail (progress tracking he tackled in a later essay). The four addressed in this essay are:

  1. Optimism generates behavior that reduces the effectiveness of estimation (this is true for all types of estimates). One of the core assumptions that optimism generates is that everything will go well. In my interview on the Software Process and Measurement Cast 84, Dr. Ricardo Valardi indicated that his research strongly supports this thesis. Software developers are trained problem solvers that haven’t met a problem they can’t surmount, therefore they fail to anticipate that problems will occur. And when problems do occur they will require more effort than planned.
    Brooks points out that software development bears similarities to other creative endeavors. The developer conceives of the solution to any tasks in a perfect state. As the task is implemented all of the constraints that did not exist in the perfect state come home to roost, thereby slowing progress. When the solution is exposed to interaction with others (such as stakeholders) even more flaws are exposed, requiring additional effort and calendar time to correct. Even from this small piece of the larger essay we can see the rationale for many of the principles in the Agile Manifesto. For example, the principle calling for teams to work with business on a day-to-day basis is a direct reflection of the need to move interaction from the end of the process to the beginning.
    Brooks completes his discussion of the impact of optimism by pointing out that while the probability of a problem with any individual task might be low, large projects are composed of many tasks that happen one after each other. Therefore the overall probability of a problem is always significant.
  2. Effort is often confused with progress, which stems from using a man-month as a unit of project size (it is amusing to reflect on how archaic the term man-month has become in 2015). Even today I am often ask how large a project is only to be told how many hours or sprints are estimated. Conflating effort and size leads to the assumption that people and time are interchangeable. While this might be true for independent tasks that don’t require interaction with others, like mowing the lawn, it is untrue for creative tasks that require interaction between people or teams. It is also untrue for projects or tasks that can’t be pulled apart and done in parallel. Brooks uses the now classic analogy that nine women can’t have a baby in a month to drive home the point.
    All projects have a proper staffing level above which the project will take longer and below which adding people will increase throughput (remember the concept of bottlenecks from the re-read of The Goal). Staffing equilibrium is recognized in Agile and is reflected in the size of Scrum teams (5 -9 people) and Dunbar’s number for projects or programs. The staffing equilibrium is influenced by a wide range of factors that Brooks didn’t explore; we will discuss this in a future essay. Brooks’ rationale for why more people will require more time is relatively straight-forward. More people require more overhead, more communication and interaction to get work done. Unstated but inferred is that if you think you staffed the work correctly to begin with then adding extra people is a bad idea.
  3. Gutless estimating leads teams and projects to deliver before they are ready. Brooks suggests that because we are uncertain about any estimate we are often affected by the urgency of others. The lack of a track record using measured and demonstrable factors such as velocity, productivity, functional size or even technical makes it is difficult to defend any estimate without reverting to pure opinion. Acceding to the urgency of others or any other factor that demands the completion of work before it is ready will have negative consequences. Those consequences are often identified as technical debt that reduces that value of the functionality delivered by the software .
  4. When schedule slippage is recognized the natural tendency of most managers is to add people in order to attempt to recover. This almost always makes things worse. This observation lead to Brooks’ Law. Brooks’ Law states that adding manpower to a late project only makes it later. For some reason EVERYONE admits to understanding Brooks’ Law, however very few seem to be able to live within the Law’s constraints. Adding people to any project requires re-planning, training, coordination and more testing (more integration testing if nothing else), which means that any possible gain is usually lost. This often induces the impression that even more people are needed to get back on track. Brooks called this a regenerative cycle, adding people seems to generate the need to add even more people. The argument that is often made is that automation and newer tools have invalidated Brooks law. The argument misses the point, every added person is an additional communication and integration node in a network that needs to work together to deliver software. More nodes require more human communication, which tools and other automation might help, but they don’t replace human interaction. The slope of impact might (and I underscore might) be less steep, but it has not been erased. If you doubt the veracity of the comment, go find a late project and offer people directly involved with the work to inject new people into the mix and see what the reaction is.

The messages in the essay are timeless and have influenced nearly every theorist, methodologist or coach whether they are working with classic, lean or Agile techniques. Now we have to work on getting all practitioners to follow through on using the ideas on projects rather than assuming what didn’t work before will somehow work this time.