The Mythical Man Month

One of the seminal works in the software world is The Mythical Man Month, written by Fred Brooks in 1975. Selected here for your review is chapter two from the book, also titled "The Mythical Man Month".

I suspect many of you have heard of this particular work, which discusses the difficulties in scheduling software projects. Brooks highlights some of the problems that cause inaccurate estimates, such as optimistic programmers (see: Murphy's Law). Brooks also tackles the false idea that adding more people to a project will allow it to finish ahead of schedule.

Understanding the flaws in our typical scheduling approach will help you provide better estimates to your management and your customers.

Read Chapter 2 of the Mythical Man Month here.

My Highlights

Brooks's intro to the paper provides a very nice overview of the difficulties around scheduling software projects:

More software projects have gone awry for lack of calendar time than for all other causes combined. Why is this cause of disaster so common?

  • First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well.
  • Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
  • Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef.
  • Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
  • Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.

Aside from being overly optimistic, many times we don't realize problems or missing details in our designs until we actually try to implement them:

Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. [...] For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician.

And we forget the scale of our product when assuming everything will go as expected:

In a single task, the assumption that all will go well has a probabilistic effect on the schedule. It might indeed go as planned, for there is a probability distribution for the delay that will be encountered, and "no delay" has a finite probability. A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.

There are many situation in which adding extra developers won't help:

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule (Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

Don't forget about communication overhead:

In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer than an even trade of men for months

The added burden of communication is made up of two parts, training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.

Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task and bring us to the situation of Fig. 2.4.

Brooks shares his scheduling rules of thumb:

For some years I have been successfully using the following rule of thumb for scheduling a software task:
l/3 planning
l/6 coding
l/4 component test and early system test
l/4 system test, all components in hand

When rescheduling a project due to a delay, avoid small slips:

I like the advice given by P. Fagg, an experienced hardware engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.

In summary:

One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined.