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. ( )

The book that said "nine women can't make a baby in a month": projects don't scale with warm bodies. Brilliant. ( )

Brooks, Frederick P.. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1995. A classic. This was a valuable education for me; I had the belief that shipping software is primarily about writing and testing code. Wrong! Brooks does a great job at explaining why developing software is hard: the need for conceptual integrity, to resist the urge to tinker, and handle the human element of software.

A great book for thought. ( )

Wow. If you missed my blog entry you should definitly read "No Silver Bullet" if you read nothing else out of this book. I can see where this book is considered a "classic". The ideas expressed have since been expounded upon with a multitude of books covering a single essay. I wouldn't recommend it to a beginning Software Engineer but I would and do recommend it to intermediate software engineers. People with a couple of years experience that have started to think about the problems addressed in this book.

The major important concept of the book is the downward curve in productivity per worker as additional employees are added to the project.

The book goes through a lot to prove this and give some reasons for it (for example more permutations of communcation connections between employees).

The down side is that there is just too much outdated material in this book to make it worth reading. If you fully grasp the above concepts, skip this book, otherwise you will be bored to tears. If you don't grasp these concepts, then read the book as it is the best place to start on the subject. ( )

This is truly a must read. Many have said that this book is quite out date, and I don't outright deny that charge. However, it is still very relevant and helpful. I found at least half of the chapters to be very sharply applicable to today's software engineer. If you have any involvement on any organized software project, please do yourself a favour and get this book!

Although much of the approach Brooks advocates has been common practice in the software industry in the 30 years since the book's publication, The Mythical Man-Month remains as relevant today as when it was written. It references obsolete platforms like System/360 and Multics, and is set in a world where punch cards and PL/I were state-of-the-art, but human nature hasn't changed. The few parts that are truly irrelevant remain charming, like this comment: "The Apostle Peter said of new Gentile converts and the Jewish law, 'Why lay a load on their backs which neither our ancestors nor we ourselves were able to carry?' I would say the same about new programmers and the obsolete practice of flow charting."

This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs!

[2006-07-24] ( )

An excellent book on management and software development. It is remarkable how much Brooks gets right. ( )

While some may say this book is out dated there are still important lessons to be learned from it. I feel, however, that because the examples given to back up the arguments are now out of date it may make reading the book difficult for those who were not around at the time the original edition was published. ( )

A so-so read. Many essays are outdated, but the MMM essay is still highly relevant. It alone is worth reading today. ( )

I bought the 1982 edition from Abe books because I was too cheap to shell out $33 for the 2005 edition.

It's a good book, but a bit dated. Many of the suggestions are now standard business practices and it is more specific to programming than is really necessary. I bought the book specifically because I was interested in using the concept "Plan to Throw One Away" at work.

I laughed when the chapter started talking about the problems with scaling-up pilot chemical plants. I recall that lab VERY well. You build a pilot plant to prove that the process will work. You hope that when you scale it up, the reduced losses will make it efficient. I don't think the analogy is correct, but the lesson is a good one. Don't develop a new process without thorough testing, during which you'll probably have to throw the product away. Work the bugs out during the pilot, and then implement. ( )