![]() |
|
So what is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?"
Alas, time cannot be warped so easily. Dr. Brooks observed, while he was managing the development of Operating System/360 (OS/360) in the early 1960's, that man-months are not -- so to speak -- factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.
When you stop to think about it, this phenomenon is easy to understand. There is an inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be dedicated to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there will be at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger.
"The Mythical Man-Month" is, of course, about substantially more than, well, man-months. Many other concepts and chapter titles found in the book have also made their way into computing jargon and folklore, such as "the second-system effect" and "ten pounds in a five-pound sack" and "plan to throw one away." Brooks also addresses design issues, interfaces, specifications, tool-building, and debugging techniques. He was an early proponent of cross-compiling and simulation (when the OS/360 project started, there were as yet no fully-functional implementations of the hardware).
Interestingly (and I suspect characteristically), Brooks did not exploit 20 years of hindsight to revamp the body of "The Mythical Man-Month" for the Anniversary Edition reviewed here. He chose, instead, to let the original text stand on its own merits and to add four chapters containing his influential 1986 essay "No Silver Bullet," a summary of the debate over the latter essay by other computer scientists and Deep Thinkers, his own annotations of the chapters in the first edition of "The Mythical Man-Month," and some general musings on the evolution of computer science and programming.
I first stumbled across "The Mythical Man-Month" shortly after it was released in 1975. At that time, I was your prototypical self-taught code mangler, working in almost complete isolation from other programmers, learning everything the hard way, reinventing wheels by the dozen, and with minimal exposure to the computing literature. Although I recognized Brooks's work as both important and very well written, I was too naive to fully appreciate its significance. Revisiting the book twenty years later, having in the meantime plowed through some hundreds of other computer books and spent a fair amount of time writing and editing computer books myself, I find myself somewhat in awe of "The Mythical Man-Month."
Although there are definitely passages that feel dated (such as Brook's recommendations from the 1960's for a "surgical" team structure), very few computing books have stood the test of time as well as this one. The book is beautifully written, edited, typeset, and illustrated. It has few peers in the elegance of its presentation and its insights into the human side of software development. And although Brooks comes across as a direct and rather unpretentious fellow, I can imagine that he must have been inspiring and challenging to work for -- his powers of observation, willingness to learn from mistakes, and ability to see through to the deeper issues are remarkable.
-- Ray Duncan
| Preface to the 20th Anniversary Edition | |
| Preface to the First Edition | |
| Chapter 1 | The Tar Pit |
| Chapter 2 | The Mythical Man Month |
| Chapter 3 | The Surgical Team |
| Chapter 4 | Aristocracy, Democracy, and System Design |
| Chapter 5 | The Second System Effect |
| Chapter 6 | Passing the Word |
| Chapter 7 | Why Did the Tower of Babel Fail? |
| Chapter 8 | Calling the Shot |
| Chapter 9 | Ten Pounds in a Five-Pound Sack |
| Chapter 10 | The Documentary Hypothesis |
| Chapter 11 | Plan to Throw One Away |
| Chapter 12 | Sharp Tools |
| Chapter 13 | The Whole and the Parts |
| Chapter 14 | Hatching a Catastrophe |
| Chapter 15 | The Other Face |
| Chapter 16 | No Silver Bullet -- Essence and Accident |
| Chapter 17 | "No Silver Bullet" Refired |
| Chapter 18 | Propositions of The Mythical Man-Month: True or False |
| Chapter 19 | The Mythical Man-Month after 20 Years |
| Epilogue |
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctiveness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this tractability has its own problems.)
Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
From The Mythical Man-Month, Anniversary Edition, pages 7-8.
| Readability | |
| Originality | |
| Organization | |
| Accuracy | |
| Consistency | |
| Depth | |
| Timeliness | |
| Editing | |
| Design | |
| Overall Value |
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.
Brooks, Frederick P.: "The Computer Scientist as Toolsmith II," Communications of the ACM, 39(3):61, March, 1996.