The Mythical Man-Month Revisited

The Mythical Man-Month

Jan 11, 2012
By Dave Edstrom
NOTE: This is an article I wrote for the January 2012 IMTS Insider.

In all industries there are seminal books that are in the must-read category as someone is learning their trade. In manufacturing, one of these must-read books is The Goal by Eliyahu M. Goldblatt and Jeff Cox.

In the computer industry, there are numerous must-read books and certainly Frederick P. Brooks The Mythical Man-Month, written in 1975, is in that category.

Personally, I prefer the updated version of Brooks’ book as it sheds more light on the topics and he updates his thoughts toward the end of the updated version. My favorite computer book that deals with the challenges of getting a product out the door is the Pulitzer Prize winning book by Tracy Kidder called The Soul of a New Machine.

The lessons from Brooks’ The Mythical Man-Month can also be applied to manufacturing. This is especially true as software becomes more important in manufacturing each and every day. I’d like to discuss “Brooks’ Law,” which is the focus of his book, but the point he brings out is implicit in the other two books as well.

When management makes the decision to throw more people at a software project that is running late, they do so under the firm belief that adding more people is the right and obvious decision to make at that point. The problem is that it is usually the wrong decision. “Brooks’ Law” states “adding manpower to a late software project makes it later.” At first glance, this may seem counterintuitive. The reasons Brooks’ Law is usually right are multiple. I use the term “usually” here because there are exceptions to Brooks' Law. The reasons Brooks’ Law usually holds up are when you bring new software developers onto a project, there are a number of tasks that simply must be done. These include:

• Bringing new developers up to speed on the project. This typically involves current software developers and project leads investing time with these new developers.
• There might be training for the new developers because the software tools or practices the project is utilizing are different than what they have previously worked on.
• The remaining work must be prioritized so the experienced developers are taking on the most difficult parts of the project.
• There is also dividing the work among the existing and new software developers — often a daunting task.  
• This partitioning of work can be extremely difficult if the initial architecture was not cleanly laid out separating out interfaces from implementations.  

What I mean by an “interface” is how one communicates with a piece of software. This is typically at a high level. For example, let’s say I want to verify that when a prototype part is being created on a specific machine tool, it is being created by one of our very best machinists. I also want to make sure that these machinists are using a cutting tool that meets certain quality requirements my company has determined will be used by for all prototype parts. What is the software interface that I program my client application to in order to make this happen?  Side note - this is where an open and royalty-free protocol such as MTConnect^® provides simple interfaces to get information.

The “implementation” is the low-level set of specifics on what happens when that above request is serviced.

Here’s another way to think about the interface and implementation definition in layman’s terms. The interface for me to get the yard mowed on a Saturday is to yell at one of my three sons, “Get the yard mowed tonight before it gets dark.” If I do not hear anything from them in 14.896 femtoseconds, I then yell, “Are we clear?” If I hear a positive response, then I consider the task done.

The implementation is my son going out to the shed, checking gas in the John Deere tractor and the Honda push mower, then deciding whether they want to mow the front or back yard first and finally getting the yard mowed. I don’t care HOW they mow the yard; just get the yard mowed before it gets dark. If time was tight, I could ask John to mow the back, Michael to mow the front and have Tim trim. However, if I needed my ½ acre mowed in less than three minutes, the partitioning and coordination to make this happen would be an interesting exercise. This partitioning can be easy to do when it comes to a simple task such as mowing the yard when you can simply yell at one of your sons to get it done, but it is very hard for a software project that could require hundreds of thousands of lines (or more) of code to be written.

It also can be a challenge integrating the new software developers into the existing communication framework.  

Brooks also states in his book, “the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth – it implies that men and months are interchangeable.” It is well known that your gifted software developers can literally be 10x as productive as other software developers. This makes the dividing up of work even trickier.

A humorous statement that Brooks would make to drive home this point is, “The bearing of a child takes 9 months, no matter how many women are assigned.” This does drive home the point that some things just take time to make and software is certainly in that category.

Have things changed since 1975 with software development? Absolutely. It used to be that everyone thought software should be developed like a boat going down a gentle waterfall. In other words, one went from planning to coding to component test to system test and finally to deployment in a nice logical fashion. Today all the realists know that software development needs to be agile, lean, a clear partitioning of tasks and most importantly, interactive with the end customers. The type of computer languages have also changed a great deal, enabling more partitioning of tasks. When you think about the time frame of 1975 and computing, it is pretty remarkable to realize that even 37 years later, Brooks’ Law is still true many more times than it is false.