Tangled Webs

    Law, Sausage & Software
Issue 4.8
May 28, 1999



The Refuge of Derelicts


If Mark Twain were writing today, his list of things one should never see being made would undoubtedly be law, sausage and software. The process by which most software is produced is pathetic, and what's still more ridiculous is that in many cases the people involved in the process are unaware of the absurdity.

The most famous book ever written on software development is unquestionably Frederick Brooks' The Mythical Man Month. It was originally published in 1975 and is based on the author's experience in software development in the sixties. However, it remains every bit as relevant at the turn of the millennium, and thanks to an exceptionally well chosen title, it has taken on symbolic meaning that extends far beyond the ideas expressed in the book itself.

The man-month is an imaginary unit of productivity believed to correspond to the amount of work the average software programmer can do in a month. The vast majority of outsourced software development projects seem to be contracted and scheduled using this metric. Unfortunately, the futility of scheduling software development projects using man-months has been well documented since the late sixties.



Fools & Damn Fools


Studies done over the past 30 years by TRW, NASA, IBM and many other organizations have consistently found that even among experienced, professional programmers, the difference in individual productivity is over 2,500%. They also show that experience has little to do with productivity. Even when programmers are compared to others having the same length and type of experience, the difference in productivity is still an order of magnitude. A given programmer may be over ten times as productive as another with an identical resume.

It's important to keep in mind that these studies are not comparing a few programming superstars to trainees. They examine a cross-section of professional programmers, and they all confirm the same truth about software development. When the time spent on communication and administrative tasks is factored in, we see that a single top-notch programmer can produce the same amount of work as around 30 mediocre programmers over the same period.

Are you beginning to see the absurdity of trying to define a man-month, let alone schedule by it?

To be fair, these same studies show that for large projects -- those involving dozens or hundreds of programmers working for 12 months or more -- administrative tasks consume a larger proportion of the project, individual differences between programmers tend to cancel out, and the man-month becomes a practical way to plan. Likewise, these studies all deal with software development. There is far less variation in activities such as testing.



A Letter from Earth


So what does all this mean to you, a businessperson thinking of contracting the development of custom software? Well, most important, you have to realize that people who say things like "That's a six and a half man month project." or "Going with a three-tier solution will add another man-month to the project" are talking through their hats. Unless the programming team has been selected, the schedule set, and the technical lead consulted on the matter, such statements are meaningless.

The biggest favor you can do yourself is to simply ignore all talk of man-months. Some simple preliminary analysis will determine the approximate cost of the project. If the price range is acceptable to you, insist upon -- and be willing to pay for -- the compilation of a detailed functional specification of the software to be built. Once that is done, then a final price and delivery schedule can be agreed upon.

From that point on, focus only on functional requirements not the resources the contractor is using to meet them. Whether the software is developed by a team of 20 programmers or created by voodoo incantation really doesn't matter. The developer is responsible for allocation of resources. You are purchasing the end product.

With this in mind, you should also require that all bugs found within a reasonable time frame, say one year, be fixed promptly and without charge. Most development companies are happy to provide such guarantees, but those who balk should be treated with the same mistrust applied to any manufacturer who refuses to warranty their products.

Focusing solely on the end product is the best way to get value for your money, but many clients feel that having five programmers working on their project for three months demonstrates that they are getting their money's worth. However, 30 years of productivity figures show that this is simply not the case. In fact, man-month scheduling usually becomes a self-fulfilling prophecy.

When a contractor tells you that a certain job is a "ten-man-month project," it means the company will assign three engineers full time and a fourth part-time. You will get whatever they have developed after three months. This is wonderful for the contractor. For unless he grossly misestimates, it ensures the profitability of the project. From the buyer's side, however, the situation is less than ideal.

"Now wait a minute", I hear you say. "I know of quite a few small projects that were scheduled using man-months and they went just fine." True enough. Most contract projects are still scheduled in man-months, and a lot of perfectly acceptable software has been built and delivered in this manner. Then again, a lot of law and sausage has been made over the years as well. In all cases, there is room for substantial improvement.


[ Home Page] [ Back to Index ] [ Previous Issue ] [ Next Issue ]

© Copyright 1999, Tim Romero, t3@vanguardjp.com
This article fist appeared in the May 1999 edition of Computing Japan.
Tangled Webs may be distributed freely provided this copyright notice is included.
The Tangled Webs Archive is located at http://www.vanguardjp.com/t3/tangledwebs/index.shtml