Book Review: The Mythical Man-Month
December 28, 2011
As part of my employment at ThoughtWorks I am afforded a book allowance. This prompted me to look around and figure out which books I really should have read by now. One name which came up quite a few times and which has often been mentioned to me is The Mythical Man-Month: Essays on Software Engineering.
This book introduced the famous concept of ‘9 women can’t make a baby in a month’ which is an analogy for saying that adding more people to a late software project makes it later. It’s also featured on StackOverflow’s list of books to read and Jeff Atwood has it on his list of recommended books with the note ‘If you haven’t read it, shame on you’.
Having now read this book I would like to ask everyone who recommended it one question: Did any of you actually… read it?
The Mythical Man-Month
Ok, true to the title – this book really does introduce the concept of the mythical man-month. It considers the mythical software project which is behind schedule, has more developers thrown at the problem and tries to prove that it’s a bad idea. Not that I really doubted this concept, but it’s always nice to have some positive confirmation.
This all happens in the first chapter. From there on the author dives into managing software architecture and doesn’t really ever return. Apart from the examples being so outdated I’ve only really heard of one or two of them (in history books), the entire book reads like a dinosaur. If you don’t believe me, here is a direct quote from the book.
Meanwhile, the whole notion of batch debugging without recompilation was becoming obsolete. Interactive computing systems, using language interpreters or incremental compilers have provided the most fundamental challenge. But even in batch systems, the appearance of fast-compile/slow-execute compilers has made source-level debugging and snapshottting the preferred technique. How much better the system would have been if the TESTRAN effort had been devoted instead to building the interactive and fast-compile facilities earlier and better!
Yes, if only. Obviously I am not providing any context here, but I would like you to consider what context this text could possibly be placed in while still making it relevant to you.
Why this book is a dinosaur
So apart from the examples being from the stone age and the diction being long-winded, I tried to take a step back and consider why the concepts being discussed seem out of place.
It comes down to Agile development. Pretty much all the concepts and possible solutions introduced are superseded in one way or another by Agile.
To give you a perfect example, there is an entire sub-chapter dedicated to the concept of Telephone logs. The idea here is that the software architect for some or other system will continuously be bombarded by telephone calls requesting clarification on some or other detail. His word should then be taken as absolute law and he should furthermore keep telephone logs of all his conversations which should then be incorporated into the software implementation documentation on a monthly basis.
This book seems to advocate the incredibly outdated software life-cycle: the client specifies the project in full, requirements are drawn up and built into specifications, the implementation team goes off for months or years, comes back and everyone realizes it’s not what the client wanted in the first place. Those days are behind us (hopefully).
I realize that at the time this book was written this was pretty much standard practice, I simply fail to see how it still has any relevance today.
Treating Software as an Engineering Practice
As you can probably tell from the title, the author is clearly of the opinion that software development should rather be called software engineering and be treated as an engineering practice.
At some point during the early years of software development (back when batch systems and the like were still around) the industry was a bit of a mess. Projects were always late, stressful and over budget. Engineering on the other side was almost an exact science – the plans for a bridge would be discussed and drawn up by an architect, the exact materials and manpower required would be calculated, the entire cost and length of building the bridge would be estimated, everyone would go off and do their bit and it would all end up as a roaring success while being very close to the original estimates in terms of budget and duration.
It was then concluded that software development should become more like engineering and was rebranded as such. This also gave birth to the concept of software ‘architects’ and words like ‘implementation’. And software development/engineering still sucked.
Comparing software development to engineering doesn’t work. Let’s imagine for a moment that you’re developing an application in C#. If you’re using the engineering analogy writing the code would be similar to the builder adding another beam to the bridge – using a pre-defined piece of building material to fit into a perfectly conceived architectural plan.
Developing software doesn’t work like that. For one thing, building the bridge is very cheap for us – just hit that compile button! You’re actually building the entire bridge hundreds of times each day. What this means in terms of software development is that every time you write a bit of code you’re actually being an architect – you’re changing the design of the bridge little by little. If you want to see what the finished product looks like you can see it right away! Software development and Engineering are 2 completely different practices and we have long ago moved away from treating them the same.
Conclusion
To be fair, some of the later chapters are a bit more modern (especially those which were revised for the current anniversary edition), but arguing about whether or not Ada will be the next big programming language and whether or not Object-Orientated Programming will become mainstream really doesn’t appeal to me. Software development is simply a field which changes too quickly – a book which was written 10 years ago would be completely out of date, never mind one which was written 36 years ago!
I think a large part of the popular appeal of this book is unfortunately simply the nostalgia value. From a practical and relevancy perspective it offers very little.
If you’re considering this book, take my advice and save yourself the trouble – read Harry Potter instead.
Hi Jaco,
I usually don’t comment on blog posts, but believe it important in this instance.
I agree that the processes and technology referred to by the book are dated, but process and tech is not the reason for the book’s importance. The book addresses core fundamentals and principles relating to software engineering and project management.
A lot of what is considered common practice today has originated from this book. Some examples of fundamentals contributing to the Agile movement include ideal team size, organic system design and factor 10 programmers. Furthermore the paper on “Essence and Accident in Software Engineering” is key to understanding complexity in systems design.
These are concepts are building blocks to good team design and management regardless of your process model choice.
This book is definitely not intended for the novice professional looking for a quick understanding on how projects are run.
Hi Martin,
Of course everyone has their own opinion, and I welcome yours. You’re talking in some pretty general terms, while I prefer to be more specific. It’s easy to say that ‘a lot’ of today’s common practices originate from this book, but which specifically? Has our preferences for team size really come from this book, or from the industry learning what works best from 30 years of empirical evidence? How about the host of ideas presented in this book which are completely off the mark – a marketplace where you can buy object classes, for example? I didn’t read the book and try to see which ideas that are touched up could possibly have led to the standards and practices we use today – I read and evaluated it on merit.
I’m still of the opinion that this book’s popularity is due to nostalgia – similar to how so many music lovers try to argue that vinyls is somehow better. The fact of the matter is that if this book was released today it probably wouldn’t sell 5 copies.
Hi Jaco,
I agree, if the book was published today, it would in all likelihood be shunned. One has to consider that the same would happen if the likes of Shakespeare or Galileo published their original work today. The point is that Mythical Man-Month represents a milestone in the progression of our trade.
Theory and philosophy aside; I personally applied learnings from the book to my projects and ventures with very positive results. By directly applying chapter 1 and 2 to a real project; I managed to deliver it at 20% the price compared to competitors, whilst the developers earned as much 4 times their salary. Worth noting that we ensured quality was as high as needed for the situation
I don’t want to argue with you – clearly you love this book and if you manage to apply it to projects and it works for you, great. In my opinion it’s completely outdated and I don’t see the benefit. Let’s agree to disagree.
I haven’t read the whole book. But I’ve read “No Silver Bullet — Essence and Accidents of Software Engineering” and it definitly changed my mind about what i was told in university about software developement. I really enjoyed it, and I think it gives an interesting point of view.
Hi Jaco,
Of course you are right. The mythical man month was the eye opener that software can not be designed like waterfall, and all sensible software companies must have switched to agile processes by now. Would it not be great news if our industry has reached a stage that we can look back at books that are historically breakthroughs that shaped our profession?
There are still companies reluctant to adopt agile methods, with (project) managers who think developers are just typists. That is why the book is still relevant. I’m happy for you that you work in a company that makes you think the whole industry knows this book.
Cheers, Melle (yep, readdit and liked it)
You are living in a different world from most corporate grunt programmers. Mythical man month is still touted as a current book. Agile has not found its way into corporate life and I doubt it ever will in full. Maybe software companies have moved to agile but most other companies have not.
I didn’t really consider that. This really is a sad state of affairs.
Apparently you never worked for a medium/large ‘entreprisy’ company. While I was reading this book I was almost crying because I was realizing that managers were making the same mistakes over and over for the last 30 years. Overall this is one of the saddest book I have ever read and it should be a mandatory reading for everybody that is leading a project.