Customer Reviews
Important lessons for software engineers - By: James Christie, 21 Feb 2007 
This is a highly readable & entertaining rant directed against the inadequate development practices of software engineers over the years.
I am one of the geeks that Cooper targets, but I think I'm sufficiently self aware to know that his point is entirely justified. Building workable, usable applications on time & on budget is a fiendishly difficult problem. Pretty well all of the effortin improving our working practices has focussed on getting our job done more efficiently & predictably so that customers get their applicationsin reasonable time & at a reasonable cost. We've always been pretty clueless about the human side, making sure that the applications can be used easily & efficiently. That, of course, has great practical & financial consequences, but the cost is often hidden from the developers who have moved on to screw up elsewhere.
Cooper sometimes overdoes his argument, & minimises the real, practical problems involvedin applying his techniques. His insistence on calling all developers as "programmers" is a bit irritating, but I can accept that as a stylistic quirk rather than evidence of ignorance of software engineering.
I'd strongly recommend this to software developers who are starting to have doubts about whether they're really delivering what users need. Of course, the ones who have no doubts are the ones who really need to read this book, but I suspect they wouldn't even pick it up, & they's throw it aside after the first few pages if they did give it a go. Pity.
Excellent information aggressively presented - By: Mr. Wayne Pascoe, 22 Oct 2005 
This book provides a wealth of knowledge if you can stick with it through the generalisations & attacks on the group of people who need this book the most.
Something Mr Cooper talks about is people not knowing their customers, but falls into this trap himself. While the book may have been written with managers & project leadersin mind, many developers will read it as a means of improving themselves.
With thisin mind, writing a book that often hints at poor interface design being a deliberate attack on users, &in some places implies that software is hard to use because programmers are getting back at people because they were picked onin high school might be a little silly. This kind of hyperbole is not helpfulin getting the message across, & will not help business people further understand their staff.
Helping business people understand that different people have different skills & getting the right person for the job will deliver better results than forcing someone to do a job they are not suited for would have been a better result. As it is, I can see how some PHBs would come away from this book believing that they produce bad software because their developers hate them, rather than because they have poor processes & do not invest enough time & moneyin the right places.
A must read for all people involven in software development. - By: , 28 Apr 2005 
The book addresses many areas of why the culture that existsin IT & firms that deal with IT is not working & why many IT projects go wrong. He points out that this is not due to lack of design, but because design is not donein the proper way. He talks about the roles of everyone (managers, programmers, designers, users, etc.) during the design & what things are been done wrong. He goes into depth why programmers are the least suitable people to do the design & how they can not "think as users". The good thing about this book is that it also gives many advices & ways on how to do things the right way. Thus, he does not only identify the problem areas, but he goes on & suggest solutions & ways to improve.
This book is a very good reading for everyone who is involvedin the ANY partin the software development phase. I strongly recommend that people take some time to read it, or just browse through some areas of it. The book is splitin two major parts:
The first part (Chapters 1-8) shows why there is more of a cultural problem than a technical problem on the way that software is developed. It is a good background reading to understand the rest of the book.
The second half (Chapters 9-14) suggest ways to improve the bad culture & create software that is actually helping & not embarrassing the users. This is the part is the main core of the book & needs reading. It can be understood more deeply once the first part has been read, but this part can be read on its own as well.
Please, first READ and then review... - By: , 07 May 2004 I've read this book & really felt that I had to respond to some of Ben Carey's & Matt Vane's comments (backin 2002 I think).
About the engineering arrives rather than invents: Just because there are/were certain (as you said) geniuses amongst us [engineers], this doesn't mean that the rest of us can be brushed by the same brush!
About the UML actors comment: If someone who read the book still believes that a use-case actor is the same as a persona then he rightfully gave the book a 1 star rating...
Also the attack on the results of the "Coopers Business Case" is rather lame...
The fact that Logitech got out of the scanners market can be attributed to any important factor (related to sales & marketing). For the other two products, the fact that their owners were replaced could mean that the vision was replaced as well.
Cooper's techniques, which were used while working with the above products were excellent & should have made their point clear.
To suggest (after reading the book) that use of those techniques didn't deliver while additionally resultedin the company's/product's downfall is rather (excuse my language) stupid!
I can save you some time here.. - By: C. NEWPORT, 02 Feb 2004 Skim parts I-III it's a diatribe on what's wrong.
Read Part IV several times & take notes as it gives solutions to the identified problems & is actually really good.
Skim the rest...
For a man promoting that less is more he could do with applying his own advice to the new edition of this book...
