The Mythical Man Month by Fred Brooks has been on my reading list longer than I'm willing to admit, but I'm happy that this has finally changed. At the same time I'm confident that I was able to enjoy it far more with the professional experience I have now. I also think it was a privilege to read it for the first time in such a pivotal moment for the software industry.
This is a classic of software literature with the first edition being released 50 years ago, so when I picked the book I was mostly expecting to get a historical perspective of the industry and learn about practices we'd long since abandoned.
How wrong I was. Apart from the references to technology that has long been buried in the past, The Mythical Man Month is still a modern book on software engineering.
It was shocking to see that many of the discussions we have in this day and age were already issues back then. Throughout the book Brooks proposes solutions that were new and innovative for the time. And don't get me wrong, there are many ideas that seemed reasonable to him that we've now experimented with and moved away from a long time ago. But for every single chapter I was able to find a concept that was either a seed to a modern software engineering practice if not a if not an exact reflection of what we do today. Here are some key insights that particularly resonated with me.
In the chapter "The Surgical Team" Brooks shares a setup for software teams that is akin to a medical team performing a surgery.
"[...] each segment of a large job be tackled by a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity. [...] Who are the anesthesiologists and nurses on a programming team, and how is the work divided?"
While the proposed structure does not exactly match our current practices it's very easy to draw some parallels to how we've been organizing teams into small specialized squads. Also in this chapter Brooks describes the work of "The toolsmith":
"File-editing, text-editing, and interactive debugging services are now readily available [...]. But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team. [...] The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries."
If this is not one of the best descriptions of the work of a modern SRE engineer I don't know what else it is. Moreover, in the the "The Second-System Effect" chapter Brooks writes:
"This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.
The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one."
This can be directly mapped to our modern practices to avoid overengineering and to the "rule of three" of refactoring. Later, in the chapter "Passing the Word", we have:
"Anyone can propose problems or changes, but proposals are usually distributed in writing before the meeting. [...] These have been circulated and carefully considered by implementers and users, and the pros and cons are well delineated. If a consensus emerges, well and good. If not, the chief architect decides. Minutes are kept and decisions are formally, promptly, and widely disseminated."
And with that Brooks describes something quite similar to what we now know as Architecture Decision Records (ADRs).
There are some other examples in my list that are related to Agile practices but that I'll leave to another post. For now, I hope that I've interested you in Brooks' work, despite the age, The Mythical Man Month is a classic of our field and it's well worth the read.
What classic software engineering books have surprised you with their modern relevance? Have you read The Mythical Man Month? Share your recommendations and thoughts in the comments!
If you like my writing please consider supporting me by subscribing to my newsletter and buying my book Strategic Software Engineering on Amazon.
Top comments (0)