Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software (much of the book is available in online form now). At a point roughly midway between the start of the personal-computing revolution in the mid-’70s and the present, Kapor threw down a gauntlet: Computers were too hard to work with. “Everyone I know (including me) feels the urge to throw that infuriating machine through the window at least once a week,” Kapor wrote.
The PC revolution’s promises of “personal empowerment” remained unfulfilled because the software that drove the miraculous new machines was simply not well-enough shaped. The people who made it weren’t thinking clearly enough about how their products would be used. Somebody had to do that work; Kapor argued that programmers probably weren’t the best people to take it on, and proposed the creation of a new discipline of “Software Designer” to wear this mantle.
This person’s role incorporated some of the work often associated with the “software architect” on the one hand and the “interaction designer” or “UI designer” on the other. The software designer wasn’t just a graphic designer, nor was he just an engineer; he was responsible for the “overall design” of a program. For example, Kapor writes, Dan Bricklin was the “designer” of the original VisiCalc spreadsheet not by virtue of having made detailed choices about its user interface but simply by having invented the “metaphor of the spreadsheet itself.”
In a way, Kapor’s manifesto applies the auteur theory to software. Just as the movie critics who espoused that notion wanted to direct our attention to thinking about who was the true “author” of a movie — in most cases, they argued, its director rather than its writer or producer — so Kapor wished to see programs shaped by one creative individual who could push them in valuable new directions and keep them from losing touch with whatever vision drove them in the first place. Such programs would be consciously and deliberately designed by a trained individual who could think not only about the engineering and implementation detail but also about the overall purpose and goal of the program and how users would interact with it. Interestingly, Kapor held that the designers should know programming (“Designers must have a solid working knowledge of at least one modern programming language”).
Robert X. Cringely’s history of the PC industry, Accidental Empires, suggests that Kapor pushed to elevate the idea of software design because he was afflicted with a case of “impostor syndrome” — he felt guilty about his own financial success at Lotus and somehow that guilt was motivating him to try to turn his own haphazard career path into something more formal and legitimate. That idea is, like much of Accidental Empires, muddled, entertaining and a little bit insane. I think Kapor’s motivation was simpler and more forthright: he knew that many programmers distrust designers and feel that they know best how to shape their handiwork. But he also knew that teaming a designer with a programmer could work: he’d had a hugely successful experience creating Lotus 1-2-3 in collaboration with Jonathan Sachs. And he wanted to see if that approach could be turned into a model for making better software.
A manifesto is a call to action. Did Kapor’s bear results? In the years since, there have been a handful of programs established — like Winograd’s at Stanford — to provide formal training to career software designers. Certainly, as software has moved to the center of the business world, and as Web-based programs have entered the mainstream, the industry has grown more aware of the need to impose creative shape on its products. On the other hand, there aren’t many examples of design being elevated to the central role Kapor advocated. In most organizations today, a business person says “This is what we need,” programmers attempt to build something to meet that wish, and designers slap on an interface. Programmers and designers often remain in an “us vs. them” relationship.
So far, I think the biggest hurdle to wide adoption of Kapor’s software design model is that it’s been too easy for organizations to view the role of software designer as an added luxury cost for most projects. And there simply aren’t many people with the unusual combination of skills and passions to play that role well. A good auteur, in software as in cinema, is hard to find.
Is Kapor’s early-’90s prescription still relevant? Do we need software designers as a distinct profession separate from “software entrepreneur” and “software developer”? I still find the “Manifesto” a bracing read, but I’m curious to know how it sounds to programmers working in the trenches today.
[tags]code reads, mitch kapor, software design[/tags]
Post Revisions:
There are no revisions for this post.