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 task 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 Hertzfeld headed General Magic's development effort. These two men were the lead software engineers on the Apple Macintosh and are arguably 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 changed quite a bit in the ensuing 14 years, and their methods were no longer viable. In early 1993, I interviewed Andy Hertzfeld at General Magic's engineering headquarters 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 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 Michelle Quinn's 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. They 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 law, architecture, or medicine, 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 not truly correct. If you ask Andy Hertzfeld, 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.

Programmers have sensitive bull detectors, and all it takes to inure them to outside interference is a couple of episodes in which marketers or managers demand changes "to make the interface better" that turn out to be ineffective. Whether these changes are good or bad, they force the programmer into extra work. Each change also degrades the quality of the code because each change leaves behind inevitable splices and scars in the code. When someone declares that the program will be easier to use if all of the OK buttons are placed in the upper-right corner of each dialog box, the programmer's experience and wisdom tells him that it is just a waste of time his time. And he is correct in his fear.

After a few of these wild-goose chases, they begin to treat all outside design direction merely as advice. It's as though the builders have had to rip out too many ill-conceived walls, so now they look at the blueprints with a jaundiced eye and resolve that they won't take them too literally.

Software engineers draw diagrams on the whiteboard showing the back-end data-handling code and the front-end user-interface code as two separate boxes. But there is really no difference in the code. It's not like one wall is made of granite blocks, mortared in place by a journeyman mason, while the adjoining wall is made of wooden lumber nailed in place by carpenters and covered with Sheetrock screwed in place by union drywallers. The assignments, pointers, and function calls are all pretty much the same, whether the software is responding to a user's mouse movement or reorganizing a database deep inside the program's guts. The same programmer often writes the system internals and the user-interaction code. She uses the same language, libraries, tools, and techniques to code it. Who is to say where the dividing line is between software for computers and software for users?

Programmers are used to apportioning the programming tasks on functional lines, and it is not at all clear to them why taking one slice out of the whole program, crossing many functional boundaries, and turning it over to an outsider is a good thing. It is hard for engineers to see that the C code used to interact with a database is hugely different from the C code used to interact with a human.

My colleague Jim Gay told me the following story. It illustrates how easy it is for smart engineers to pick the problems that amuse and interest them, rather than choosing to solve the problems that really need solving.

TransPhone was a start-up company in the e-commerce arena. Our basic idea was to build a simple-to-operate consumer screen phone to enable Internet commerce. Critical to the success of our model was a simple, easy-to-use interface with which noncomputer people would be comfortable. TransPhone turned to an interaction-design firm for help in defining this interface.

Our attitude was that we had the user interface almost done, but it could use a little tweaking. However, in the very first meeting, the designers repeatedly stated that they had no idea what it was that we were actually trying to do, or who we were trying to do it for. We believed that they were trying to oversimplify a problem that was, in reality, quite complicated. The meeting ended with the designers assigning us the task of more concisely defining our objectives. We, on the other hand, were beginning to feel that the designers did not have a clue what it was we were trying to do.

We proceeded to build an improved prototype to show to prospective partners, but the TransPhone device just didn't click with our prospects. We continued to assume that it was just our demo that was not compelling enough. TransPhone ceased operations a few weeks after the second prototype was completed.

Recalling that original meeting with the interaction designers, it is now clear that they homed in on the critical problem facing us in the first few minutes of our initial meeting: What was our objective, and who were we doing it for? This question was never adequately answered. Had we addressed it at the beginning, perhaps one of two things would have happened: Either we would have come up with an answer (and with it a chance for success), or we would have been unable to come up with the answer (in which case we could have minimized our investor's losses).

The lesson in this experience is that product design is a critical part of the business cycle. Our failure to address fundamental design issues in favor of pressing forward with engineering and sales ultimately doomed our company. In hindsight, when we couldn't find prospects that truly understood what we were trying to do, we should have revisited the basic assumptions of our business. I believe that this would have most likely led to a different, and simpler, product. Instead, we added more bells and whistles that probably made our value proposition more obscure than it already was.

Just like the General Magic guys, Jim found out the hard way that cool technology and a red-hot market can't overcome the dead weight of ill-conceived code. It's not enough to bridge the gap between technology and need. Somebody needs to make humans want to cross that bridge.

Most of our technological history is an industrial one, and both the problems and the solutions that define it are on a human scale. There is friction between humans and mechanical devices, but there is also a balance between them. In the information age, as computers invade our lives, and more and more products contain a chip of silicon, we find that what lies between us humans and our devices is cognitive friction, which is something new and something that we are ill prepared to deal with. Our engineering skills are highly refined, but when we apply them to a cognitive-friction problem, they fail to solve it. Over the years, our software engineers have gotten better and more skilled, yet their track record in making software powerful and pleasurable remains about the same as it has always been.

I believe that our failure to solve the problem with engineering methods is proof that engineering methods cannot solve the problem. I'll go further and state that engineering methods are one of the root causes of the problem. Asking engineers to fix the problem is like asking the fox to solve the henhouse security problem.