|
The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition (平装)
by Frederick P. Brooks
| Category:
Software development, Programming, IT, Technology |
| Market price: ¥ 388.00
MSL price:
¥ 378.00
[ Shop incentives ]
|
| Stock:
Pre-order item, lead time 3-7 weeks upon payment [ COD term does not apply to pre-order items ] |
MSL rating:
 Good for Gifts |
| MSL Pointer Review:
Focusing on the human elements of software engineering, this classic offers insight for anyone managing complex development projects. |
| If you want us to help you with the right titles you're looking for, or to make reading recommendations based on your needs, please contact our consultants. |
|
| |
AllReviews |
1 2   | Total 2 pages 12 items |
|
|
Theon (MSL quote), USA
<2007-01-10 00:00>
If you think it would be outdated it must be because you have not worked long in the business of software engineering. It is not about languages or tools, its about managing people. As much as we like to think we can automate the eccentricities and flaws of people away, we never will. Software engineering is a process done by people - not machines and milestones on paper. In order to succeed the key is not avoiding mistakes; mistakes are inevitable. No, the secret to success is not the process but the people who use the process. Having the tools and understanding to not just handle setbacks of human error but to flourish in them, that is the secret to success. That is what this book tries to convey. Too few seem to get the message. |
|
|
Mark (MSL quote), USA
<2007-01-10 00:00>
This is truly a must read. Many have said that this book is quite out date, and I don't outright deny that charge. However, it is still very relevant and helpful. I found at least half of the chapters to be very sharply applicable to today's software engineer. If you have any involvement on any organized software project, please do yourself a favour and get this book! |
|
|
Moshe Reuveni (MSL quote), Australia
<2007-01-10 00:00>
I cannot think up any other book that would come close to being as effective as this one when it comes to solid, down to earth advice on the management of software projects.
Direct and to the point in its presentation, and built on actual experience gathered during years of work, the book lays down its insight in an extremely effective and efficient manner, making for both an interesting and an effective read. Quantity wise, the book addresses many issues surrounding the world of software project management, issues that usually take several books for others to explore.
Although the book is old, with references to old technologies that serve best as comic relief nowadays, it is quite amazing to see how true and how valid the insights gathered by the author are today. My own experience and discussions I have had with colleagues from reputable Fortune 100 companies helped me realize how relevant the book still is: Decades after it was written, project managers everywhere still approach software projects with attitudes that would never be accepted elsewhere and are still attempting to cut corners they should not cut. They all end up paying the price, just as the book predicts.
The bottom line is that this book is a true classic: Extremely effective, concise, readable, entertaining - and one that withstands the test of time. |
|
|
Soren Meyer (MSL quote), Germany
<2007-01-10 00:00>
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. |
|
|
Harvey Sugar (MSL quote), USA
<2007-01-10 00:00>
This was one of the first software engineering books I ever purchased (Not the 20th Anniversary Edition). It is still one of my favorite software books and I re-read it every year or so. Some of Brooks' solutions to common problems are showing their age but the issues he raises are timeless. Some of my favorite chapters are:
The Tar Pit - every project I have ever worked on has been a Tar Pit at some point, even the best ones. Brooks shows why this happens.
The Mythical Man-Month - the source of the quote "The bearing a child takes nine months, no matter how many women are assigned." and the observation that adding more programmers to a project can actually delay its completion. The sources of scheduling woes were identified by Brooks long ago but we still live with them.
The Second System Effect - it amazes me how many times I've seen this happen and still don't realize it until it's almost too late. I need to read this chapter more often.
Why Did the Tower of Babel Fail? It's all about communication.
The wisdom in this book has become so ingrained in our industry that people quote it without even realizing it.. Brooks is a great writer and makes this an easy read. You could read this book in a couple of days but work a life-time to appreciate its value. |
|
|
Gary Powell (MSL quote), USA
<2007-01-10 00:00>
First if you are comparing Code Complete, a book from Microsoft Press 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 communica- tion 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.
|
|
|
Charles Ashbacher (MSL quote), USA
<2007-01-10 00:00>
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. |
|
|
Vincent Poirier (MSL quote), Japan
<2007-01-10 00:00>
This classic on software engineering made its mark as a study of how to manage large complex projects. Most of the book applies to management in general rather than to software engineering in particular.
Here are two examples of the more general insights the author, former IBM manager Frederick P. Brooks, gives readers: an instance of a straightforward insight immediately applicable, and another one we obtain by carefully (!) reading the text.
Brooks looks at different types of projects; large projects that can be split into many simple independent tasks will be completed faster if we add more staff to carry them out. However, engineering projects are seldom so simple. Developing software for a new machine requires the machine, which is itself being developed, as well as documentation, which is being prepared! All these tasks relate to each other and require all participants to communicate with each other. The number of communication lines within a team grows exponentially with respect to the number of team members. At some point, adding more men and women actually delays project completion, shattering the myth of the man-month.
However we must be careful as we read the Mythical Man Month. This book was written in the seventies about the author's experiences in the sixties, so to understand Brooks correctly, we've got to read him carefully. For instance, Brooks praises PERT charts, saying outright that "there is no substitute" for them. I can't believe this is a blanket endorsement for mindlessly turning out slides and charts by using Microsoft Project! Brooks didn't have MS Project or PowerPoint in the sixties: PERT charts were carefully drawn, often by hand, they were expensive, and they were prepared after thinking things through. We find the true insight a little further down page 156: "The preparation of a PERT chart is the most valuable part of its use".
Some of the book is of course more relevant to software engineering. For instance, Brooks's correct 1986 prediction that off-the-shelf, shrink- wrapped software would become the standard way to implement solutions. Just look at Microsoft Office or at SAP's R/3 to see the truth of this. (I'd even say that because powerful software is now so cheap, we've created a glut of output.)
Read properly, The Mythical Man-Month remains as insightful today as in the seventies and eighties. Brooks's style is friendly but professional and business like. Budding project managers will find many useful insights. |
|
|
Erik Gfesser (MSL quote), USA
<2007-01-10 00:00>
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 Small talk. 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. |
|
|
Nicodemus Chan (MSL quote), Singapore
<2007-01-10 00:00>
The Mythical Man-Month is a great read especially for those managing computer software projects.
This should be given to all software developers and managers to understand the pitfalls in software development.
I read with a chuckle when it said that terminal optimism is an occupational hazard. "Coding is 90% finished for half of the total coding time. Debugging is 99% complete most of the time.
The man month is only devoted to in the first couple of chapters, instead the rest of the book deals with team communication methods like a project workbook. Brooks tells of using something that provides versioning and a change log for referral, something that a Wiki now does excellently. This shows the foresight of Brooks management ability.
It's all about management really and communication and structures of authority.
Things like elements of power are also addresssed and he mentions that great designers and technical people should be rewarded just as equally by providing an alternative career path rather than the management path. Imagine that David Beckham was told the only way for him to further his career was by becoming the manager! Tosh! People should be rewarded and their best skill honed if such their skill really is valuable.
When the best programmers are not rewarded, we are losing a major part of the country's great software development talent to making mostly mediocre managers. I believe that it really takes 5 years for a programmer to really understand software development and at that point that talent is lost if it isn't rewarded. Managers we have plenty. Great programmers no.
I loved his Biblical references and there was an 'a-ha' moment when he said why organizational trees are trees because no man can serve more than one master.
I also gained great insight when he mentioned that there is no silver bullet by likening developing code like maintaining a clean room. Bugs are inevitable. So are germs. It is through maintaining steadfast cleanliness that we keep the effects of bugs and germs away.
There is much more that I could write but I would want you to read the book.
|
|
|
|
1 2 | Total 2 pages 12 items |
|
|
|
|
|
|
