countdown boutiques-francophones Learn more scflyout Home All-New Kindle Music Deals Store sports Tools Registry

Customer Reviews

4.5 out of 5 stars
4.5 out of 5 stars
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on May 29, 2004
If you have managed some software projects or have worked on some non-trivial software systems, undoubtedly you have faced many difficulties and challenges that you thought were unique to your circumstance. But after reading this book, you will realize that many of the things you experienced, and thought were unique problems, are NOT unique to you but are common systemic problems of developing non-trivial software systems. These problems appear repeatedly and even predictably, in project after project, in company after company, regardless of year, whether it's 1967 or 2007.
You will realize that long before maybe you were even born, other people working at places like IBM had already experienced those problems and quandries. And found working solutions to them which are as valid today as they were 30 years ago.
The suggestions in this book will help you think better and better manage yourself, and be more productive and less wasteful with your time and energy. In short, you will do more with less.
Some of Brooks insights and generalizations are:
The Mythical Man-Month:
Assigning more programmers to a project running behind schedule, may make it even more late.
The Second-System Effect:
The second system an engineer designs is the most bloated system she will EVER design.
Conceptual Integrity:
To retain conceptual integrity and thereby user-friendliness, a system must have a single architect (or a small system architecture team), completely separate from the implementation team.
The Manual:
The chief architect should produce detailed written specifications for the system in the form of the manual, which leaves no ambiguities about any part of the system and completely specifies the external spcifications of the system i.e. what the user sees.
Pilot Plant:
When designing a new kind of system, a team should factor in the fact that they will have to throw away the first system that is built since this first system will teach them how to build the system. The system will then be completely redesigned using the newly acquired insights during building of the first system. This second system will be smarter and should be the one delivered to the customer.
Formal Documents:
Every project manager must create a roadmap in the form of formal documents which specifies milestones precisely and things like who is going to do what and when and at what cost.
In order to avoid disaster, all the teams working on a project, such as the architecture and implementation teams, should stay in contact with each other in as many ways as possible and not guess or assume anything about the other. Ask whenever there's a doubt. NEVER assume anything.
Code Freeze and System Versioning:
No customer ever fully knows what she wants from the system she wants you to build. As the system begins to come to life, and the customer interacts with it, he understands more and more what he really wants from the system and consequently asks for changes. These changes should of course be accomodated but only upto a certain date, after which the code is frozen. All requests for more changes will have to wait until the NEXT version of the system. If you keep making changes to the system endlessly, it may NEVER get finished.
Specialized Tools:
Every team should have a designated tool maker who makes tools for the entire team, instead of all individuals developing and using their private tools that no one else understands.
No silver bullet:
There is no single strategy, technique or trick that will exponentially raise the productivity of programmers.
0Comment| 7 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 28, 2004
There have been many, many books on software project management lately, but this one still is one of the best. Perhaps the context of older simpler technology helps illustrate the principles more clearly. While some new technologies have an impact on projects, particularly the encapsulation aspect of object-oriented design that allows for real code-reuse, the fundamentals don't change. Further, Brooks shows us why there can never be a "Silver Bullet" that will revolutionize the art.
He covers in great detail critical elements such as team structure, development process, conceptual integrity, and scheduling issues (including the myth of the man-month, for which the book is named). Further, since he draws on experience from classic projects such as IBM's OS/360, the book has interesting history as well.
My only issue is that with recent increases in power of PCs and languages, many "projects" are now of such scope that they need only involve a single developer, in which case a different paradigm is needed.
0Comment|Was this review helpful to you?YesNoReport abuse
on November 30, 2003
Perhaps the first mass market book on software engineering, this book is a classic. It has defined the agenda for the software engineering field, as well as guide the organizational design for many software and IT organizations.
Some key concepts from the book...
- It is not good project management to divide effort by time to come up with staffing. Adding people adds commuications complexity, so double staff size quadruples the amount of communications links.
- To insure conceptual integrity, the software project needs the design to be handled by a very small group of people.
- The optimal model for a software development team is a hospital surgical unit.
- There is no silver bullet for improved quality, just a lot of best practices.
Mr. Brooks brings a wealth of experience to bear on this. As the head of some of IBM's largest operating system development projects, he's been in the guts of some of the hardest challenges the industry has to offer. He writes in a non-technical style that cuts to the heart of these difficult topics.
In the latest edition, Mr. Brooks takes a hard look at what he got right and wrong over the years. This rare self-critical analysis makes it a valuable re-read for those that enjoyed it the first time.
0Comment|Was this review helpful to you?YesNoReport abuse
on June 30, 2003
I read this book after the instructor of a computer course I took in the mid-1990s highly recommended it to students. There are so many reviews listed here for this book that I am not sure I can add anything of particular note. What I can say is that reading, understanding, and applying principles outlined in this book will help programmers begin their evolution to software engineers. I recommend this book to everyone involved in the software development process, including project managers and all software project stakeholders. Yes, I agree with some reviewers that parts of the book are a bit outdated. However, this is a highly readable book which has much timeless advice. Learn to read between the lines. If the text refers to a procedural language, and your only exposure has been to object-oriented languages, for instance, think about how you can apply the principles to Java or C++ or Smalltalk. Readers just need to understand that a book does not need to be rewritten every time the language-of-the-month changes. This book is not eternal truth. Principles do change over time. Read this as one of your primers to software engineering, and then follow up your reading with other texts. This book is quoted so often in other books and technical journals that it deserves an initial reading.
0Comment|Was this review helpful to you?YesNoReport abuse
on March 18, 2003
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on October 20, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on March 28, 2002
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on March 5, 2001
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.
0Comment|Was this review helpful to you?YesNoReport abuse
on February 22, 2001
There are few must reads in this industry. This is one. First published in 1975, this work is as applicable to software engineering today as it was then. Why? Because building things, including software, has always been as much about people as it has been about materials or technology--and people don't change much in only 25 years.

In the preface to the First Edition, Brooks states "This book is a belated answer to Tom Watson's probing question as to why programming is hard to manage." This short book (at just over 300 pages) does a masterful job answering that question.

It is here we first hear of Brooks's Law: "Adding manpower to a late software project makes it later." Brooks doesn't just drop that on the reader without explanation. Instead, he walks through the reasoning, discusses how communication in a group changes as the group changes or grows, and how additions to the group need time to climb the learning curve.

Those new to the industry or who are reading the book for the first time might be put off by the examples and technology discussed. Indeed, even in the newly released edition, the original text from 1975 is still present, essentially untouched. So, talk of OS/360 and 7090s, which permeates the text, is perhaps laughable to those not looking deeper. When talking about trade-offs, for example, Brooks offers "... OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is day 366). That might have been left to the operator." This is 26 bytes he's talking about!

Brooks provides a light, almost conversational tone to the prose. This isn't to say the observations and analysis were not very well researched. Comparing productivity number with those of Software Productivity Research (SPR), you'll find Brooks came up with the same measurements for productivity as Jones--only 20 years earlier!

Other wisdom is also buried in this work. Brooks declares "The question, therefore, is not whether to build a pilot system and throw it away. You will do that. The question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers." The state of products I buy today tells me not enough people have taken Brooks's observations to heart!

The latest version of the text includes his work "No Silver Bullet." Brooks, who had brought us so much before, had one last "parting shot."

As I started this review I will also end it: this book is a classic. Read it.
0Comment|Was this review helpful to you?YesNoReport abuse
on August 7, 2000
"Throwing more programmers at a project won't get it finished quicker." We've all heard it a thousand times. This is the book of the quote.
This has been a massively influential book and yet we still see ourselves and others making the same mistakes in software development, year in year out. It is certainly one of the 'must read' books that every project manager should read early on in their career. Written by an experienced manager, pretty much everything it says is common sense, yet it is only common sense after you've read it. Reading the book though is only the first (and easiest) step.
The hard part is putting it all into practice in the real world. To do that properly it is not enough to say that you once read it 20 years ago. It needs to be on the shelf by your desk and dipped into now and again. There's nothing so helpful as being told what to do, or not to do, (even when you already know) for contributing to the courage to go and do it. Stick by the principles of this book as far as you can and you won't go far wrong. Serious software development will never be without its headaches but that's no excuse for not doing things better.
"Be the change you're trying to create." - Gandhi
0Comment|Was this review helpful to you?YesNoReport abuse