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.”