One cannot venture far into the world of software engineering literature without hearing about The Mythical Man-Month by Frederick P. Brooks, Jr. The book is consistently hailed as a classic, so in my quest to grow as a software practitioner I decided to shell out and see what all the fuss was about. Unfortunately, being written in 1975 (re-issued in 1995 with minor changes to the original material), it seems so out of date now that I doubt it can have more than academic appeal.
I found the book to be mostly 300 pages of anachronisms, such as machine-time sharing on systems now more than 40 years old, secretarial support for the chief programmers (“secretaries” meaning a “keypunch operators” as I understand it), and the general notion of a world where an unlimited supply of top programmers is available to every organization.
While Brooks touches on the timeless issues of scheduling, documentation, and maintainability, the discussion does not seem to highlight any salient points relevant to the modern developer. That might be either because Brooks’ lessons have been tightly woven into current best practices, or because it’s simply been superseded – I don’t know which is correct.
The only point I found to be somewhat interesting is the one he makes about conceptual integrity. Brooks states that in order for a system to be produced efficiently, it has to have a conceptual integrity that can only be achieved if the architecture comes from the mind of only one or two people. Brooks suggests that if the work is too large for two, then they can create the top-level architecture with rigorously defined interfaces, and the sub-projects can then be delegated to others, and so on, so long as each new level is designed by one or two people to ensure conceptual integrity at each level. Whether this is actually accurate or relevant today I am too inexperienced to say.
Summary
Surely anything still worth retaining from this book has been said countless times since, with much more relevant and recent examples. That is not to say that the book was ever without merit, not at all; I have no doubts that this was a highly important book in the 70’s and 80’s, and thus indirectly also today by helping the field of software engineering move forward. I just highly doubt The Mythical Man Month will make you a better programmer today. Go read Facts and Fallacies of Software Engineering instead.
Summing up
-
Hopelessly outdated for practical purposes
-
Some value as a historical curiosity
The lowdown
If you’re a developer looking to improve yourself, your time is better spent elsewhere.
You may benefit from an old Zen proverb “empty your cup” meaning you cant receieve new information if your “cup” is full. When you “know” about a topic, its hard to really pay attention and take in new knowledge about the same thing. When you detect that you’re being taught something you already know (Lessons tightly woven into current best practices), you pay much less attention and miss any extra insight and chance at a deeper level of understanding. Understanding the “why” is just as important as knowing the “what” because it helps you execute the lessons more accurately and prevents you from blindly applying lessons to situations they might not work for.
Thanks for sharing your thoughts! I completely agree that understanding the “why” is just as important as knowing the “what”. Personally I think I’m fairly skilled at seeking out and retaining exactly this kind of knowledge.
Is there anything in particular you think I might have missed from this book?
Though I’ve read it almost 15 years ago, I think you didn’t catch the real message. Yes, the punch cards are fun stuff (indeed, I enjoyed those parts), but this book is not for the software engineer in you. It’s for the manager. Here are the most valuable (and still valid) lessons and observations, that I think make it worthwile (or at least made it so 15 years ago for me):
– adding people to a late project will make it later. Communication has an overhead that grows non-linearly (superlinearly, Brooks says it’s quadratic) with team size.
– the infamous ‘no silver bullet’ chapter introduces the idea of accidental and incidental complexity, stating that there is an inherent complexity in creating software (or any solution to any problem) that won’t go away with better tools. So it will always be hard. (Addendum: until we create AI.)
You might be right, and I might get more out of this book if I re-read it after becoming more experienced (when I read it 1.5 years ago I had literally just been employed in my first position as a software developer). Still, I stand by my claim that whatever relevance the book has today can be found better explained elsewhere (e.g. “Facts and Fallacies of Software Engineering” by Robert L. Glass, as I mentioned in the summary, and which covers exactly your point regarding adding people to a project), or are already part of widely known best practices.