The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Say "The Mythical Man-Month" to any software engineer or project manager and you will get immediate recognition. The concept of this title essay is that, because of communication and other overhead, adding additional engineers to a late software project makes the project finish later, not earlier.

It's a valuable insight, and one which is regularly taken into consideration when making staffing and planning decisions today. But this 300 page book contains much more just this assertion, and since it was written in 1975 (and re-issued in 1995) large chunks of it are so out of date as to be of only academic interest.

There are a few other points that Brooks makes in various essays that are still worth emphasizing today. The one that I found to be most compelling was his claim that for a system to be produced efficiently it has to have a conceptual integrity that can only be achieved if the architecture come from the mind of one or two people. As a product manager, this also started me thinking about whether a new product could succeed if features and requirements were prioritized by more than one or two people. In both cases, Brooks seems to agree that if the work can be broken down into high level chunks with rigorously defined interfaces, as in classic object oriented design, the resulting sub-projects can be delegated out, so long as each piece is once again designed by one or two minds.

Another area that feels plausible, although I can't confirm it from experience, is the "second system effect"; the tendency of product architects on their second project to try to do all of the things they feel they didn't get to on their first one, regardless of whether that fits the new project. Given that we now take for granted that feature creep is bad on a project and that features not wanted by users are bad for a product, some architects may have been trained out of this mental trap, but it seems such a natural human response that it is probably still worth looking for.

But much of the rest of the book has been supplanted by modern practices and processes. The section on programming "surgical teams" for example postulates one secretarial support person per chief programmer - an obvious anachronism today. It also postulates a world where organizations have the option of hiring as many top level minds as they need, something that in today's marketplace is the domain only of companies like Google. (And even in 1975 could probably only have been guaranteed to an IBM manager.)

Much discussion is devoted to the intricacies of bug checking and machine-time sharing on systems now more than 30 years old. Scheduling, documentation, and maintainability issues are touched upon, but except to highlight the fact that theses have been important issues in software development for a long time the discussion does nothing to enlighten the modern practitioner, and may on occasion mislead.

Overall I agree with the consensus that this book was important, perhaps even seminal, in our understanding of many software development issues. But the best way to read it today is to be willing to skim quickly over out of date material to find the nuggets of wisdom that remain relevant.

There are very few great essays on software. If we were to assemble them then this book would undoubtedly sit on the top.

The Mythical Man-Month started of as great piece of software project management book heavily based on the OS/360 project. Despite its age the book has managed to retain value for its readers to this day. A sign of true classics.

One of the well known quote from the book "Adding manpower to a late software project makes it later." has gone on to become a law on to itself "Brook's Law"

I think this book should be made a mandatory reading for all the aspiring project managers.

Pros: Great set of essays on software engineering
Cons: None

Note: Buy the the 20th anniversary edition as this has a new chapter chapter titled "Propositions of The Mythical Man-Month: True or False?" which contains updated stuff for the previous 17 chapters.

Brooks captures in an excellent way the essence of software development and SW development planning. Although the book uses some examples which can be considered old the ideeas are still usefull after 20 years.

There were only two computer programming courses at the University of Alaska - Fairbanks in the fall of 1963, and I took them both. One involved writing machine language code on a key-punch machine to run a stack of punch cards on a surplus IBM 1620 computer. The computer and peripherals were donated to the University by the feds. The 1620 was interesting in that it had 4 kilobytes (that's kilo, not mega, and not giga) of magnetic-core based memory. Along with it's peripherals, the 1620 took up most of a room measuring, as I recall, about 15 feet by 20 feet.

I wrote a little inventory tracking program that fit on five punch cards, and ran without errors. I was enormously proud, and very full of myself at the end of it.

The other course involved the study of symbolic logic. The instructor spent the entire class writing lines and lines of symbolic code on the blackboard. He never spoke a word during this process, so we students dutifully wrote down each symbol without having a clue what any of them meant. This could not and did not last. One day the instructor did not show up for class, and never came again. We never knew what happened to him. I can't help but see these two courses in the same semester as something of a paradigm for the evolution of the computer and information processing industry itself; or at least for my place in it.

I ended up with a degree in English, but I have never been able to break permanently free of my fascination with the gizmos, devices, and plumbing underneath the high concept that we now call information technology (IT). More to the point, for the past 25 years I have been making my living in the business of building interfaces between people who want information, and the ugly black boxes that hold all those magical bits and bytes which we can define, after much effort, as data.

Today I supervise a 2 to 5 person tech team charged with web-enabling a 40 data form/250 data output format system running against a live production database containing 20 + million data records. Because we are such a small team, and we have a very large project - and in the interest of full disclosure - I have become an enthusiast for the kind of software development described as Agile. Agile is defined in the Agile Manifesto ( http://agilemanifesto.org/ ).

Agile is probably not the Silver Bullet that Brooks talks about in Chapter 16 of his excellent series of essays, but it does point the way to it. My own forecast is that some form of a biological or quantum mechanism in the memory architecture of the hardware, mirroring the Agile processes, will eventually make Brook's Silver Bullet a reality... maybe in 10 more years. At that point jobs like mine - essentially software middle-men and women helping non-techs try to convert boxes and machines full of data "bits" into real-time information - will disappear.

Brooks covers the great management issues of software design and development during this period. He shows us in these few well-written essays how we are moving from an almost pure, "top-down," engineering process to an almost pure, "bottom-up," humanistic and cultural one. Because they are essays they are all - like Agile methods - succinct, readable, and to the point. Brooks refers to Jim McCarthy, then of Microsoft, and the development manager of Microsoft's very successful Visual C++ product. In McCarthy's own book, "Dynamics of Software Development," published in 1995, McCarthy talks about the six elements of aesthetic form in the arts: unity, theme, variation, evolution, balance and hierarchy, and how these are critical to developing and delivering great software on time and on budget.

In his preface to the 1974 edition, Brooks refers to Tom Watson of IBM asking why software programming is so hard to manage. This is a great premise for the series because there is no real answer, yet, to Watson's question. It is still - more than 30 years later - very hard to manage software development, and, according to Brooks' 1985 essay, and his 1995 update, there still is "No Silver Bullet."

For tech geeks like myself, or for those who are simply trying to understand what the modern world is all about Brook's essays are must reading. Five stars - No question.

I first saw this book in a college bookstore in 1976. I did not buy it then, and have seen it referenced several times through the years as a significant computer science text. Well, I finally decided to hunt it down and buy it!

After reading it, I am sure glad I did. Even though few might remember the IBM 360, the lessons learned are still valid today -- like "adding resources to a late project makes it later." With proof.

This particular edition includes a follow up by Dr. Brooks written 20 years after the first edition was published. He is very frank about how he has changed his mind over the years (not much, but some), and the whole chapter shows a glimpse of the mind of one of the great men in the field.

Now I wish I had it in hardback...