Book Review: The Mythical Man-Month
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.