Centerverse home

QTVR panoramas

about design: essays, books, etc.

I make music too

Excerpt from TIARTA*

*The Inmates Are Running The Asylum" by Alan Cooper; SAMS Publishing, 1999. ISBN #0-672-31649-8)

Excerpted from pages 88-89 (hardcover). Cooper was the creator of Visual Basic, among many other achievements.



...Computer industry guru Jerry Weinberg says, "Once you eliminate your number one problem, you promote number two."' For decades, the computer industry's number-one problem has been efficiency, Computers were - relatively speaking - small, expensive, slow, and weak. We lionized the hacker-gods who could make programs that operated as efficiently as possible so as to maximize the productivity of the expensive mainframe computer. Essentially, it was far cheaper to train people to deal with obscure-but-efficient software than it was to buy more computers. The driving inevitability of plummeting computer costs has utterly obliterated that problem. Today, it is far more expensive to pay for human costs of adapting to "efficient" software than it is to make the software conform to the expectations of the humans.

The solution is obvious: make the software serve the users. But standing in the way is the culture we've so carefully built over the last forty years that puts the hacker-gods in the driver's seat. The community of software engineers is generally willing to accept interaction design into the process, They say, "Sure, wait until we're done, and then do all the design you want." Unfortunately, design has to come before construction, so the programmer's openness to design is largely ineffectual - it's like a cement truck operator telling the carpenters they can build all the forms they want as soon as he is done pouring the concrete.

Teaching Dogs to Be Cats

As a fallback position, software engineers are always willing to learn how to design. I'm constantly asked to "teach me to design." I applaud their open-mindedness, but I despair for its effectiveness. Any software engineer good enough to call herself a professional is well steeped in that literal-deterministic-sequential way that silicon behaves. Far too steeped to have much simultaneous effectiveness in the irrational-unpredictable-emotional world of humans. I'm not saying that a programmer cannot become a designer, I'm just saying that it is nearly impossible to do either of them well while attempting both simultaneously.

Every software engineer thinks that he is different; that he is the one who can do both. This is simply not true, as the failure of General Magic showed. Bill Atkinson and Andy Herzfeld headed General Magic's development effort. These two men were the lead software engineers on the Apple Macintosh and are probably the two most talented, creative, and inventive programmers ever. Their simultaneous design-and-programming on the Macintosh was a success in 1984 (although Jef Raskin, who did no programming, contributed much of the design). However, things have changed quite a bit in the ensuing 14 years, and their methods are no longer viable. In early 1993, I interviewed Andy Herzfeld at General Magic's engineering headquarters-which was Andy's living room in Palo Alto-and he described his design/programming philosophy to me. I listened in amazement, knowing that the odds would be severely stacked against him. Who but history could second-guess an engineering talent as towering as Andy's?

There is no doubt that the product General Magic had in mind was, and still is, extremely desirable. There is no doubt that its technology was superb. There is no doubt that Marc Porat's ability to establish strategic partnerships and to make business deals was second to none. There is no doubt that the company was well sired and well funded. So what caused its demise? I offer interaction design, or a lack of it, as the smoking gun. Despite its stellar pedigree and awesome talent, General Magic's product was engineered and not designed.

The current thinking in the industry ignores this obvious deduction, as the General Magic article shows. The balance of the article seems to lay the product's failure on Porat's hubris and ego, but there's not a CEO in Silicon Valley who doesn't have hubris and ego in abundant quantities. That surely cannot be the reason for the company's failure.

Our high-tech culture is so inbred that we have little perspective on our own failures and foibles. You cannot be a successful reporter of high-technology unless you are a computer-savvy nerd - an apologist - yourself, so the reporters blame our failures on personal demons, bad luck, and acts of God.


Software programming is not a true profession, like being a lawyer, architect, or doctor, so titles in our industry are very unreliable. Several of my friends who are top-notch computer programmers call themselves "software designers," a title that is indisputably well earned but not truly correct. If you ask Andy Herzfeld, he will willingly accept the sobriquet "designer."

Many programmers believe themselves to be talented designers. In fact, this is often true, but there is a tremendous difference between designing for function and designing for humans.

Even if programmers haven't acquitted themselves well of the design task, they have at least kept many projects from unraveling completely. When a usurper approaches, they are careful not to let control get into the hands of irresponsible people. Most programmers are extremely responsible, and they often view outside consultants, marketers, and managers as flighty and incompetent.

(© 1999 by Alan Cooper)


All content herein copyright © 1995-2002 by Kai Matthews, except where I've explicitly noted items as others' work.

This page was last generated on Tuesday, 16 July, 2002 08:54:49 PM (US Eastern Time), and was
  pop!site-pwrd built w BBEditand
Made w MacOS (9 and X)