The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Fredrick P.Brooks (1995)
Review date: December, 2008

This is the book that started it all, and probably is the most frequently quoted piece of software development literature. To skip ahead, this is where the phrase "silver bullet" was first used, and this is where Brook's law "Adding manpower to a late software project makes it later", was formualted.

The original book consists of fifteen chapters, each treating one aspect of software development or another. The chapters have colorful titles like "The tar pit", "Why did the tower of Babel fail", or "Hatching a catastrophe". So, what is this classic about? This summary may not give the contents justice.

  1. Why software creation is fun, and differences between a "product" and the more complete "programming systems product".
  2. Time estimation and the complexity of trading time for manpower.
  3. Structure of an expert team.
  4. Conceptual integrity is maintained by few.
  5. The second system build by an architect suffers from feature-creeping.
  6. Certain types of documentation.
  7. Work division and communication.
  8. Hard data on programmer productivity.
  9. Program space requirements.
  10. Vital documents.
  11. Prototyping, change, and maintenence.
  12. Tools and building environments.
  13. Debugging, and some design.
  14. Project followup.
  15. "Self-documenting" programs.

Again, please note that these summaries have been made subjectively, and may not truly reflect the essence of a particular chapter.

The difference between the original book and the second anniversary addition is four new chapters. They have been added many years after the original print and continue where the first edition left off.

"No silver bullet" is a reprint of the author's classic paper, and comprises chapter 16. Chapter 17 answers arguments thrown at this very proposition, in which the author states that there doesn't exist a single technique that will increase software productivity with an order of magnitude (within a decade from the time of writing). In chapter 18, the entire first edition is summarized very briefly, and the author makes comments on whether his assertions on a particular topic were correct in retrospect. Statements that have been made obsolete at the time of writing the second edition have been marked as such.

Finally, there's a roundup chapter, written approximately 20 years later, where the contents of the book are validated against some new insights.


No doubt does this book deserve to be one of the greatest classics of all times in its field, but... There's a "but". As time passes some of its contents get hopelessly invalid. For every immortal passage and insight, it also contains a statement like "On a Model 165, memory rents for about $12 per kilobyte per month". This may bring forth some nostalgic tears among the true old-timers, but for the younger generation of software people this is abstract.

Nevertheless, if some parts and chapters are read more lightly, this book amazes by its insights and statements, of which many still hold. As always, I've jotted down some points worth discussing in-depth.

The first chapter is amazing; here you get the feeling like "the guy really knows what it's about", and then you get struck by the fact that this was written in the seventies.

Two or three chapters later, the author talks about conceptual integrity and the benefit/must of having few system architects in order to achieve it. Now, I may blame my inexperience, but this is the best discussion of conceptual integrity I've ever seen, and the good part is that this is a theme that keeps recurring throughout the book. Many paragraphs end with the conclusion that the conceptual integrity of a system must be maintained.

If you want proof of the author making eternal statements, turn to page 100. In a discussion of where programmers placed their dirty code (sort of), the author touches on the thing that I consider being the biggest problem of some, let them remain unnamed, agile methods: solving your little problem, written down on your little piece of paper, may not lead to an optimal solution in the long run. Some ten pages later, those of us who like written decisions and specifications find good arguments for this.

Maintanence and refactoring (although not named like this, of course) are also treated: the author claims that the first version of a system will be too poorly implemented to function properly, either because of performance or lack of usability. The cure to this is either a rewrite or alterations "piece-by-piece". Well, I guess all of us have seen this happen.

Project completeness is also touched on. In an inconspicuous section, we find gems like "coding is 90 percent finished most if the time" and "debugging in 99% percent complete". Do we recognize this?

The "No silver bullet" chapter, is without doubt the book's greatest contribution (even though it appeared in the second edition). At the beginning of the chapter the author elaborates on the inherent complexity of software and its development in a very convincing way. Whenever you think you're stupid because you can't solve a programming problem, read the first pages of this chapter.

The last gem I'm going to bring up is an argument related to object-orientation found towards the end of the book. Often I've argued that object-orientation doesn't need an object oriented language to be implemented (although it helps), and I've never seen anybody really concur. Well. OK, I haven't really been looking, but somehow this discussion should be more controversial. Anyway, the author argues that the flaw of object orientation its bound to complex languages. Instead, attention should be directed towards the principles.

By now, you should be tempted to read more, but as always, there are some gotchas. In this book's case they are all derived from its age. In general, as soon as hardware and operating systems are discussed, things become abstract for those of us who are younger than 40. Also, some practices have changed since then...

Among obsolete things we find the concept of the "surgical team", a team of almost ten people that support a single programmer directly or indirectly. I wish things would work like that today. Later on, the author takes Dijkstra on defending GOTO.

A true thing of beauty is the concept of "self-documenting programs". I will say no more, but take my hint: I mention self-documenting programs in the section where the bad things are listed. Seriously, ready the book. I don't want to spoil the fun.

Until this point this hasn't been much of a review, I've only selected the good and the bad parts and commented on them. Well, that's how I felt this book should be treated.

Read or not read then? Read, of course, though your mind will oscillate between awe, and ridicule, depending on whether you read about silver bullets or self-documenting programs.

Who should read this book

This is the most quoted book on software development ever! Everybody who is the least interested in the roots of the discipline should read this book. The primary target audience would be project managers, as the few technical recommendations that are given are very obsolete, and don't really enlighten developers on technical issues.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.