Mythical Man-Month


Article/ Review

The Mythical Man-Month
20th Anniversary Edition
by Frederick P. Brooks
1995 Addison Wesley


The Mythical Man-Month's central theme is that conceptual integrity is critical to any software development project.

"Those who do not remember the past are condemned to repeat it."
-George Santayana

"The Bourbon kings remembered everything, but learnt nothing."
-Charles Maurice De Talleyrand-Périgord

1965 was the Dark Ages before the World Wide Web and personal computers. Computing was done by high priests hidden in an air-conditioned Holy of Holies. What possibly could Frederick Brooks' classic programming text, The Mythical Man Month, about that era of software development, tell us about software developed today?

Brooks wrote his book to help developers understand why software was late, over budget, and took several revisions to get right. He talks about the difficulty in managing complex projects and offers advice on how to navigate the inevitable difficulties. He was the first to point out many of the key concepts in software development; ideas that are taken for granted by experienced software developers.

Why is this book, despite its age, still relevant? In 1965, software was late, over budget, and took several revisions to get right. When I first read the book about 17 years ago, software was late, over budget, and took several revisions to get right. Today, software is still late, still over budget, and still takes several revisions to get right.

I have been a software developer for 19 years; for the past 12 years I have had my own software consulting firm. I can tell you that the problems and principles that Brooks talks about in his book are still being ignored by many corporate and business environments. And you can see the poor results. The sad part is that the ideas Brooks talks about are simple, and he writes about them in a very clear and concise fashion. I am tempted to say, "Even a manager could understand them."

The Mythical Man-Month's central theme is that conceptual integrity is critical to any software development project. Most of the advances in software engineering technology have made the implementation easier. The real difficulty is developing and maintaining the unifying concepts during the initial development and subsequent revisions.
 

One "wrong", consistent design is almost always better than a compromise between two excellent designs where the final product does not hang together.
I have rarely seen a project fail simply because the technology was not ready. COM, CORBA, Java, and the Internet are wonderful technologies. They will help you bring greater value to your clients. They are not going to solve the fundamental problem of transforming concepts into something useful. Better tools help, but the real trick is to design the program right in the first place.
  Here are some of the highlights:
1.Based on Brook's classic advice I can almost always predict which software projects will succeed. And you can as well.
• One "wrong ", consistent design is almost always better than a compromise between two excellent designs where the final product does not hang together.
• With no design, each group will go off with its own design and you will produce a balkanized product.
• In either case, without a consistent design, performance improvements and new functionality cannot be easily made, except by being late, over budget, and taking several revisions.
• Many years ago I participated in a programming project that ignored this principal. Design did not follow any single conceptual plan, rather it followed the corporate structure. The application groups designed the applications, the graphics groups designed the graphics, the database group the database, and the user interface groups the user interface. Nobody really addressed putting the pieces together. The program never worked well, it was difficult to debug, bug fixes and performance improvements were difficult to make. Today with the growth of middleware components and mutli-tier architectures this issue has become very critical.

2.The Mythical Man-Month was the first to point out the vast difference in ability among programmers. Many managers tend to be penny wise and pound foolish and try to replace "expensive" programmers with cheaper ones. Never mind the productivity ratio is far greater than the salary ratio between the two. Seeing this replays in my mind the Rocky and Bullwinkle commercial: "Hey Rocky watch me pull a rabbit out of my hat! But Bullwinkle that trick never works!" And no matter how different ways Bullwinkle tries it - it never works.

3.Brooks also formulated some of the classic proverbs of the programming industry. There is Brooks' Law that "Adding manpower to a late software project makes it later". The time that the new people would save is more than taken up by the original team explaining to them what is going on and repartition the work among the new people. This is the mythical man month in the title. Another famous proverb talks about the fact that some tasks cannot be done in parallel no matter how much a manager wishes. "The bearing of a child takes nine months, no matter how many women are assigned." Or "How does a project get to be a year late?...One day at a time."
 

I have rarely seen a project fail simply because the technology was not ready. COM, CORBA, Java, and the Internet are wonderful technologies. They will help you bring greater value to your clients. They are not going to solve the fundamental problem of transforming concepts into something useful. Better tools help, but the real trick is to design the program right in the first place.

In our kinder, gentler era we will not meet the fate of one Bourbon king who lost his head when he was fired. Nonetheless, let us try, for once, to learn from our past mistakes.

-Michael Stiefel
 

All Content (c) 2000 - 2014 Reliable Software, Inc. All rights reserved.