The Mythical Man-Month

The Mythical Man-Month

It’s been over 40 years since The Mythical Man-Month by Fred Brooks (Addison-Wesley, 1975, 1995) was first published. Notably it is as relevant today as it was back then to both Program Managers and Architects.

When I first read the book in the early years of my IT career, I was in a project management role. The insights that Brooks presented were very profound and taught me a great deal at the time. The idea that “men” and “months” are not interchangeable, that “adding more people to an already late project will make it later”, or that 50% of the time for complex system-of-systems projects should be allocated for testing, are all lessons that have served me well over the years.

I’ve always thought about The Mythical Man-Month as one of the preeminent books on project and program management. So it surprised me when I re-read the book years later in an Enterprise Architecture role and discovered that it’s really a book about architecture. Statements like “The architecture of a system is the complete and detailed specification of the user interface” and “The ratio of function to conceptual complexity is the ultimate test of system design” are just as illuminating to an Architect as are the lessons I learned years ago as a Project Manager.

Many of the insights that Brooks shares with his readers are based on the experiences he had building mainframe computer systems for IBM (especially the System/360). His genius was in being able to see the patterns in which practices worked and which didn’t, and articulate them as generalized lessons that are just as applicable today in a large data integration projects or business transformation programs.

Here are a few random quotes from 1975 that are thought-provoking for issues in 2016:

  • “A programming system product takes nine times as much effort as the component programs written separately for private use.” [This may be a good rule of thumb for creating re-usable services.]
  • “If a system is to have conceptual integrity, someone must control the concepts. This is an aristocracy that needs no apology.”
  • “The purpose of organization is to reduce the amount of communication and coordination necessary.”
  • “Build a performance simulator, outside in, top down. Start it very early. Listen when it speaks.”

Maybe the real message is that in order to be an effective architect, you also need to be a program manager. Or to be an effective program manager, you also need to be an architect. It seems that the real power behind Brooks’ teachings comes from combining both disciplines.

It’s been said (I’m not sure by who – maybe DeMarco) that “The best architectures are those that are adopted”. It certainly is possible to force a poorly architected system into operation, but it generally does not last long before it is fixed or replaced. The real point behind this statement is that an architecture on paper, no matter how elegant, is a bad architecture if it cannot be implemented. As architects therefore, it is our duty to not just create specifications, but to roll up our sleeves and take responsibility for seeing them through into operation. Which of course is one of the reasons I am such a strong proponent of the BOST™ approach.

Finally, here is my overall favorite Brooks quote: “How does a project get to be a year late? One day at a time.”


  • Rodrigo Rodrigues

    John, it is really elucidating …. I’ve not read the book yet, but will… soon.
    I’ve always thought that the kinetic power of the brain is intrinsic to the ability of architect. Since I was very young I’ve been intrigued by the force that pulls ideas together to transform materials into concrete solutions, so every time I’ve gained a present or a toy, I would dismount it solely to see how it works, and possibly to get to those ideas behind it. I’ve collected ideas through my entire life, and discovered, rather old I guess, that my passion is architecture of systems (in our currently case, integration of systems and things …).
    I think, today, that ideas are timeless, and so is architecture. For instance, I’ve studied Oscar Niemeyer’s architecture as if looking through a system or solution to a housing problem. It’s been said that he, Oscar, has seen all his work through construction and on… And the role of an architect is to ensure its work will endure and function as possibly. In a way, a program manager could think like this, but in my humble opinion, it is not quite as responsible for the whole as the sum of its parts, and the architect gets to be inside the creation, which is something completely unique that the program manager is not involved. If you get my meaning.
    Reading a book from 75 and feeling it would be suitable for now, 41 years later (almost my age…), it’s a proof that architecture itself an the ideas are timeless. Don’t you agree?

    • John Schmidt

      Rodrigo, good comments. I also used to love taking things apart when I was young to see how they worked. Quite often I couldn’t put it back together, but that didn’t matter if I learned something.

      • Rodrigo Rodrigues

        My grandfather would go through the process with me when I was very young, and helped me to put it back together, which almost always worked… hehe 😉
        When he was gone I started to do it by myself, with a kind of “mission” to succeed everytime, in his name. This was amazingly fun and construct part of my character and knowledge.

  • David Vancina

    TMMM was required reading in my Information Systems degree program at DeVry. (This was a lot closer to Brooks’ day than we are today!) Loved this book and have drawn from its principles often. I will have to find my box of college books and reread. (I just finished rereading “The Soul of a New Machine” recently — another favorite.) Thanks, John!