Rating: 
Summary: Read the 1st edition, sure to love the 2nd.
Review: I bought the 1st edition many, many years ago, probably back in the early 80s when I was just starting out as a programmer. It has made an incredible difference in how I view the art of computer programming. I was friends with a college professor at a local university (not the one I attended). I recall that when a new employee first started in his department where he worked before being a professor, he would give him a copy of "The Mythical Man-Month" and Kernighan and Plauger's "Software Tools", and send the employee home until they'd read both. Should I ever become ruler of the known universe, I'd make that a law. "Software Tools" was interesting for a few years, but I eventually had enough experience that I no longer needed it. I still find "The Mythical Man-Month" incredibly valuable, but virtually unknown amongst the programmers I work with today, so I'm buying 6 copies today for my co-workers. It is a must-read for any professional programmer or program manager.
Rating: 
Summary: Great book, yet old
Review: This is a great book for software engineering. However, it is not a reference book for you to learn the SE in general, rather it is a book pushing you hard to think the SE in general. The book has a age of more than 20 years, but most conclusions are correct. Being a software architect, how sad I am !
Rating:
Summary: One of the Few Timeless Software Engineering Titles
Review: This book is SO good that I am not even certain that I feel honored to have the ability to rate it!The mythical man-month draws important distinctions between the management of software projects as compared to physical products (e.g. construction, car parts, etc.). These differences include the "man-month", or what can be accomplished by one man in one month. Drawing powerful analogies between poor software engineering (such as expecting 9 women who are newly pregnant to produce a baby in 1 month), Brooks succinctly identifies key areas of oversight made by managers. I recommend this book to all students of software engineering, technology managers, and all people who are tired of working on yet another late and over-budget project.
Rating:
Summary: Condensed project wisdom for the ages
Review: I discovered this book almost 5 years ago, while managing ever larger projects for a consulting firm. The technology has changed, the dynamics of the workplace have changed, but most of the author's points are still valid. Toss out the references to arcane technology and focus on the people and processes that make projects successful. Technology projects are about people and we haven't changed much in the last 10,000 years. It is rare to find a book so readable and thought provoking.
Rating:
Summary: timeless, insightful
Review: A classic book about the development and management of large scale software projects. One of the industries veterans shares his experience and his views gathered mainly during the development process of the IBM OS/360 operating system. Yes, this book is more than 20 years old - which makes it even more interesting (or shall I even say: sad?) to see that many of the observed shortcomings and pitfalls are still the industries greatest problems today. Maybe all management and developers alike should be required to read this book prior to getting a job in the field. Although the book does feature some code examples these are few and far in between, it's main focus lies on the coordination and management aspects of software projects. The somewhat poetical title hints at one of the most stressed points, namely that men are not interchangeable and that twice as many engineers don't cut development times in half. Brooks also offers his opinions on the psychological aspects of systems design, backed up by his experience and occasional statistical evidence. This anniversary edition features a review by the author, where he sums up what points he thinks remain valid in hindsight more than twenty years later.
I particularly enjoyed a beautiful chapter titled: 'The joys of the craft' where Brooks tries to explain what fascinates and captures him about programming. If you happen to be stuck on a frustrating stretch of your project - read this chapter and you'll feel better - I did.
Rating:
Summary: Misleading title
Review: For some reason I bought this book thinking it was going to be about the Moth-Man. Well it turns out it is about the Man-Month, which contrary to what the cover leads you to expect is not a monster deposited on Earth by space aliens. Like Moth-Man. Be warned this book is not as it would appear to be!
Rating: 
Summary: Outdated, sexist, unnecessarily religious, and often wrong.
Review: I don't know about you, but I am not interested in reading a book on managing computer software development as a trip down memory lane. It's just not a fun way to spend a weekend. I bought this book to improve my skills in the world today, and it was 80% useless. If you are a retired software engineer, and want to relive the good ol' days of Big Blue, this is the book for you. For the rest of us, it's a waste of time. Here are the reasons I think this book is useless. 1. IT IS SEVERELY OUTDATED
Do you know what OS/360 is? How about Exec 8? Scope 6600? Multics? The author uses these as examples throughout, and I have no idea if he is holding them up as good or bad, because I have no idea what they are or what they signify ... and the author doesn't really explain. For the under-40 crowd (under-50? I don't even know WHEN these were made, or who used them) this is completely mystifying. It's not just that the technology has moved on ... it's that the book takes up an awful lot of space dealing with the specifics of the old technology. He makes recommendations about using microfiche, assumes memory is made of gold, suggests that you hire secretaries to key-punch in the hand-written code of the programmers, doesn't know about version control software like Perforce, etc etc. Personally, I don't know who in the software business has the time or energy to read all this old, useless material. It should have been edited out for the re-print. There is certainly no need for it, other than to mark the book as quaint... 2. IT IS RELIGIOUS AND SEXIST
Additionally, I am perpetually put off by the sexism and the religious [stuff] in the book. Religion, you ask? What does this have to do with systems programming? I ask that too. And can't the editors remove the all-male references in the book? Apparently not. Here are a few of the totally inappropriate comments he makes about sex and religion that made it hard for me to stomach the book: "A team of two, with one leader, is often the best use of minds. [Note God's plan for marriage.]" EXCUSE ME?????? "...this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake." "This description, which Miss Sayers uses to illuminate not only human creativity but also the Christian doctrine of the Trinity, will help us in our present task." Note: The author refers to all men by their last names alone (Watson, Cosgrove, etc.) but to all women with the title "Miss" (Miss Sayers, Miss Campbell etc.). And he refers to all workers as men, to their output as man-hours or man-months, and to all people in this book as He. There isn't any balance at all, despite the large numbers of women in the software industry today. Yes, the book was originally written 30 years ago. But this version was published in 1995, and by then the sexism in most publications had appropriately been exised and replaced with a more just system of using He and She interchangeable, and People instead of Men. The Christian references (to the Tower of Bable, to Noah's ark, to Reims Cathedral "proclaiming not only the glory of God but also His power to salvage fallen men from their pride") are also odd, and distracting. A large proportion of the people in the software industry today are not Christian, and this Christian bias is oddly insulting. It is particularly odd because it doesn't actually add anything of value to the message of the book. 3. IT IS OFTEN WRONG OR POORLY WRITTEN
One chapter is from a paper written in 1986. The next chapter is a comment on all the criticisms written on that paper. Nearly every single one of the author's comments says, "So-and-so doesn't agree with my thesis, but he misunderstood what I was trying to say." He spends over 20 pages explaining what he "meant" to say. He also has retracted certain sections completely, but he didn't do this in the main part of the book. He did this in the back, in an outline that is likely to be skipped by most readers. This is a weak way to put out a new version. Hello, take the time to re-write the book with the updated information. Remove the obsolete references and either add new ones or skip concrete examples completely so that the book will be less grounded in one narrow slice of time. Take the responsibility of an author and make the book worth reading. This book is a must-skip. The editor should have demanded a new version, or not published it at all.
Rating: 
Summary: Why people like this book
Review: A lot of programmers really love this book. It will arm you with a dozen good juicy quotes that will support your argument that your manager is an idiot. Lets say you are late and another programmer is assigned to help you out - you can simply point to this book and explain how adding more programmers to a late project will just make it later. If that one doesn't fit. you can surely find another one that does. If you liked "Catcher in the Rye" or "The Peter Principle" you may like this book too. Software management is hard - mostly because there is a great deal of variation in the talent and productivity of computer programmers. This book is a fun read - and food for thought. And in its defense I must admit it has changed the way I think about large software projects. But sadly, beyond the fun quotes and maxims (which often contradict each other) there is not much to help you get the job done.
Rating:
Summary: Ultimate attitude adjuster
Review: Even though some of the essays in this book reference engineering constraints that many feel are aged and outdated (like ensuring your code uses as little memory as possible because when the book was written RAM was expensive), it is in fact filled with easy-to-read wisdom that every engineer should know. And for the record, you should write code to use RAM economically. It may no longer be expensive, but come on, man. I've found this book is best used to whip people into shape. For example, when someone in a management position considers adding engineers to a late project to "get it out of the production queue," its helpful to have them read three or four select pages. Its the ultimate attitude adjuster. So even though the book was initially written at the end of a development cycle freaking 20 plus years ago, consider its utility as an attitude adjuster when introduced in this context: "Here's a book on this very topic, written by a fellow written 20 plus years ago. The Association of Computing Machinery considers it applicable to this day." Sometimes the old school simply reigns.
Rating:
Summary: A book that every software person should read
Review: Written in 1974, this book has aged well and in many areas not at all. Which is both a good thing and a bad thing. It is good in the sense that Brooks identified many characteristics of software development at a time when software engineering was still a newborn. The bad part is that so many in positions of responsibility need to be reminded of the basic, and accurate, points in the book.
Creating software is like dieting, in that shedding the first few pounds is easy and can be done almost overnight. However, extrapolating from the initial results is foolish, as removing each pound after that gets harder and harder. And yet, many managers do not think that way. When initial results come back, they are positive and if extrapolated, lead to rosy conclusions. Managers, being a bit rosy in all four cheeks, tend to follow this, even though Brooks and all experience emphatically tell us that each additional step gets increasingly harder.
Many years ago, when the company I worked for hired a new CEO, the software developers recommended that he read this book. He did, but it didn't help. His attitude was that our situation was different, which it wasn't. The completely predictable result was that nearly every developer left in search of more realistic grazing grounds. If you are a manager of software development at any level, do everyone, including yourself a favor. Read this book and take it seriously, it will be one of the best ROI events you have ever had.
| 
