Learn more Shop now Learn more Shop now Shop now Shop now Shop now Shop now Shop now Shop now Shop now Shop now Learn More Shop now Learn more Click Here Shop Kindle New Album - Pink Shop now Shop Now

Showing 1-10 of 22 reviews(5 star). See all 45 reviews
on 23 March 1999
I am the silicon valley chapter president of the Association for Software Design and World Wide Institute of Software Architects, and I'm always on the look out for really good books on what design is. Most books miss the boat entirely.
I had the pleasure to read the galleys before the book went to the publisher. As always, Alan has a very engaging and provocative writing style.
A lot of people confuse Design with programming. This is like confusing Architecture with construction engineering. But really they are very different, even in a legal context, for the design and architecture about fitness to purpose, and programming and construction are about appropriate implementation a design. It's easy to construct a house without an architectural design, but it can be very frustrating to move around and use the space. You can also program software without design, and the result is "software that needs to be spanked", as Alan says.
What is really great about this book is that Alan shows what software design is, in contrast to programming, and shows that while it is not an engineering science, it isn't touchy feely mumbo jumbo either. In the later chapters he talks about an actual methodology he uses in his company to do design, and these techniques can and should be widely copied.
You'll learn a lot from this book: you'll know what software design really is, AND how to do it. And unless you are a programmer with a fragile ego, you'll split your sides with laughter as well.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 23 August 1999
You might be familiar with Cooper's previous, and fairly influential, book "About Face: The Essentials of User Interface Design." Cooper is also known as "The Father of Visual Basic" for his work on the original version of Visual Basic for Microsoft.
This latest book goes way beyond the nuts-and-bolts concerns of Cooper's "About Face" book--in fact, it's not really a nuts-and-bolts book at all. Programmers are not the target audience. Rather, "The Inmates Are Running the Asylum" is about the insanity that results from the lack of a proper design process, run by trained professionals, in the software life cycle. That brief description really does not do the book justice, though. This is a manifesto, a call to change for the whole industry. I predict (or perhaps "hope" would be a better word) that in ten years, this book will be viewed as a major milestone for the software industry, on par with Frederick Brooks's "The Mythical Man Month", Codd's relational theory papers, Constantine and Yourdon's "Structured Design", DeMarco's "Peopleware", and McConnell's "Code Complete." I know I'm going out on a limb with a statement like that, but I think this an important book.
I highly recommend this book. It's an easy read, not a technical book. Just to temper some of my hyperbole, this is by no means a perfect book, and many will disagree with Cooper's assessment of and approach to the problems at hand. I certainly have had my disagreements with Cooper in the past. But this book, in my opinion, is generally right on. Even if you don't agree, you won't be able to ignore the floodgates that I hope it opens. Check it out.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
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.
0Comment| 5 people found this helpful. Was this review helpful to you?YesNoReport abuse
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 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
on 7 May 1999
I used to like computers--then I got a job where I was actually expected to get some work done. Every time we upgrade something on our system, I have come to dread the occasion because I know that my work will somehow be irreparably messed up. There was even one occasion where I actually discarded the upgrade and went back to the old version of the software. There is no question in my mind that the way software is designed today really needs to be changed. There is too much software out there that is built as if a third grade kid was designing a swiss army knife--it may have a lot of cool stuff on it, but you end up cutting yourself every time you try to use it.
I thoroughly enjoyed reading this excellent book. It's well worth the money.
0Comment|Was this review helpful to you?YesNoReport abuse
on 16 October 2009
Developing software and solutions myself for more than 20 years this book certainly woke me up and gave me the insight and explanation on why so many users fail using the software and solutions we created over the time. We developers are so focused on technology and so much computer experts that we think everybody think and act as we do. I you want to create solutions that really work for the users read this book and continue with About Face 3: The Essentials of Interaction Design to get the details. Then, to get hands on, use the book:Designing for the Digital Age: How to Create Human-centered Products and Services, to implement the methods into your development process.
0Comment|Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)