The Mythical Man-Month: Essays on Software Engineering

[This post was first written in 2010 when I first read this book and updated again in 2021 when I re-read the book.]

The Mythical Man-Month: Essays on Software Engineering is undoubtedly one of the Bibles of software engineering. Written by Fred Brooks and first published way back in 1975, it was updated and republished in 1995, which is the edition I read. It is a book of essays based on the lessons Fred learnt while managing the OS/360 project at IBM. OS/360 were the operating system and tools written to support System/360 computers created in the 1960s. Thousands of engineers worked for many years on the creation of OS/360, and thus the book provides valuable insights into real-world large-scale software development. The principal question the book tries to answer is “Why is software development hard to manage?”

Chapter 1 compares the creation of large and complex software systems to a primordial tar pit where animals got stuck and sucked down to their death. Chapter 2 introduces the mythical man-month and shows why it is a grave error to assume that man and month are interchangeable. A complex project that is delayed cannot always be brought back on track by throwing more people at it. The learning time required for the newbies and the increase in communication might only delay the project further. Chapter 3 looks at one way to handle complex projects, by forming surgical teams where the surgeon (principal programmer) takes center-stage and the others assist him. Though the 1960s job designations used in the book are outdated, the roles Fred describes map to how high-performing teams in technology companies are organized today. Chapter 4 preaches that conceptual integrity should be the prime aim in system design - there should be a clear division between architecture and implementation. Creating software cannot be a democracy, the core design has to come from the mind of a creator, an architect. Other members have to strive to implement this vision within the constraints of the design.

Chapter 5 cautions on the Second-System Effect, when features that could not be implemented in the elegant first system are crammed in, resulting in a incoherent, feature-choked and buggy system. Chapter 6 and Chapter 7 take the Tower of Babel as an example of a complex project that failed because of lack of communication and organization. All design specifications and changes should be written down and communicated or shared with other teams. Unnecessary communication should be reduced by suitably structuring the organization of teams and their responsibilities. I found this to be similar to how communication, guidelines, project information, documentation are organized in teams that are run well today. Chapter 8 looks at various methods and fallacies of estimating how long it takes to deliver software with numbers from (old) real-world projects. Software estimation is one of the hardest tasks in managing a software project even today. Chapter 10 looks at the importance of documentation, recommending that besides specifications the best documentation is well documented code since it is most easily updated along with the code. Chapter 11 recommends prototyping, a system written to be eventually thrown out. This is quite important for big changes to the core of a software system. Chapter 13 prescribes what we today called unit testing on components, regression testing on changes and system testing on integration.

The original 1975 edition had 15 essays. The 1995 20th anniversary edition that I read had 4 additional chapters. Chapter 16 is a famous paper by Fred titled No Silver Bullet where he argues that though computer hardware was improving by orders of magnitude in a few years, productivity in software development would not increase by an order of magnitude. Hidden in sections of this paper are simple and accessible descriptions of OOP (Object Oriented Programming), AI (Artificial Intelligence) and Expert Systems. In Chapter 17 the author takes on the criticisms to his paper No Silver Bullet - I did not find this relevant to this book. Chapter 18 is a gem because here Fred distills down all the earlier essays to short summaries - a great reference! In the final Chapter 19, the author looks back on the 20 years since his book was published.

I had been putting off this book for many years and bit the bullet when I had to teach the Software Engineering course at university. It is a timeless work - I have since read this book twice cover-to-cover, taken notes and referred to it many times. Though written in 1975, I am continually surprised how relevant and interesting it still is. Also endearing are the woodcut figures, quotes (sometimes Biblical) that adorn all the essays. I found the examples from OS/360 and other real projects to be insightful and educational from a historical perspective. In my opinion, The Mythical Man-Month is an essential read for people in every role in the software industry - engineer, lead, and product/program/engineering manager.

Rating: 4/4