Un-Jobsifying software development

Steve Jobs justified his distain of user studies by claiming that “users don’t know what they want”. This is true, as far as it goes — recent events have demonstrated the dangers of giving users what they think they want at scale in ways that even major media outlets can’t ignore. The second, unstated part of this, however, was more powerful and more dangerous: the idea that Steve Jobs knows what users want. In the case of Jobs, this concretely meant the uncritical adoption of design ideas intended for standalone appliances.

Unix philosophy is often summarized as “do one thing and do it well”. When stated this way, it’s pretty similar to Braun’s design rules. The third part, often left unstated but monumentally important, is “play nice with others”: what distinguishes the Unix command line from a Chumby or a Macintosh Plus is that the components are composable. Ignoring this third rule transforms a computer from a construction kit (capable of solving any problem with a little ingenuity) to a box of ready-made appliances (each not quite doing what you need, with no customer-servicable parts inside).

These twin misunderstandings define Steve Jobs’ legacy. (I say Jobs’ legacy rather than Apple’s legacy because the other half of Apple’s DNA comes from Wozniak, whose approach was much more in line with the Unix hacker’s emphasis on tools-to-make-tools and tools-for-engineering.) Apple’s late popularity (after twenty years on the edge of bankruptcy, mind) has cemented Jobs as some kind of design visionary and encouraged the uncritical adoption of the ideas he uncritically adopted: that designers know better than users about users’ own needs, and that walled gardens are more desirable than ecosystems. I’ve written at length about the second elsewhere, so I will focus on the first (which I have only touched on).

So long as programming remains a niche skill, the developer-user relationship is an asymmetrical power relationship, like that between teacher and student or doctor and patient. Like doctors, we attend to the needs of vulnerable people who don’t have the background to distinguish good advice from bad advice. Like teachers, we control institutional access (locking people out of accounts or letting people in, determining whether whole classes of people get to use our software based on our implementation of accessibility standards and our color scheme and font size decisions, and in extreme cases even controlling whether or not people go to jail). Like lawyers, everything we do becomes precedent for future situations — and tools for the less competent or scrupulous.

Unlike lawyers, no judge exists with domain knowledge and the power to shoot down ideas. Unlike teachers, no institution exists to discipline us for favoritism and no tenure or emeritus system exists to encourage the retention of experience. Unlike doctors, professional societies and standardized ethical codes have no control over our employability and people who make unforgivable mistakes cannot have their license rescinded.

As a result, if we care about the world, we need to be very careful about how we use our substantial power. A weekend project can serve more people than any building does over its entire life; we have an incredible responsibility to those people. Hacks get uncritically copied, trendy technologies get uncritically adopted, and users get caught between the poorly-fitting gears. We put liability waivers on our tools, but while we may no longer be legally responsible for how other people use our tools, we still bear enough residual causal responsibility to justify being extremely careful. The first step toward such care is getting rid of the illusion that we are more knowledgable and capable than the people we serve outside of a tiny corner of specialization.

The ideal interaction style between user and computer is not appliance-use but collaboration. In this way, the user and computer can develop each other together, each providing things the other could not alone. In order to make this possible, developers need to act collaboratively with their users, too: understand the core loop in their creative process, and provide tools that allow the user-computer-amalgam to be more creative and more discerning and tools to make those tools more effective. Tools-to-make-tools are not the sole domain of engineering: a serious musician invents tunings or whole new instruments, and a serious painter experiments with and ultimately invents new personal techniques; the only thing standing in the way of opening up the computer to such experimentation by “non-technical” users is communication.

Ultimately, by bridging these gaps, the distinction between “non-technical” and “technical” will begin to dissolve, the same way that public schools dissolved the scribal class.