Rating: 
Summary: Great for understanding the software development cycle
Review: The book was written 25 years ago, about a project FB worked on 35 years ago. Though the specific examples he uses in cases are outdated, the general ideas and practises are every bit appropriate today. This should be a must-read for every project manager and release manager. Many of them don't understand how throwing more people at a problem doesn't yield a quicker solution!
Rating:
Summary: Not just for project managers
Review: You won't learn how to plan and control a project from this collection of essays, but you will learn many valuable lessons that you can apply to every project. Fred Brooks was the original project manager for IBM's OS/360 development in the mid 1960s, then the largest software development project ever attempted. Although OS/360 and its successors were enormously successful in the long run, its early days were plagued by highly publicized schedule slippages, deferred features, and unplanned incompatibilities. Dr. Brooks shares with the readers the lessons he learned from those experiences, written from the perspective of just a few years later, after he had left IBM for the academic world.
Rating:
Summary: A must for every professional
Review: Some younger programmers may get impatient with the Weinberg's references to obsolete activities, such as keypunching and submitting a debugging run, but they shouldn't stop reading. Nearly every page of this book conveys valuable insights into the nature of programming. The book is readable and entertaining, a professional book you'll read for pleasure and re-read. Weinberg adds no new chapters, nor does he edit obsolete content. Even the pagination is the same as in the original. Instead the Silver Anniversary Edition appends to each chapter a "Comments on the chapter" section in which the author relates the content you've just read to the world of today.
Rating:
Summary: A classic that all should read
Review: I read this book more than 20 years ago and I remember it so well because what it says can be still found in the everyday's tasks of the computer programming. I found especially good the chapters "man-month" and "second system".
Rating:
Summary: Best and Most Useful Software Development Book
Review: This is the best "Meta Software Development 101" book around. Without regard to programming language or platform, it describes the fundamentals of undertaking software development. Great for intelligent and open minded managers or executives (yes, a rare breed) confused by what usually happens on a complex project.
Rating:
Summary: Great book for any computer person....
Review: I couldn't put it down because it was like reading a Michael Crichton or John Grisham book. Must for any new computer person.
Rating:
Summary: The baseline reference.
Review: You simply can't have an honest argument about software engineering without the background this book provides. The canonical explanation of how adding manpower can make late projects later. The 2nd edition graciously admits some shortsightedness of the 1st, which somehow manages to emphasize how the rest of it has remained true decades later. (For a good counterpoint, I'd suggest the eXtreme Programming series.)
Rating: 
Summary: A Still-Relevant Classic
Review: Not everything in thi book is relevant today, and there are newer approaches to some tough problems that this book was too early to evaluate. Nevertheless, this book all too accurately describes many of the pitfalls of software development project management that still exist today. A must-read for anyone in the field. Barring a revolution in the way people think, it will probably always be a must-read, for those who think that this book is about technology, or about problems that can be solved with technology, must remember - there is no silver bullet.
Rating:
Summary: Oldy but Goody
Review: This book is a classic, but recently revised and corrected. The amazing thing is how relevant the book still is to software product development. If you are involved in software, this book is a must-read. The most valuable part of the book, I believe, is the "plan to throw out" prototype chapter. While the goal is always to make a bigger, better, fast whatever, it is almost an axiom that you WILL build something that has to be discarded and reworked. This absolutely happens every time, I can tell you from first-hand experience. Therefore it is vital to plan to throw out so you can migrate your users to whatever will follow. If you dream that the first product is THE ONE, you risk abandoning them on a product that will inevitably evolve. Planning the throw-away also helps meet the schedule goals by setting reasonable milestones that can be met. In my role as a product manager for a top-selling software product in its class, I found that the Mythical Man-Month was absolutely vital. However, some additional reading is recommended; Walker Royce's Software Project Management was published in 1998 and adds the dimension of software project evolution. This goes into more detail why you can't write all the specifications upfront, and even if you do, they are certain to change by the time the product is released.
Rating: 
Summary: A Classic in MIS Management?
Review: When I visited POK in May 1965 the area was abuzz with the story about the high-ranking manager who was fired and disgraced. (It was unusual to hear any talk about top management.) Fifteen months later I heard about the success of a new management technique used there. Six years later, after years of practical experience) the results were published. I wonder how much good it did since? In 1975 F.P.Brooks Jr. published his essays. The first edition explicitly noted his failure, and there was no mention of his successor. The second edition censored the details of his failure, and mentioned his successor in a footnote. He does not explain why one manager succeeded when another failed. The book does not mention a topic of discussion in the early 1960s: should a manager of programming also be a programmer? GE and RCA said "no", IBM said "yes". By 1970 that question was no longer discussed. When the programmers assigned to OS/360 refused to sign-off on the specifications and schedules, IBM turned to a Director of Engineering to head the project. Within a year the project was further behind schedule than when it started, and grossly over budget! has any other project before or since used an engineer to manage a programming project? The most quoted essay is the chapter that repeats the title. It starts out by noting that most software projects go over schedule - as if this never happens in other areas! The correct answer is that most schedules are not based on reality, but on the wishes (fantasies?) of upper management. But no one dares to mention this fact! F.P. Brooks Jr. claims the term "man-month" is fallacious. Forty-two centuries of human experience says it it NOT - if the project is competently managed. Doesn't he know that "reaping wheat or picking cotton" also has sequential constraints? Most buildings start with detailed plans from experienced builders, and proceed from excavation for the foundation to the roof, sequential constraints. He fantasizes about "pairwise intercommunication", an exercise that is a demonstration of deliberate poor judgment, or an attempt to explain away failure. In the "Sharp Tools" chapter F.P. Brooks says "I am convinced that interactive systems will never displace batch systems for many applications". The response is" word processors, spreadsheets, and the internet. Does he lack "the vision thing"? Since 1965 he has never held another programming management job, or even in engineering, his area of expertise. Any reason why? Around 1942 Henry Kaiser revolutionized ship-building with his modular approach. Could this technique ever be used for computers and software?
| 
