The Common Culture

The nature of war and the demands of military training are common in every country. This gives rise to the strong cultural similarity shared by soldiers everywhere, regardless of which ideology they might choose to defend. The same is true in programming shops.

The collective psychology of Homo logicus engenders a common culture of software development. The accepted way that software-based products are built is astonishingly similar, from camera company to auto company to bank to navy, which is why products as diverse as cameras, Porsches, ATMs, and Aegis cruisers all behave in a similar, recognizable, computer-like way.

One aspect of this culture is a reverence for technical skill. This reverence has the effect of elevating the importance of programming skill into areas in which it is no longer relevant, such as interaction design. Thirty years ago, when computers lived in glass houses and were used only by trained programmers, the self-referential design work of programmers was adequate and appropriate. As computers edged out into the consumer market, programmers still did the design, by historical default. Development managers ask, "Why should I pay interaction designers for what I get free from my programmers today?" This is a good question, except that the underlying assumption is incorrect. He is not getting interaction design, free or otherwise, from his programmers. Rather, the interface he gets is one designed to please only the authors: people with atypical training, personality, and aptitude.

This highlights another key point regarding the culture of software development. Although it is founded on the particular nature of programmers, it is propagated by their managers, many of whom it must be said are former programmers. Jeff Bezos says that the most vociferous defense of the two-click interface came from the product manager!

The reverence for technical skill has another effect. Most people assume that programming is more technical than design. I won't dispute that, but I strongly disagree with the conclusion typically drawn from it that programming should therefore come before design in the development process. This has the effect of making the user conform to the technology. If the interaction design came before the programming, the technology would conform to the user's goals instead. I have heard high-tech executives say, "We'll bring designers in after the programmers build the functionality." This has the effect of making moot most of the interaction designer's opportunities to contribute.

Programming Culture at Microsoft

It is hard to overestimate the depth and power of the software-development culture. Fred Moody's 1995 book about Microsoft, I Sing the Body Electronic,^[1] gives an indication of how deeply entrenched the nerd culture is through an examination of this most archetypal software-development shop. The journeyman author and computer-industry-beat reporter spent a year inside Microsoft, observing the creation of a new multimedia product that came to be called Explorapedia. Moody was given unfettered access to Microsoft, and his book paints a revealing portrait of life and culture inside the industry-leading company. As you can tell from its products, Microsoft reveres programming, but has little or no awareness of interaction design. The book provides a fascinating study of what happens in a programming culture.

^[1] Fred Moody, I Sing the Body Electronic, 1995, Viking, New York, New York, ISBN 0-670-84875-1.

In his introduction, Moody sets the stage:

The Microsoft approach to corporate organization is to form small teams around specific products and leave them alone to organize and work as they wish. It is a risky approach, for these crews are left unsupervised to a degree unthinkable in standard American corporations.

Microsoft is famous for hiring extremely bright, highly aggressive, young people right out of school. Moody says, "I felt like I was watching a gang of adolescents who had sneaked into some corporate headquarters after hours, taken over its boardrooms, and were playing at being businesspeople." Microsoft is also famous for pushing these youngsters very hard to get the most and best out of them. Moody says, "The atmosphere on the campus is one of unrelenting anxiety and constant improvisation."

The book is a remarkable chronicle of how arbitrary, demoralizing, and unprofessional Microsoft's development methods often are. Moody himself was quite admittedly baffled by what he saw, although he was convinced that he had seen something important. What he saw right away is that programmers run the show. Even when they don't do so explicitly, they do so implicitly by the force of their will. Moody never once questions his and everyone else's assumption that programmers should be in the driver's seat, yet he constantly remarks on the friction, dissension, unpleasantness, and sense of failure that it brings about:

This is not to say that I understand what exactly is going on at Microsoft. For the sad fact of the matter is that I left the company's campus more confused than I was when I entered. And looking back over these pages now leaves me even more perplexed, as I still cannot manage to tell whether they contain a story of success, of failure, of success disguised as failure, or of failure disguised as success.

What he was witnessing, of course, was the creation of a dancing bear: a drearily hard-to-use product whose sole virtue is delivering features unavailable anywhere else.

The development of Explorapedia was a classic example of how screwed up our typical development process has become. There is no doubt in my mind that the product was a failure. What confused Moody was that the product shipped on time and made money. In the final pages of his book, which Moody calls a "Postmortem," he says:

It never occurred to me when I first approached Microsoft that I might end up chronicling a failed project. Yet from almost the beginning until near the end of my stay there, I believed that I was indeed observing an object lesson in how not to develop a product. Since everyone connected with [Explorapedia] was so miserable, so angry, and talked so incessantly about frustration and disappointment, I could only assume that chance had hooked me up with a catastrophe. But in fact the [Explorapedia] project was an unqualified success.

In the next sentence, Moody all but calls it a dancing bear: "While each particular feature in Explorapedia is a pale version of the feature first envisioned…the encyclopedia nevertheless entered the marketplace as the sole product of its kind." It's easy to win when you have no competition and you are backed with Microsoft's awesome brand, vendor leverage, and prodigious bank account.

By far the most damning thing is the weakness of the product. Near the end of the book, he quotes Sara Fox, one of the designers, as she looked at

…the Dorling Kindersley book upon which [Explorapedia] was based, and had been shocked to see that the book allowed browsers more freedom to explore at random than did the computer. Yet the computer was supposed to be this grand force of liberation from the strictures of the printed book. In the book, she pointed out, the text flowed freely around pictures, and readers could browse through it at their leisure, taking in volumes of content at a glance. In [Explorapedia], they would be funneled through the pop-ups in numerical order, allowed only a few sentences of content at a time. It was a hideous paradox: the computer actually would be more restrictive than the book. "Dorling Kindersley did the opposite of what we're doing, and we turned into gatekeepers."

At Microsoft, the most important projects are conceived, managed, and coded by programmers. The multimedia CD-ROM project that Moody observed was something of an exception in that "designers" were involved at every step of the way. But they in no way exhibited the skill set that I consider mandatory for the role of interaction designer. They seemed to be ignorant of all of the things important for an interaction designer: a strong understanding of what programmers actually do, an understanding of interaction-design principles and methods, and a taxonomy and tools for understanding their users. Moody makes clear that the only skills the Microsoft designers brought were a quick wit, boundless energy, and a sense of aesthetics.

Thus, it was inevitable that he would observe a very dysfunctional model. "It was a designer's assignment to try to pile on features, a developer's role to resist for the sake of meeting a deadline, and a program manager's job to mediate and render verdicts." Any adversarial relationship such as this is bound to take a heavy toll. The people, product, or company will suffer.

The Microsoft employees who worked on the project remain as unenlightened as Moody. Kevin Gammill, the lead programmer, says:

"Carolyn keeps calling it the Project From Hell, and Craig's always talking about how he's never been through anything like this. But Craig's also always talking about how we made this mistake and this mistake and this mistake on Encarta and now here we are making it again. And Sara always says, 'A product cycle is so…cyclic.' Every project here is like this! We keep saying that we learn from our mistakes…but we keep going through the same [expletive] over and over again."

Reading the intimate portraits of Gammill is as fascinating as watching a train wreck. A reader not familiar with the software industry might be tempted to write off the descriptions as hyperbole or accuse Moody of picking an unrepresentative example of the breed. But Gammill is an archetype whose behavior is very typical. I've met hundreds of men and a few women just like him.

Even under relatively normal conditions, it was hard for his teammates to talk to Gammill. An enormous cultural chasm stretched between developers and designers at Microsoft. Often it was impossible for a developer to make a designer understand even the simplest elements of a programming problem. Just as often, designers would work for weeks on some aspect of a product only to be rudely told, when they finally showed it to a developer, that it was impossible to implement.

Although conditions had improved in recent years, the two camps literally spoke different languages and came to the world of computing from opposite intellectual, cultural, psychological, and aesthetic poles. Designers came to Microsoft from the arts; developers from the world of math and science. Developers looked down on designers because their thinking seemed fuzzy and unstructured, their tastes arbitrary. Designers felt that developers were unimaginative, conservative, and given to rejecting their designs out of hand without trying to find a way to make them work. Because programming was inexplicable to designers, they had no way of assessing a developer's insistence that their designs were unprogrammable. "Designers," Tom Corddry liked to say, "are invariably female, are talkative, live in lofts, have vegetarian diets, and wear found objects in their ears. Developers are invariably male, eat fast food, and don't talk except to say, 'Not true.'" He might have added that designers and developers deal with conflict in markedly different ways. When developers, who are given to bursts of mischievous play, begin peppering a designer's door with firings from a Nerf-ball gun, their victim calls the supervisor to complain. A developer would fire back.

I want to make perfectly clear that what Microsoft and Moody call a "designer" is what I call a visual designer. Visual designers have a well-developed aesthetic sense, think visually, can draw or paint, and are a part of every one of my company's design projects. However, they add their magic to our designs only after the heavy lifting of conceptual and behavioral design work has been completed by trained interaction designers.

By the way, Corddry's snappish "Not true" is a good example of Po Bronson's "I didn't answer incorrectly, you just asked the wrong question."

Moody was very aware of the unique cultural quirks of programmers and devoted many colorful paragraphs to describing their abrasive, arrogant, demanding attitude, yet he never really fathomed their values. In his description of an encounter between burger-eating programmer Gammill and a female, "vegetarian," visual designer named Carolyn Bjerke, Moody makes a fundamental misinterpretation:

While Gammill's replies to Bjerke's questions tended toward playful banter, his demeanor and posture were undeniably hostile. He sat with his back ramrod-straight, tapping one foot frenetically on the floor while he drummed the table with his fingers. He gave the impression that he would rather be anywhere else in the world. You could gauge his reaction to Bjerke's question by the increase in the rate of his finger- and foot-taps; they accelerated in direct proportion to the difficulty of the feature in question.

Moody attributes Gammill's irritation to the "difficulty" of the undertaking. Nothing could be further from the truth. Programmers love difficult tasks. The more difficult the problem is, the more satisfaction there is in solving it. Difficulty is often the prime motivator for good programmers. Gammill's irritation is based on the prospect of having to write uninspiring code, and on his loss of control to a person he does not respect: Bjerke, the nontechnical person whose design decisions seem arbitrary to Gammill. Of course, Gammill would never state this he is probably unaware of it himself but would use the red herring of "difficulty" to lay off the blame.

If someone is to lead a development team, he or she must own the respect of the programmers. The work that programmers do is frighteningly complex and demanding, and they defend their turf ferociously. Anyone who attempts to guide programmers will fail unless he knows and respects the programmer's job inside and out. At Microsoft as in most shops there are programmers and there are "lesser" people, and those lesser people cannot possibly hope to influence the product-development cycle.

But Microsoft is undeniably successful, and this has one unfortunate side effect. Many companies are motivated to copy Microsoft's culture as a means of copying its success. It is a common mistake to copy the trappings of success, rather than the root cause of it. It's like seeing General George Patton's pearl-handled revolvers and drawing the erroneous conclusion that to be a good strategist one must wear ornate sidearms.

Moody unintentionally makes another interesting point about our software-development culture. Many executives with lots of experience in creating and marketing software products have never applied interaction design. Lacking design, some of their previous products were successes and some were failures, but the process they used to create them was the same. From this they deduced that the success or failure of a software product is due only to chance; software success is simply a crapshoot. In Moody's story, all the signs pointed to failure, yet the product was a success. For General Magic, discussed in Chapter 6, "The Inmates Are Running the Asylum," all the signs pointed to success, yet the product was a failure. Looking in the wrong places, they fail to discern a pattern, so they simply assume that results are random. The problem is reminiscent of physicians in the nineteenth century, before it was discovered that the anopheles mosquito carried malaria, who were unsure of the disease's source. It was thought to float on the evening air, striking randomly, and one's only defense against the often-deadly fever was luck. After the cause-and-effect relationship was discovered, the disease was quickly brought to heel.