"Adding manpower to a late software project makes it later."
In fact, this very quote is featured in one of the book's chapters, along with many other little gems. The particular version I read was The Anniversary Edition, which featured four new chapters, and new thoughts from the author.
Now, I've read this book several times, and each time it seems I unlock another piece of the great mystery of software development. I'm not shy to say that devouring it in one sitting is a virtual impossibility for me; value takes time to unpack. It took me years to write this review, and I'm not sure I'll ever truly complete it.
I first learned about The Mythical Man-Month when I read a source online that likened the software development process to childbirth. The person who made that assertion told me that he had obtained that nugget of wisdom from The Mythical Man-Month.
And here, I found it.
"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned."
The Premise
The Mythical Man-Month is a collection of musings written back in 1995 or before, dealing with the nature of managing a software project. Brooks draws upon his experience in managing the hugely complex software system, OS/360.He starts off with a description of what a Program is, and how it scales up into a Programming Product, a Programming System and finally a Programming Systems Product. That's elementary enough, and things get a lot deeper from there.
The Aesthetics
Not so many to speak of. There are some nice prints and photos of art exhibits preceding every chapter, though I'd venture to say those are merely fluff. The visuals are otherwise very much non-descript.The Experience
Given that this was written way back then, the language used tends to feel a bit antiquated. Though the concepts aren't. Brooks has an elegant yet chummy way of writing that puts you at ease, or to sleep - pick one. He comes across as calm and logical, pretty much what any kind of Manager needs to be.Brought me back to simpler times, where men wore ties and women wore skirts. It's a bit antiquated, yes, but the truths in there are ageless.
The Interface
While the book itself is a somewhat easy read, it's sometimes hard to decipher the accompanying graphs and charts. Which is a pity, because I suspect that understanding of those would have greatly deepened the insight imparted by Brooks's writing.What I liked
In his essay, The Tar Pit, Brooks puts eloquently into words what I love about my industry, and why I've stayed in it so long: making stuff.
First is the sheer joy of making things. The child delights in his mudpie, so the adult enjoys building things, especially things of his own design.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.
Little essential truths that are only tangential to the topic. For example, in the chapter The Other Face, he discusses the importance of documentation, but also acknowledges, via the use of an anecdote, that while everybody understands the need for documentation, it's more important to know how to document. So instead of preaching its importance, he proceeds to explain how.
This quote, uttered in the context of Code Reuse. That's just zen, it is.
The best way to attack the essence of building software is not to build it at all.
Plan To Throw One Away is a fascinating chapter about trial and error. It's eerily reminiscent of my own efforts at writing mini-games at times.
Discussed in the chapter Hatching a Catastrophe, the author's words again strike a deep chord.
Conversely,when the manager knows his boss will accept status reports without panic or preemption, he comes to give honest appraisals.
Indeed, how many things are swept under the carpet simply because Management have a tendency to overreact? People need to know that their superiors are in control. When said superiors panic, it's not only the project that suffers; all future confidence in a leader is strained.
There's an outline in point form near the end of the book, encapsulating all relevant points made by Brooks, just in case the reader doesn't feel like wading through a sea of old-style English. That's pretty neat.
What I didn't
While Brooks's piece on a small surgical team being assembled to build software does sound very interesting, I'm not really sure how practical it is in this day and age. To be fair, it does read like a very early version of a cross-functional team in the Agile Manifesto.Brooks has a valid point in Tower of Babel - communication is important. Problem is, he spends a really long time belaboring the point and I really struggled to keep up.
In the chapter The Other Face, Brooks speaks of the importance of documentation. I tend to agree, but I'm ambivalent about the statement.
In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flowcharts before beginning to write programs.
Conclusion
This book is a joy to read and could very well be the Software Project Management equivalent of Sun Tzu's Art of War. As a reference on the human elements of software development, it's in a class of its own.
The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.
Sure, a lot of it comes across as common sense like the quote above. But it's common sense that is very well presented. Decades after it was first published, The Mythical Man-Month continues to be just as relevant, and that in itself is an anomaly in the fast-evolving world of software today. Part of this could be due to the fact that Brooks discusses human nature as much as he discusses software, and we all know that, unlike technology, human nature doesn't change.
My Rating
9 / 10
A book of mythical proportions,
T___T
T___T
No comments:
Post a Comment