The Mythical man-month (Review)

Bibliographic information

Brooks F.P. (1995) The Mythical Man-month: Assays on software engineering (20th anniversary edition). Addison-Wesley Professional, ISBN13: 978-0201835953

Introduction

Fredrick Brook’s book on Software engineering is hailed as one of the great books in the field. It is a collection of essays written by Brooks and based on the experiences and knowledge he gained between 1965 and the book’s first publication in 1974. The texts are written as stand-alone essays, but many of the central ideas and concepts return throughout the book. The 20th anniversary edition that I read contains an additional 4 chapters written in 1995 that look back on the previous 20 years looking at what has and hasn't changed, and asking the question why these topics are so enduring.

It has now been an additional almost 30 years since the publication of the 20th-anniversary edition. And the book remains a popular book to draw wisdom from. Many writers have performed in-depth analysis of all statements in the book, and it appears you either agree with his central premise or disagree. I will not attempt an in-depth analysis of the book. But rather a discussion of what the book tells me, and how I see its wisdom apply to the data-centric world that I inhabit.

Readers Intent

It is rare to see a book that has stood the test of time to such a degree within this field. As such I decided to read it to better gain an understanding of what it was that made it so timeless and to learn from the wisdom that so clearly had captivated so many before me. I also want to investigate, how we can take the knowledge ostensibly gleaned from early software development and see how to implement it in a data focussed context.

Discussion

The Mythical Man-month Is a set of essays that ostensibly focus on the question of how to build good software. written in a time when computer time was extremely expensive, much of the development work was performed on paper, and extensive written documentation was essential to keep everyone’s work coordinates. Individual testing was not a thing yet, let alone individual builds, or environments. Nevertheless, projects had a habit of getting out of control. Timelines were broken, and resource and cost estimates went out of the window. Whole projects are abandoned or worse pushed through at any cost. At the same time, there were teams and organisations, that managed to deliver on time. Budgets and features were delivered.

All of this sounds frighteningly familiar, I dare say to anyone who has spent some time in the software world. And it is the fact that Brooks aims squarely at the heart of these issues, which were front and centre back then and still are today, that makes the book so relatable. And I must say relatable it is. While some of the questions addressed feel archaic such as how to manage print cycles of the development manual, others are part and parcel of today’s life as a developer.

The essay the book is named for contains probably one of his most famous contributions to software management or tries to deliver its contribution. For the fact that the advice Brooks provided in 1974 is still relevant clearly shows that the lesson has not been learned. I speak of course about the idea that there exists such a thing as a Man-Month, and that one is replaceable with any other. To this day that is the go-to solution of managers the world over. Project timeline in danger, How many more people do we need to hire to save the timeline Brooks answered, so oft forgotten: None. Add people and the timeline is certainly doomed even more There are nuances to the statement that I won't spoil here, the essay is a must-read for anyone dealing with project timelines.

In discussing team structure, Brooks looks to another highly coordinated environment, surgeons. Some of the roles and tasks described are on the more archaic side, and where the text shows its age a bit. There is wisdom here, in that teams are kept small (long before the 2 pizza rule or Dunbar's number), and every member has a specialised responsibility. I think that the availability of resources and the ability to independent work dispense somewhat with the need for a hierarchical structure, especially in data processing. But I will come back more to this topic in later posts.

The next essay also contains some of the most valuable insights I have ever read about the role and relationship between architects and implementers. And makes that chapter a mandatory read for any person holding or aspiring to the title of architect. Architects are according to Brooks freed from the minutia of implementation not focusing on drawings and models detached from reality, but learning and understanding from the user's perspective. They are the user’s advocate. And should have the user’s perspective in mind, while the implementers are in charge of the actual design and how to achieve the results. Far too often the Ivory Tower syndrome also discussed by Brooks is the dominant mode. Architects view themselves as gatekeepers of an idealised design, grumbling at reality and anyone not agreeing with their perspective.

To not make this a play-by-play commentary The next several essays address questions on communication, both within the team and across the organisation. Addressing how the patterns of communication impact and constrain design. A lot of time is also spent on how to avoid feature creep and the risks and temptations of building systems for another user.

I also want to call out what are the early beginnings of a strain of thinking that has resonated throughout software development. the idea of Change, maintainability and experimentation-based development. We see in this book the early seeds of practices such as Extreme Programming, Continuous Delivery, DevOps, and early versions of Agile. Further, this book is a valuable read for those interested in where these practices come from. It is here we find the origins of statements such as: "Change is inevitable, plan for it" (Beck K. 2005: Extreme programming explained) or "A legacy system isn't badly built, but badly maintained" (Bellotti M. 2021: Kill it with fire)

The final essay I want to specifically mention is also the most discussed and most hotly debated of them all. Its name *No Silver Bullet* alludes to the content of the essay. It goes straight to the heart of the question of essential and accidental complexity in software development. He claims that there has been no change in our field that represents a change in magnitude in the improvement of work. This statement was reaffirmed in a separate anniversary essay as well. The essays provide evidence and clarification on the reasoning behind the statement. It is not my intent to reiterate them here, and any person wanting to engage in a discussion on the matter is recommended to read both papers before engaging in the discussion.

The controversy around these essays seems to revolve around that very statement and is split between the people agreeing with Brooks, and those that claim that there has been a magnitude change. It is rather disconcerting in my personal opinion to see that the people tending to fall on the side of there having been a magnitude shift, are the same people that have something to sell you that represents that very shift. Or if not selling themselves, have strong incentives to claim so based, on some decision that might have been justified premised on it providing a magnitude improvement in efficiency.

Closing thoughts

Having read the discussion, it should come as no surprise that this is another book that is on my must-read list. doubly so as it contains a lot of wisdom that is directly applicable to today’s work situation. But also because this is the starting point of so many of the prevalent trends that exist within technology today. I found it to be a read that switched multiple times from providing profound insight into today’s working, and to showing its age, with claims and statements that feel very out of touch. But I dear say that for a 50-year-old book on something moving so rapidly as software that it is relevant at all is impressive.

At times it makes me wonder if the speed at which our industry supposedly moves might be overstated, at least in its essential complexities.

As a data Engineer, I would not go looking for advice on how to build data pipelines or solve particular data problems. What this book provides, relates much more to how we work as a team of developers, and for managers how to deal with staffing and timelines. How architects should see themselves, and where to relinquish and where to hold to authority. And the final discussion on accidental and essential complexity while at times hard to follow (as evidenced by the numerous interpretations thereof) is particularly valuable to Data developers, where we still struggle to find our own and to understand and communicate the relationship between the essential and the accidental. We would all be better off if everyone had an intuitive understanding of the difference between the two.

So for everyone, do go out and pick up the book. And don’t attempt to speed-read it. Read and take the time to process, and understand how the content relates to your situations. It took me several months to process this book to a satisfactory degree. But it was worth every minute.