Rating: 
Summary: Still true
Review: One of the best books ever written about programming. It is just as true now as it was when it was first published so long ago.
Rating:
Summary: a must read for anyone who manage software development
Review: Programming languages and development tools may have changed since the first edition of this book, but the problems that arise during a software project development are still the same: lack of communication, division of labor, schedules, etc. Fred Brooks presents case studies where there were such problems and how to face it. This book is a little bit dated on technical matters, but no book on software management has been so timeless as The Mythical Man-Month.
Rating:
Summary: Must read for anyone dealing regularly with complexity.
Review: This is a classic tale of managment philosophy and software engineering. It contains some of the best descriptions of human behavior and engineering intuition ever distilled into book format. A must read for anyone managing, or working on, complex projects of any sort.
Rating: 
Summary: interesting but a little dated
Review: I would recommend to anyone managing software projects who is interested in a historical context of software project management problems. Reading this book you can see that today's problems managing complexities are nothing new. The author presents a number of case studies of projects where there were management problems and how they were solved (or not solved). Though the case studies are of ancient projects there is still valuable information and lessons to learn. The author also provides a summplemental section at the end of the book providing updated comments on the original book and his "no silver bullet" essay.
Rating:
Summary: A true classic. Should be in every developer's library
Review: The original "Mythical Man-Month" was one of the best books ever written on the nature and pitfalls
of software development -- so much so that most
later books on its topic could have been written as glosses on Brooks (and many should have been!)
This book was originally written as Brooks's meditation on the development of IBM's OS/360,
but it is mostly about human creativity, psychology, and teamwork. While some of Brooks's advice and projections obsolesced along with mainframes, most remains profoundly relevant and insightful.
This edition adds a twenty-year retrospective in which Brooks comments and critiques on the original, forthrightly admitting where he was
wrong and having fun with the many more places
where he was indubitably right.
This is a wise, funny, and deeply humane book.
It richly deserves its classic status. Everyone
who cares about the craft of software development
should own a copy.
Rating:
Summary: Of interest to many
Review: This book is an amazing experience. Whether you come to it with the intention of learning more about how to manage software projects, or simply an interest in the black art of OS programmingit's guaranteed to be an exhiliarating ride. It's not only succinct, refusing to delve into details we wouldn't comprehend, it also contains enough general commentary to make it useful for anyone involved in large projects with creative people (which basically includes just about any form of productivity whatsoever).What makes the book approachable is Brooks' style, which can only be called simple. What keeps you interested in the book are the metaphoric range it has (calling OS programming a tar pit is a considerable reach of the imagination, and yet so obvious) and the rather pragmatic advise Brooks provides at every turn of the page. If you read the book carefully enough, you realize that it makes a series of suggestions about how computing is changing us and the way we create. Brooks may or may not have anticipated this, but his use of the distinction between "essential" and "accidental" difficulties forces one to think long and hard about how these are changing the world of the artist, and the world of art. Just how much writing today is a result of the writer's "liberation" from the static manuscript, either hand/typewritten? What does one lose when this discipline goes away, and what does one gain. Without the accidental difficulties, does tackling the essential ones lead us to inelegant solutions? Or does it simply extend our range, making it possible for more among us to create, and the creative genius to make more than he/she would have otherwise. Throughout the book, what kept coming back to me was the image of a Renaissance painter and his bevy of apprentices. One never knows to what extent the painting's essence was created by the master who drew the outlines and the students who painted the details.
Rating:
Summary: Excellent book, contains many truths about programming.
Review: One of the best technical overview books I've read. Brooks
was project lead for IBMs system 360 software and articulates truths I have known and experienced personally
during the last fifteen years of software development.
I really enjoyed his understanding of the limits and capabilities of the human mind, especially bandwidth
inside one mind compared to bandwidth between minds.
I found Brooks's combination of knowledge and humilty
appealing, and the whole book was a delight to read.
Paul Harper.
Rating:
Summary: Must reading, but too seldom read
Review: In giving testimony before Congress a few years ago on IT issues, I said the following: "Humanity has been developing information technology for half a century. That experience has taught us this unpleasant truth: virtually every information technology project above a certain size or complexity is significantly late and over budget or fails altogether; those that don't fail are often riddled with defects and difficult to enhance. Fred Brooks explored many of the root causes over twenty years ago in The Mythical Man-Month, a classic book that could be regarded as the Bible of information technology because it is universally known, often quoted, occasionally read, and rarely heeded." I have been involved in software engineering for over 25 years, have written many articles and even a few books on the subject. Yet every time I think I've discovered some new insight, chances are I can find it tucked away somewhere in The Mythical Man-Month. And the tarpits and other dangers he lays out plague the IT industry today. I wonder when we will grasp and apply the fundamental insights that Brooks, Jerry Weinberg, and others laid out nearly three decades ago. ..bruce..
Rating:
Summary: Read it every 5 years...
Review: I read this book about 1992, when I was just starting my career in software engineering. At the time, I didn't appreciate the book. I struggled through it, but frankly, didn't get much out of it because I was constantly saying to myself, "This book is ancient... what does IBM's OS/360 have to do with the world today?"
Fast forward to 2 years ago... I now had a lot more experience under my belt, and came across this book looking for material on the concept of "Conceptual Integrity" in architectural design. Now that I had the experience to 'relate' to this book, I got so much more out of it! This book isn't so much about the software part of software engineering as it is about the human element. If you are a programmer with several years of experience, or if you are a manager on a growing software project, you will get a lot out of this book.
I made a resolution to myself at that time to read this book once every 5 years... both to get new material out of it, and to provide some kind of 'reflection' on what I have seen in my career in those past 5 years.
Rating:
Summary: So much better than "Code Complete" I can't believe it.
Review: First if you are comparing "Code Complete" a book from MS which has yet to release a product that was complete, it is difficult to stop laughing.
Every new middle manager should read this book, and stop trying to ignore 50 years of experience. Oh yeah, we live in internet time, but we still can't make a project deadline, because human's haven't evolved much in the last 100 years. Yes extreme programming has its place. It's the mini team within the 7 person teams that Brooks outlines.
But its the communication issues within a project that kill bigger teams. Yes some programs and projects don't need this full scale project team. But try to write the flight control software for a modern jet, and you'd better be paying attention to the lessons in this book.
Yet managers still don't learn, go find "Programming Disasters" and see some examples of millions of dollars spent and no working project. People believe that there is some silver bullet instead of trying to work within the framework that they have. No one thinks that gravity doesn't apply to them for very long and neither will they think that communication issues don't apply once they see the disaster that unfolds. Usually though the money has been spent and the company folds/the project dies.
So pay attention! If you want "chief programmers" train them! It's not rocket science. The military trains generals and sargents with regularity, we can train our leaders if we care. To do it on the cheap well, we can see what happens when we try it.
|
