Customer Review

357 of 367 people found the following review helpful
5.0 out of 5 stars I would give it a 100 stars if I could!, May 29, 2004
This review is from: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) (Paperback)
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.
Communication:
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No

[Add comment]
Post a comment
To insert a product link use the format: [[ASIN:ASIN product-title]] (What's this?)
Amazon will display this name with all your submissions, including reviews and discussion posts. (Learn more)
Name:
Badge:
This badge will be assigned to you and will appear along with your name.
There was an error. Please try again.
Please see the full guidelines here.

Official Comment

As a representative of this product you can post one Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
The following name and badge will be shown with this comment:
 (edit name)
After clicking the Post button you will be asked to create your public name, which will be shown with all your contributions.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.  Learn more
Otherwise, you can still post a regular comment on this review.

Is this your product?

If you are the author, artist, manufacturer or an official representative of this product, you can post an Official Comment on this review. It will appear immediately below the review wherever it is displayed.   Learn more
 
System timed out

We were unable to verify whether you represent the product. Please try again later, or retry now. Otherwise you can post a regular comment.

Since you previously posted an Official Comment, this comment will appear in the comment section below. You also have the option to edit your Official Comment.   Learn more
The maximum number of Official Comments have been posted. This comment will appear in the comment section below.   Learn more
Prompts for sign-in
 

Comments

Tracked by 1 customer

Sort: Oldest first | Newest first
Showing 1-10 of 10 posts in this discussion
Initial post: Nov 7, 2008 6:12:28 AM PST
I think I'll just print and frame this and send it to my boss.
JJ

Posted on Nov 15, 2008 9:57:58 PM PST
Sweet, I don't have to buy the book now.

Posted on May 22, 2009 3:32:30 PM PDT
Brian says:
She? Do you mean Cobol?

Posted on Dec 13, 2009 12:00:09 PM PST
[Customers don't think this post adds to the discussion. Show post anyway. Show all unhelpful posts.]

Posted on Jun 30, 2010 3:52:25 PM PDT
JZ says:
[Customers don't think this post adds to the discussion. Show post anyway. Show all unhelpful posts.]

Posted on Aug 15, 2010 11:21:08 AM PDT
That was one of the best reviews I've read. Thank you.

In reply to an earlier post on Jan 30, 2011 12:24:26 PM PST
I'm an experienced programming manager, and I assure you that these ARE established facts, just as true now as when the book was written.

In reply to an earlier post on Mar 21, 2011 4:29:31 PM PDT
Last edited by the author on Mar 26, 2011 8:51:59 AM PDT
[Customers don't think this post adds to the discussion. Show post anyway. Show all unhelpful posts.]

In reply to an earlier post on Jul 21, 2011 3:45:02 AM PDT
Uri Raz says:
Acute Observer: regarding your last paragraph - have you considered the possibility that the system is designed the first time by someone who designed twenty systems, and the second system would be his twenty-first system ?

In reply to an earlier post on Feb 16, 2012 12:24:17 PM PST
Just a comment on the last point. Your contention that the second system an engineer designs will be the most bloated system she will design only contradicts Brooks advice of throwing the first system away is only true if the engineer designs two systems.
‹ Previous 1 Next ›