Learn more Shop now Learn more Shop now Shop now Shop now Shop now Shop now Learn More Shop now Learn more Click Here Shop Kindle Learn More Shop now Shop Women's Shop Men's

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.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
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.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 22 April 2003
I found the book useful. Not because I agree with everything (I don't), but because it provides a useful tool to understand decision making in IT organizations.
He writes a lot about design, but the issue usually boils down to management and how it fails in IT-organizations. Those who reads this as just a receipe for how to designing software fails to grasp the point.
Yes, I agree that he beats his own drum a lot. However he still delivers the goods in an entertaining way.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 30 April 1999
Those who have read Alan Cooper's _About Face_ know that he writes a readable, well-organized book, and his latest follows that model. In it, he advocates a very different approach to developing software than is currently widely in use. He likens the process he advocates to that used for making motion pictures. In both cases, the production portion (location shooting for movies; coding for software) is extremely expensive and done by specialists. In both cases significant time (about 5 times the production time) is spent on post-production activities (editing, scoring, advertising, distribution, etc. for movies; functionality, performance, and usability testing, user documentation, support strategies, training for software). However, in pre-production (scriptwriting, storyboarding, location selection, casting, etc. for movies; interaction design, audience analysis, environment analysis, etc. for software) there is a huge difference.
A movie may spend two years in pre-production for a film that takes six weeks to shoot and six months in post-production. Software development efforts typically spend extremely little time designing, and begin coding early in the process. Cooper suggests that having a thoroughly-researched and completely documented design saves a lot of expensive production time and resource because the coders are focussed on what needs to be done and has been agreed to and don't need to guess or assume anything.
If I had to find a shortcoming of this book, and it's a minor one, I would have liked to have seen more specifics on the techniques he describes as being successful in the Interaction Design process.
0Comment| 2 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 14 May 1999
Alan Cooper begins the book by accurately defining the software and application development model that pervades industry today. This lucid and insightful analysis is worth the two stars this book earned. However, as the book progresses it never fulfills even a smidgen of the promise we are lured into believing will materialize for us, should we choose to read the entire treatise. A tight concise target is identified early in the book and then this gem of an idea unravels into a slurry of whimpering diatribes that provide no useful information whatsoever. This book is fraught with good intentions and chalk full of pure "crap".
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 20 February 2007
This is a highly readable and 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 and on budget is a fiendishly difficult problem. Pretty well all of the effort in improving our working practices has focussed on getting our job done more efficiently and predictably so that customers get their applications in reasonable time and at a reasonable cost. We've always been pretty clueless about the human side, making sure that the applications can be used easily and efficiently. That, of course, has great practical and financial consequences, but the cost is often hidden from the developers who have moved on to screw up elsewhere.

Cooper sometimes overdoes his argument, and minimises the real, practical problems involved in 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, and they's throw it aside after the first few pages if they did give it a go. Pity.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 27 April 1999
Bells and whistles have become an addiction for software developers, and it's high time someone finally turned a spotlight on this aspect of software "development" that has crippled many an otherwise good program.
QuickBooks was once a nice little bookkeeping program for small businesses. We used it for years, loved it, then upgraded to version 5.0. Unfortunately our old version was out the window before we discovered what a colossal mistake we'd made.
First, there's the "User's Guide": almost a thousand pages! A manual of such bulk is a tipoff that a program is too complex for most mortals (assuming the text was reasonably to the point).
Second, the addition of a multitude of new (and useless, for us) functions so cluttered the functionality of QuickBooks that we couldn't fathom how to use the functions that were once a breeze. We never did figure out how to customize the "new and improved" invoice template to accommodate our use.
Third: "Features" would jump up and stand defiantly in our way. When trying to prepare invoices using the barely acceptable template we'd be interrupted with an error message that said we didn't have the item in stock -- we didn't want to use QuickBooks for inventory control, but no, QuickBooks insisted.
After trying to beat some use out of QuickBooks we unloaded it and tossed it out. Now we use the invoice template that comes with MS Excel (INVOICE.XLT)and it works just fine. Intuit actually did us a favor by exercising their compulsion to ruin a simple program; they forced us to discover that a totally functional little invoice template, one infinitely customizable, was on our computer all the time. (Of course, the discovery made us ask ourselves why we weren't heads-up enough to simply design our own invoice using Excel in the first place!) It's easy to get carried away searching for special-use utilities instead of using the tools already right at hand to create our own -- free.
Grammatik is another disaster. Once I considered it indispensable and proofed all my books on it to get the reading level down and identify potential improvements in style. But the folks at Grammatik couldn't leave it alone. New and useless features were added which only bogged down the process of using it. A speller was included(as if we didn't have spell-checking features in WordPerfect and Word!), and if there was a way to disable Grammatik's spell check I never found it. And what a sorry spell checker it was -- wouldn't allow you to add words to its inadequate vocabulary, wouldn't allow you to ignore all occurrences of words it didn't like, so it stopped on every usage of them.
Where I once used Grammatik on entire books of, say, 200,000 words, the new "improved" version would drive me mad trying to get through a 5,000 word chapter. Out it went.
I considered Norton Utilities indespensable for a decade. Now it's not loaded on a single machine here because it pokes its nose into too many places where it has no business, slinging DLLs around in reckless profusion, causing problems and lockups, not to mention its insatiable appetite for computer resources.
If Microsoft can't deliver a Windows version without bugs, how can increasingly "function-rich" programs written by third parties work under Windows without causing conflicts? They can't, and they don't.
Cooper is on the mark: The inmates are running the asylum, and they don't care what us mere users have to endure to accommodate their passions for excess.
It was Mark Twain -- wasn't it? -- who apologized to a friend for writing such a long letter by explaining, "I didn't have time to write a short one." Brevity is hard work.
We've solved many problems here by brutally pruning the utilities on our machines, then formatting hard drives to clear out all the DLLs and other files that have been left behind. A typical gain in available hard-drive space is about a third after a format and complete reload of programs and data files.
Unfortunately, there are too many computer users who "think" they want bigger and better programs even if they never discover how to use more than their most basic features. Also, the computer press fawns over "feature rich" programs -- the journalists review them, but aren't saddled with using them every day. So vendors keep bloating bloating programs and raising the prices.
I've hoped in vain that some enterprising software writers would follow along behind the big boys and create iterations of the simple, functional and easy-to-use utilities they've discarded.
Maybe Cooper will inspire some to do just that.
Doug Briggs
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 9 March 2010
Weighs in against the shoddy software designed and written by geeks/geek-wannabees - and the acceptance of this by everyone else. The author urges that software can be made fundamentally better. He gives examples of bad designs, problems caused, and obvious (when we are told them) solutions.

Its an enjoyable polemic and I heartily agreed with most of it. However there is an alternative case for good-enough software. The book does not recognise this and some of its arguments are overly perfectionist. That said, this book is a well-intentioned, fun, and positive read. We need more I.T. practitioners to raise their heads above the pulpit. Any attempt to un-knit software's problems should be welcomed.

Main points:

1. Design for an idealised user, rather than trying to be all things to all men.

2. Design so as not to make anyone feel stupid.

3. Focus on clarity/unity of design rather than hordes of functions.

N.B. Professionals might read this followed by Cooper's About Face 3: The Essentials of Interaction Design (for the nitty gritty).

P.S. For a more pragmatic read try Don't Make Me Think!: A Common Sense Approach to Web Usability.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 22 June 1999
As a veteran of 5 technology start-ups, some successful, some failed, I wish this book had been around to read much, much earlier. Cooper's novel approach to designing for the infamous "end-user" is worth the read alone -- there's real, useful meat here that you can take action on as soon as you learn it (I know I did). And as an "end-user" myself to a myriad of technology (aren't we all), the book opened my eyes to how our everyday encounters can be improved (most recent example: did you ever notice how the LCD-readout prices for gasoline at credit-card pumps disappear at the very moment you actually might want to look at them--right after you've inserted your card and are really ready to make a choice?). Don't be dissuaded from reading this seminal book by the "religious wars" being raised in these other reviews I've read above--that's all inside political turf war about "who's to blame". Doesn't matter: the point is, how can we fix this stuff? Cooper's got the answer, no fooling. *****+ - Must Read.
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse
on 25 July 1999
As a shallow user (both Macs and PCs), I am continually frustrated and angered by the rudeness and obfusation of computers. We need Alan's message!!! The issue of who is to blame is a red herring. He SAYS that programmers are to blame, but then DESCRIBES a situation in which both programmers and managers (and the system) are responsible. The anecdotes are fun and to the point, and his writing style is lively and informal. The book should be carefully read by everyone in the industry. Unfortunately, I know from personal experience that the ones who need it most are resistant -- "I don't have time". Maybe when some programs get easy to use, all the difficult ones will die....I wish. Submitted by Kim Cooper
0Comment| One person found this helpful. Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)