3 of 3 people found the following review helpful
on 23 March 2013
I will confess, it is some years since I read this book, so my appraisal will be vague, perhaps completely irrelevant and really just an excuse for me to rant about my current job. However, this book did leave an impression on me and, as a UI Designer/Developer, it did express the frustration that I felt in my experience of the software development process and explained why so often it produced bad products.
I make a distinction between front-end and back-end developers. There are some that do both very well, but on the whole I see people specialising. The two camps are often identified by different mental attitudes and perspectives, not just about software, but about people and the world. Front-end people tend to be more in tune with the physical and emotional experience of using software; they enjoy visuals, sound, style and art, have technical expertise, but enjoy it for the experience it creates. Back-end people tend to be more into the engineering, generally have deeper technical expertise and concentrate on functionality and performance. Obviously these are very loose definitions, but they are complimentary when there is mutual respect.
I'm sure that we have all seen examples on software forums of one poster presenting a problem with code examples and another more experienced poster not only posting a solution, but with a fraction of the code. One can't help but admire this kind of elegance and efficiency; the kind of mind and the depth of understanding that can distil and optimise down to only the absolute essentials, but also allow for extension.
Not wanting to perpetuate the image of back-end developers, who are into Dungeons and Dragons and obscure and clever humour, but this kind of mind is mathematical, highly focused, perhaps a little binary and not a little irritated at perceived human irrationality. This kind of mind is also aware and rather proud of the fact that it can perform mental feats that many cannot and that if one can master a fully fledged programming language then other seemingly much simpler tasks (HTML, CSS and graphics) appear a doddle.
On many occasions, back-end developers have approached me and referred to my front-end work as "colouring in", "prettying it up", or "the icing", or referred to disciplines such as User Experience as "just common sense". They don't believe that concepts such as inheritance, scope, re-usability, extensibility etc. exist in the front-end disciplines, they imagine it all to be about whim and preference. As a result of this misconception, they rather resent the attention that front-end developers get from clients and users concerning the UI when to them the real genius is in the back-end functionality.
Development roles require a certain focus and the human mind is not very good at focussing in multiple directions. Hence front-end/UI developers are more focussed on the UI and the experience of the user; they are more aware of what is referred to as the Visceral Reaction, which evaluates on an emotional/physical level way before any intellectual consideration. Task flow, proportions, visual consistency, complimentary palettes, Accessibility, UI patterns are just a portion of what UI Designer/Developers consider; when back-end developers understand and support these processes you get great products.
What I remember about "The Inmates are Running the Asylum" was the emphasis on the requirements and design stage for the user's benefit and not the technology's. Too often the architecture of a particular language, framework, database, or CMS is used by back-end developers to brow beat others into pursuing design decisions that are more about the back-end developers' convenience than about the best design for the user and their tasks. Coupled with a complete lack of empathy for users, who may seldom use their computers and even then only for the most rudimentary tasks, the end result is invariably an unprofessional and visually inconsistent product, devoid of joy in its appearance and use.
"The Inmates are Running the Asylum" did describe my experience of the nonsensical and non-empirical decisions for one feature to be dropped in favour of another and for crucial bugs to remain unfixed. I say nonsensical and non-empirical because they were not based upon client or user requirements or evidence, but these decisions made perfect sense to back-end developers because they were all about what was important to them. A common back-end developer response to a user's inability to understand or perform a task on their software is to either curse their stupidity, or suggest the creation of documentation; the idea of an intuitive and self-explaining interface is not generally considered, nor do they recognise their major part in preventing it's creation.
3 of 3 people found the following review helpful
on 16 June 1999
I am a senior IT specialist with over 27 years in the field and was looking forward to reading Mr. Cooper's book until I read the reviews and noted his emphasis on technical personnel as the primary catalysts for poor software.
They may be a factor but not the primary catalyst. Unfortunately, it is and has always been corporate management that have initiated much of the problems we are all facing today. Computers in the hands of the individual or the scientist can offer a tremendous enhancement to their work and lives in an increasingly difficult and complex world. However, in the hands of business management and/or under their aspices the computer has become a plaything for fools who rampantly execute decisions against their technical communities based more on fantasy and personal agenda than that of reality and common sense. And since it is the business realm that produces much of what the consumer uses the results tend to be less than stellar.
Most fail to remember that technicians have very little say in the finality of their projects that are usually run by an organizational stream of management. This is not to say that there aren't plenty of bad technicians who are as equally guilty of incompetence and the infusion of their own personal agendas into a project. There are more than enough. Yet management has consistently failed to understand in depth the technologies they are having implemented which would then allow them to develop quality teams with a balanced forum for input from both sides. Instead, management prefers the "glory" of the technical implementation with the attitude that they they "don't understand this stuff". And how can they when most technicians themselves are having a difficult time keeping up with the high-speed evolutionary pace of their own technology.
If Mr. Cooper had more experience in the everyday development environments that most have to contend with I believe his book would have had a much more balanced emphasis and thus a superior impact on the reading public which is what is really needed. Changing the way software works will not alter the stupidity behind it!
13 of 14 people found the following review helpful
on 24 May 1999
The manner in which Alan Cooper points out problems with many high tech products is thoughtful and insightful. The book contains many descriptive examples and entertaining anectodes to illustrate the problem of "dancing bearware". His case for the necessity of "interaction design" is convincing. Overally the book is thought provoking and educational. So why only three stars?
His accusation of engineers being the root cause of the problem is badly misguided, with a silly generalization of programmers as a whole. I develop software professionally for a living, and I certainly do not consider myself or my peers "techno-jocks". I do not look down upon end users any more than I would expect an M.D. to look down upon me for lack of knowlege about medicine. In the organizations I have worked in, I have seen that developers have the task of interaction design UNWILLINGLY thrust upon them due to miserable product specifications coming from sales and management. I have also seen useless gadget features come from sales and management more often than from engineers. From my experience, these things alongside unreasonable project plans and "we can fix it later" attitude on the part of managers have resulted in awkward products many customers dislike.
Also, the book was too self-referential. In some portions, it appeared that the author was advertising his own company.
It's a shame the "inmates running the asylum" theme and self-advertisements were over-emphasized. Aside from these things, this is a good read for both high-tech managers and engineers.
43 of 50 people found the following review helpful
on 12 September 2002
The most fundamental and consistent error throughout the book is the idea that usability, failure to meet requirements and lack of an adequate design phase are new phenomena, as consequences of this era's computer technology alone.
This simply isn't true. If it were books like "design for the real world" written by Papanek over 30 years ago would have been unnecessary, Three mile island wouldn't have happened, and no one would ever misdial a telephone.
Sadly Cooper does not present proper evidence for a 'new' problem, preferring an informal and anecdotal style and, in doing so, extrapolating his entire argument from false foundations. He also sees the need to invent a whole unnecessary set of jargon to use, with fairly woolly and subjective definitions.
There are constant inappropriate references and analogies to other forms of engineering (particularly building), their methods and traditions.
"In the industrial age, engineers were able to solve each new problem ... they made bridges, cars, skyscrapers, and moon rockets that worked well and satisfied their human users. .... But unlike the past [computer] things haven't worked so well. "
Is he implying there were no problems before? Tay bridge, Tacoma Narrows, Ford Pinto, Challenger shuttle, Soyuz-1 and Soyuz-11. All suffering from dangerous design flaws (and not isolated) and none of them had anything to do with computers.
By ignoring the reality of past and current failures in (non Software) engineering Cooper quickly leaps to the conclusion that we "... have encountered a problem qualitatively different from any they confronted in the industrial age".
Errr, no. One of the first things we learn in engineering is how much of our wisdom has come from analysing failure and disaster fully, objectively and with academic rigour.
"When engineers invent, they arrive at their solution ... [it] will always be a derivative of the old beginning solution, which is often not good enough. "
Eh? Brunel? Stephenson? Even Santiago Calatrava doesn't shy from the title 'engineer'. Even in our beloved computer field, engineers and scientists abound; John von Neumann, Berners-Lee, Wozniak and Jobs. All brilliant in their day, and derived of what exactly? Not only a questionable assertion but grossly disrespectful and immodest from someone whose claim to fame is prettying up other peoples' work. These were and are the Engineering geniuses, and Cooper clearly doesn't understand engineering enough to see the differences between invention, innovation and merely doing what the budget allows.
In terms of descriptions of what a UI needs to be to qualify as usable, Cooper totally glosses over important concepts such as context. He ignores any Cost-Benefit analysis of designing and building this "no-training, no-maintenance system", blithely asserting that achieving that software (mirage) will reap all rewards. No proof, again, let alone an attempt to prove it would even be feasible.
The problem in programming is not that programmers are ill equipped or unprepared to solve the problems (though some may be), it is that no-one is demanding it of them in a coherent fashion.
Programmers are still being pushed to add 'features' buttons, wizards, gizmos and gadgets of little purpose because marketeers know they need to be able to print it on the box, and that is needed to generate the revenue.
Some programmers have the mindset he characterises, they are hardly very influential. Lack of proper requirements gathering, design, and industry-wide experience of very late, swingeing specification changes cause the problems. Programmers aren't to blame, even anti-social ones, the marketeers aren't, or the pushy ill-informed managers, the customer isn't either, but, at the same time, we all are. What we see is the consequence of nobody really knowing what they want, still less clearly stating, but everyone wanting to stamp their influence on the end product. Nice conspiracy theory Cooper, but it is nonsensical in the real world.
All the evidence sadly refutes Coopers Business Case. Products which demonstrate brilliant consideration of their target users fail miserably to make an impact (or a profit).
Look at the few of case studies of his own consultancy work he is able to offer;
1. A piece of support software for Logitech to bundle with their page scanners. = Logitech got out of the scanner market some time ago, didn't help their sales obviously.
2. Drumbeat web authoring. Well reviewed in its industry journals but scored poorly for ease of use. Elemental Software was bought out by Macromedia, Drumbeat was discontinued shortly after.
3. His in-flight entertainment (IFE) system (Clevis, et al.) for Sony Trans Com. Bought out by a competitor, Rockwell Collins, 2 years ago. Their new IFE will now be run, in their words, "on an industry standard Microsoft windows platform", Coopers system is not their flagship at all.
Now I am not going to say I think Cooper's advise for UI design is poor, or that his design methodologies are wrong. I think he is right in most of what he asserts there. It is just all based on flawed reasoning and syllogisms, and furthermore, most of it is not ground-breaking or even new ... there are plenty of good books out there discussing usability and making recommendations which are far more realistic and thoroughly presented than Cooper's descriptions of how he runs his consultancy. And he still has to demonstrate examples of where applying those principles won't cause you to crash and burn.
Cooper is presenting arguments firmly directed at those who are outside this industry and relying on their ignorance of what goes on. He plays on Technophobia and peddles misinformation. He very cleverly characterises programmers as having something to protect and a reason to be put on the defensive by what he says, in doing so appears to be trying to pre-empt responses and criticisms from technically informed readers. This has (as can be seen from the mudslinging here) unhelpfully stifled debate on his assertions. As Cooper is clearly intelligent and experienced enough to be aware of the flaws I identified, I can only conclude he was having a wry giggle with this book.
The book's populist slant and claim to have "the solution" are very appealing to some, and almost guaranteed its success. Sadly, it contributes little of use to a known and serious set of problems.
5 of 6 people found the following review helpful
on 28 April 2005
The book addresses many areas of why the culture that exists in IT and firms that deal with IT is not working and why many IT projects go wrong. He points out that this is not due to lack of design, but because design is not done in the proper way. He talks about the roles of everyone (managers, programmers, designers, users, etc.) during the design and what things are been done wrong. He goes into depth why programmers are the least suitable people to do the design and how they can not "think as users". The good thing about this book is that it also gives many advices and ways on how to do things the right way. Thus, he does not only identify the problem areas, but he goes on and suggest solutions and ways to improve.
This book is a very good reading for everyone who is involved in the ANY part in 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 split in 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 and create software that is actually helping and not embarrassing the users. This is the part is the main core of the book and 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.
1 of 1 people found the following review helpful
on 24 June 1999
This book could be a lot more dense; there are some interesting ideas, but theses could be presented on 80 to 100 pages easily. "Interaction design" is necessary, yes, I agree. But I don't like redundancy, at least not in such amounts.
The cure that Cooper proposes for insanity-inducing high-tech products could lead to some improvements, but perhaps not more or less than usability engineering or any other structured, conceptual, mature approach.
5 of 6 people found the following review helpful
on 24 May 1999
In my experience with system design, it is rarely the engineers who add the "extraneous" features. We're a lazy bunch and like to design to spec. It's the non-technical people...the marketing department, the customer reps, who blather about the software doing this and that and the customer bites. The customer thinks they get all these great features, but when the technical folks try to explain why it's a bad idea, managment says "Just put it in, we already promised them."
Besides, who says you HAVE to upgrade?? Most people upgrade because they believe they need all the 'new features' the next version has. I'm sure you've realized that nobody is fixing bugs in these new versions...ahem..windows..ahem...
13 of 16 people found the following review helpful
on 6 December 2002
I had to force myself to finish this book. On more than one occasion I had the compulsion to shred my copy, and every other copy in existance.
I entirely agree with everything in Ben Carey's review, with a few extra points.
The new panacean methodology he proposes is nothing more than renamed UML (actors for personas, use cases for scenarios, etc). Fortunately, a short while ago you didn't need to do much more than think up some funky new names for ideas to market your product in the Silicon Valley.
Worse is the suggestions that programmers are power-hungry, obtuse individuals who like nothing better than to write software that noone can use. What would be the point in creating software that was so unservicable that noone could use it?
I think the three main reasons software ends up in the state he describes are 1) sometimes there actually are badly designed interfaces (graphically and interactively) 2) the problem is sufficiently complex and extensive that there is no easy solution or 3) conflicting or dubious requirements from users and management confuse the real requirements of the software.
Rather than try to convince the people responsible for the "dancing bearware", he immediately sets about berating them. At the same time he gives credence to every manager who couldn't work a coffee pot and wanted to blame "them" for all his woes.
Don't read it before going to bed.
4 of 5 people found the following review helpful
on 22 October 2005
This book provides a wealth of knowledge if you can stick with it through the generalisations and 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 and project leaders in mind, many developers will read it as a means of improving themselves.
With this in mind, writing a book that often hints at poor interface design being a deliberate attack on users, and in some places implies that software is hard to use because programmers are getting back at people because they were picked on in high school might be a little silly. This kind of hyperbole is not helpful in getting the message across, and will not help business people further understand their staff.
Helping business people understand that different people have different skills and 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 and do not invest enough time and money in the right places.
8 of 10 people found the following review helpful
on 2 February 2004
Skim parts I-III it's a diatribe on what's wrong.
Read Part IV several times and take notes as it gives solutions to the identified problems and 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...