Brooks is a supremely experienced developer, a solid and subtle thinker, and a very fine writer, both in terms of organization and presentation of ideas and the quality of his sentences. This book is both a must-read and a pleasure to read.
The issues that Brooks addresses may have changed in their specifics - I see very little talk about Ada in my other readings on computer science - but not in their essentials. I read several chapters of this book this morning in a coffee shop, then pulled out a stack of printouts to try to understand someone else's code, and much of what I had just read was alive in what I was doing. The importance of clarity and craftsmanship in the design of code: the code I was reading was Java, but written like C, constantly taking advantage of accidents of language to achieve reasonable results in baffling ways. The difficulty of development and maintenance: it took me about ten hours of hard work to begin to understand the organization of this code, before I could begin to address the problems of refactoring, adding features, and documentation which constitute the project I'm assigned to. The "plan one to throw away" concept: the initial code will be refactored, but only in the sense that it will be completely rewritten in place. However, the original writer's ideas provide a lot of the initial mistakes that we would have made ourselves, so his time was not by any means wasted, nor was the time I spent understanding his code. The list goes on - and Brooks understood it all, thirty-five years ago, before object-oriented programming was even a concept. ( )

The classic project management reference for information system development.

A must read for anyone who calls himself a 'Project Manager' or wants to become one. ( )

A book about technology, first written in 1975 and yet still - astoundingly - relevant.

Imagine reading along, mentally applying the lessons to your own experience when the author notes that great efficiencies would be gained if only everyone had a desktop computer... my god! This book is ancient (in terms of technology)!

And that's what is both instructive and disturbing - the I.T. field is still struggling with the same issues they struggled with a quarter century ago.

That aside, Brooks does a a fantastic job of discussing how software "is done", the contributions of each role on the team and how things get very complex very quickly as the size of the project scales up. His insights remain poignant and his credibility increases as many of his predictions from 1975 ring true today.

And while Brooks does talk about ease of use and how important it is that the application meets the needs of the people who use it, he never mentions the role of the Usability Practitioner. Is this an oversight or an active decision or was there simply no such thing as a Usability Practitioner in 1975? I would have expected him to note the role in one of his many follow-up chapters.

Speaking of which, my only critique is with the structure of the book. Brooks has returned over the years to add follow-up chapters such that its hard to distinguish what is the end of the original book and what was added later.

Wisdom is a hard thing to come by. You gain it slowly by experiencing life yourself or maybe a little faster by learning from others experience. As someone working in the field of software development its incredibly helpful to be able to differentiate temporal issues from an issue that is simply innate to the work we do. I feel I'm all the wiser for the read and I wish Mythical Man Month were required reading for my colleagues ( )

I found the essays informative, from a historical and theoretical perspective, but not a lot of help in how to improve management of projects. There are many far better books than this one for actual "how to" tips and tricks. ( )