Summaries and Customer Reviews are supplied by Amazon.com

Imagine, at a terrifyingly aggressive rate, everything you regularly use is being equipped with computer technology. Think about your phone, cameras, cars-everything-being automated and programmed by people who in their rush to accept the many benefits of the silicon chip, have abdicated their responsibility to make these products easy to use. The Inmates Are Running the Asylum argues that the business executives who make the decisions to develop these products are not the ones in control of the technology used to create them. Insightful and entertaining, The Inmates Are Running the Asylum uses the author's experiences in corporate America to illustrate how talented people continuously design bad software-based products and why we need technology to work the way average people think. Somewhere out there is a happy medium that makes these types of products both user and bottom-line friendly; this book discusses why we need to quickly find that medium.

Average Customer Rating:

Appalling

Customer Rating:

I am a technical manager in the software industry. I am responsible for the SDLC, manage developers, and perform code reviews, while still occasionally contributing code - generally architecture and technical spikes. I mention this because I feel this gives me a good perspective on books like this, as I deal daily with the issues on 'both sides of the fence'. I bought this book sight unseen and without knowing who the author was because it was recommended to me as a 'timeless classic'. To be honest, I couldn't read it in it's entirety and merely skimmed it. This is without a doubt the worst book I have ever seen on this subject. I read this with a stunned disbelief at what I was reading along with a growing sense of disdain for the author. Okay, firstly the author has the most intense bias against engineers. In retrospect I realise it should have been obvious from the title (duh!). Take these examples from the Chapter 3 - Feature List Bargaining: "These feature lists allowed programmers to 'shift the blame' to management when the product failed to live up to expectations." [implies (a) blame belongs solely with the developers and (b) features lists are an evil plot of the developers. Apparently developers should read minds instead] "There are far too many features to create in the time allotted, 'they claim', and many of them will have to be cut to meet the deadline." [implies developers are deceitful] "The programmers 'draw a dividing line midway' through the list. Items above it will be implemented, they declare, while those below the "line of death" are postponed or eliminated." [implies unreasoned and arbitrary decision making by the developers] "All of the analysis and careful thinking done by high-powered and high-priced executives' is made moot by the unilateral cherry picking of a programmer following his own muse or defending his turf." [Contrasts the 'careful thinking' of the managers with the 'unilateral cherry picking' of the developer. Sneakily implies 'high priced' = 'worth it'] Whilst reading this rubbish, I was trying to imagine what reality the author lived in. A google search told me that he was some sort of 'father of VB'. Oh. Well. That explains rather a lot. I suspect that the sort of developer that the author is railing against in this book is the sort of developer that the author was previously. My 15 years of experience in the software industry (C++,Delphi,Java) has been vastly different. I would not have hired a developer like the author was then, and I would certainly not engage his services as a consultant now. The author seems to be completely mired in the past and completely out of touch with the last decade of the evolution of the industry. One good book on Agile or Lean development will impart the reader with the context to look at the perspective the author displays in this book as dangerously antiquated. This book reads like some sort of 'class-warfare' political *screed* from the managerial class to the engineering (working) class. Let me share my experience. The IT industry is full of scams and cons, primarily run by large consultancy firms. Software development is hard, and the majority of those responsible for the success of failure of IT projects do not have enough understanding of the projects to feel comfortable in taking responsibility for their success or failure. They will obviously accept the accolades of success, but in an all too human manner - look for scapegoats for failure. By turning to outside consultants pushing the latest new technology, they can always blame the consulting firm if things go wrong. The consulting firms are completely on board with this as (a) they are paid well and (b) they know that when the next new technology is ready the cycle will repeat. This is not a secret. I have sat in board meetings with these consultants who have used exactly this as a sales pitch to us. Now I don't know if the author is a 'true believer' in the idea's presented in the book or whether it is a cynical attempt to reinforce the existing prejudices of certain entrenched executives in order to secure for him more consulting work. In any case, this is the worst book I have ever read, bad enough to write my first negative review on Amazon. I'd normally recommend reading books like this to get an idea on what to avoid, but in this case I can't even recommend that, it's actually too repulsive. Avoid like the plague.

To be taken with a large grain of salt

Customer Rating:

The Inmates Are Running The Asylum starts off pretty well. It begins with some very good examples of poor design that lead to a bad user experience, as well as just how downright dysfunctional the software development process can be. There is also the beginnings of a thesis on how to solve these problems. From there however, the quality of The Inmates takes a steep nosedive. The deeper into The Inmates you go, the lower the signal-to-noise ratio becomes. Cooper's message gets buried progressively deeper under a heap of sand-kicking diatribes about software engineers, armchair quarterbacking of the designs of others, and thinly veiled plugs for Cooper's particular brand of interaction design consulting. There are some good ideas in The Inmates, though nothing truly groundbreaking at this point in time. Cooper champions things such as goal oriented design, personae, and primacy of user friendliness. All of which are good things, but none of which are exactly new concepts in 2008. However, the actual useful information comprises maybe 75 pages of the 250ish pages in the book, and is reduced to little more than nuggets of useful information scattered throughout a sea of whining and self aggrandizement. Cooper's armchair quarterbacking of certain technologies as 'dancing bearware' is particularly annoying. Cooper continually brings up example after example of software and technology that is breaking new ground, acknowledges the fact that the technology even exists as an amazing achievement, and then turns around and lambasts it for not magically coming equipped with the precise amount of polish and feature sets that he wants. The 20/20 hindsight through which Cooper views many technologies belies the fact that Cooper is just as blinkered when it comes to the 'big picture' issues of software engineering as the managers and programmers that he continually needles. Cooper tries to keep the tone light, and his unique brand of humor kept me reading even as the tone of the book slid gradually into that of a polemic against all things Alan Cooper doesn't like. This book can be downright dangerous if taken as holy writ. Cooper continually takes shots at programmers, and in fact spends an entire chapter reducing them to a set of stereotypes and providing an 'animal handling' guide for the backwards, egotistical, smelly bullies otherwise known as 'programmers'. Taking Cooper's stereotypes to heart is pretty much guaranteed to cause rifts between design and engineering teams, as Cooper goes to great length to explain exactly how far beneath contempt programmers are, how they are not to be trusted, etc. The Inmates espouses a philosophy of design in which non-designer stakeholders are to be marginalized or even totally cut out of the design process. The concepts of business or technical needs influencing design are constantly sidelined, as business and technical concerns are never legitimate, but rather the result of inept managers or lazy programmers. This book should be subtitled 'How to have your design, business, and engineering teams at each others' throats in 3 easy steps'. Overall I think that the book has some useful information, but much like Cooper does with his case studies, the reader must cherry-pick it to obtain any useful information. Coopers ideas are good (if dated), but they could have been presented in a far more concise fasion, and could have done without the extra 175 pages of masturbatory ego stroking, ranting, and poorly disguised plugs for his consulting firm.

A Must Read Classic, Albeit with Some Dated Ideas

Customer Rating:

This a classic book that anyone who build computer systems should read. Some of the specific examples are dated, though many caused me to nod in acknowledgment, especially his observations about alarm clocks and TV remotes, Inmates describes goal directed design, the concept of Pesonas, ideas which, whether they make sense for your project are not, are ones that you should be aware of. This book also explains what "polite software" is and emphasizes the market advantages to good interaction design. Even if this book doesn't change the way you work, it will help you think about the relationship between interaction design and programming. Among the interesting points Cooper makes are Customer Driven isn't aways the best model (customer influenced is better), and neither is Engineering Driven; software designers should go beyond customers say they want and help them to understand what they need. There were a few things towards the end of the book that struck me as just wrong. For example Cooper says that most developers don't believe that they are the best people to test their code. Most Agile software developers would challenge that point. Agile developers would also challenge the recurring theme that the engineering team can't make the leap to understanding the customer enough to build good interaction design. He ignores the value of a specializing generalist, which is an important concept in today's projects. It's for these points that I gave this 4 rather than 5 stars. Regardless, this is a book that anyone building software systems should read, if only to understand the concepts underlying interaction design.

No Cognitive Friction Here..

Customer Rating:

Alan Cooper gives the reader insight into why so many of today's technological products frustrate and confuse users. Yet he goes past this to discuss a methodology for keeping it simple and designing for the user i.e. avoiding cognitive friction. This book has changed the way I will develop products and should be a must read for product managers of application developers. Just learning Mr. Cooper's vocabulary is worth the read. The ideas such as personas, keywords, and designing for an individual push the book way above average. This is an easy read that should be done in your spare time if you want to avoid cognitive friction with your users. It has changed the way I view technology and brought a new awareness to thoughtless technology implementation which often cause failure or misuse. The only reason I gave this book a 4 out of 5 as I feel it could have been reduced a little bit more, certain points I felt like the author was rambling about personal fustrations.

an essential handbook for designing software

Customer Rating:

Cooper's argument in this book is simple: you have to know your users, and you have to understand what they're trying to accomplish with your software. The method that he puts forth for achieving this understanding is personas, richly-described archetypical users. The book is easy to read and understand. He begins with a detailed description of the problem with software design as carried about by programmers who can only imagine themselves as the users of their software, resulting in software that makes really difficult things possible but doesn't bother to make easy or common things quick and easy. After making the argument that programmers shouldn't design interfaces and making the case both for usability and interaction design, he lays out the personas concept. Cooper's guidelines for creating personas and using them are well-written and well-thought-out. However, his examples of applying them to some of his own customers are rather repetitive, and sometimes come across as somewhat whiny. Now that it's time for my group at Microsoft to revisit our personas and determine what needs to be tweaked for our next version, I decided that I should revisit the book that first advanced the idea. It has stood up well to the test of time (something that not many computer books can do). I highly recommend it, both to usability and design professionals, as well as programmers.