NeoVictorian 2: Off The Floor
The laborer feels himself first to be other than his labor and his labor to be other than himself. He is at home when he is not laboring, and when he is laboring he is not at home.
Who would call a car company's payroll system, "home"? That was the task of the original Extreme Programming team. In software, much of our work and many of our dreams focus on Enterprise. Most of the rest concentrate on tiny tools that are expected to appeal to a mass audience, or grand tools — Office, open or otherwise — that can be imposed as standards on the world of work.
This isn't working. We've been stuck for years, the backlog never goes away, and we fight the same old fights with a new generation of management. The Enterprise is too complex, too turbulent, too confused, to be a fruitful place to study the craft of software. We don't know when it's right. Yes, we sometimes know when it's wrong, when we can't even deliver the software. But what is success? Praise from a self-interested manager? An incremental improvement in corporate throughput? A pile of surveys filled in by our students? A nice writeup in The Journal?
I propose that enterprise software is a hard problem that we can understand only after we solve an easier case, one that lies close to hand. Before we can tackle the enterprise, we need to write software for people. Not software for everyone, but software for you and for me.
By NeoVictorian Computing, I mean systems that are
- Built for people
- Built by people
- Crafted in workshops
When I say that software is "built for people", I don't mean some fuzzy notion that the software is intuitive or "friendly" or that it can be sold to millions of consumers. I mean, simply, that it offers some specific people three specific virtues: commodity, firmness, and delight.
It helps to get stuff done: not filling out forms or filing pictures or retrieving records, but the endlessly difficult, challenging, everyday stuff of understanding what is going on around us.
It doesn't break down in use. That doesn't mean it never fails: failure is part of software, just as brushstrokes are part of painting. Firmness means we can trust it, the way we trust the handle of a good hammer — including the knowledge that even good tools can crack.
And, sometimes, it makes us smile. Or it makes us think.
We can know when personal software is right, in exactly the same way we know when a theory is right, when a painting or a sentence is right. We don't need clinical studies or usability labs. We don't need box office numbers. We don't need to see the reviews from the newspapers or the VC's. We know.
And, yes, we might be mistaken. We sometimes deceive ourselves. It happens. At times, an audience helps us know that we're really right, and on occasion the approbation of our students or the cheering accumulation of sales might reassure us. But these are secondary; we have to start by knowing what is right and true, because we confront too many crucial choices to work from focus groups and popularity polls.