The Mythical Man-Month: Essays on Software Engineering

Rating: 4/4 (Undoubtedly the most important book a software engineer has to read!)

The Mythical Man-Month: Essays on Software Engineering is undoubtedly the Bible of software engineering. Written by Frederick P. Brooks Jr. in the stone age of 1975, almost everything in it is surprisingly relevant to this day. The essays are based on the lessons learnt from the mistakes and successes in the OS/360 project at IBM which Fred managed. The OS/360 was the operating system and tools written to support the System/360 architecture created in the 1960s. Thousands of engineers worked on the creation of OS/360 and thus the book provides insights into large scale software development. The principal question the book tries to answer is “Why is programming 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 explains why it is a grave error to assume that man and month are interchangeable. A complex project that has delayed cannot be brought back on track by throwing more people at it. The learning time required for the newbies and the increase in communication will only delay the project further. Chapter 3 looks at one way to handle complex projects, by forming surgical teams where the surgeon (programmer with experience) takes center-stage and the others assist him. 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 all the 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. Chapter 8 looks at various methods and fallacies of estimating how long it takes to deliver software. 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. Chapter 13 prescribes what we today called unit testing on components, regression testing on changes and system testing on integration.

The original book published in 1975 had 15 chapters. I read the 20th anniversary edition published in 1995 which has 4 new chapters. Chapter 16 is the famous paper by the author titled No Silver Bullet. This paper was published in 1986, and the author argued that no matter what magical development happened in the next decade it would not increase productivity in software development by an order of magnitude. I had not read this paper earlier and found it very educational. 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 No Silver Bullet that appeared after that paper was published. This chapter does not inform much and can be skipped. Chapter 18 is probably the most important one for the reader who has arrived this far in the book. It is a summary of all the earlier chapters and IMO acts like a quick lookup when the book is later used as a reference. In the final Chapter 19, the author looks back on the 20 years since his book was published.

Some books are indeed timeless. Not only is The Mythical Man-Month still relevant, it is still interesting to read. The chapters are peppered with quotes and woodcut figures. Examples from OS/360 and other projects from that era are eye-opening and educational from a historical perspective. The book left me wishing I had read this earlier or had this text in the Software Engineering course in my undergrad. I had been putting off this book for many years now and finally bit the bullet since it is one of the texts in the Software Engineering course I am teaching at university. In my opinion, The Mythical Man-Month is the most important book in software engineering and an essential read and reference for everyone involved in this career.

My notes from this book can be seen here.


5 thoughts on “The Mythical Man-Month: Essays on Software Engineering

  1. Pramod Biligiri 2010-09-05 / 23:27

    Definitely a good book. I read this in my first year after college..Probably worth a revisit 🙂
    Some of the stuff I have tried to keep in mind during my career are the Second System Effect, Conceptual Integrity, Surgical Teams and of course, No Silver Bullet 🙂

    Not sure if you’ve read this very recent interview with Fred Brooks

    • Ashwin Nanjappa 2010-09-05 / 23:33

      I had read a few chapters many years ago before abandoning the book. This re-read was definitely eye-opening to me 🙂

      I had not read that interview. Thanks! 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s