What makes software fail? A lot of software projects are outright failures: botched feature specs, missed deadlines, poor functionality, security holes, and so on.

But there is a much subtler category of failure that is much harder to spot and address: the lack of usefulness.

Just last week, I took my car in for maintenance—nothing special, just an oil change and a tire rotation. Now, I’ve taken my cars to the same shop for at least ten years, and they’re usually quick and efficient, as they should, given that these are routine tasks that any mechanic should be able to handle—well, quickly and efficiently.

This time, however, things were distinctly different: the shop had switched from its old, terminal-based computer system to a new, “more modern” system based on a GUI operating system that shall remain unnamed.

What a disaster! The shop’s productivity had dropped dramatically as the techs struggled to figure out how each part of the new software worked and made mistake after mistake, resulting in frustration on both sides of the counter.

Clearly, that software is a working failure: it probably performs the tasks that it was designed to perform, but not in a way that actually helps its users do things more easily and more quickly.

This is a much more common problem than engineers and architects are willing to admit. Far too often I see someone in charge of writing a piece software worry about how a product works without paying so much as a passing thought to whether it actually works the way people expect it to.

The truth is that we are, by and large, stuck in a reality where software somehow equates with automation. We worry about speed, performance, and scalability, and see our job as that of simply providing a tool that makes a repetitive task easier.

This approach, however, betrays a dangerous underlying assumption: that the user already knows how to perform that task—which, unfortunately, is almost never the case.

Take, for example, time-management software. There must be thousands of to-do apps out there, written for just about any platform imaginable.

It’s easy to see why: on the surface, writing a to-do list application is a simple problem that pushes many of a programmer’s favorite hot buttons: data storage, synchronization across multiple devices, perhaps even a touch of user-interface design.

You’d think, with all these thousands of programs at our fingertips, that the whole of humanity—or at least that portion of it who has access to computers—would have, by now, become perfectly organized.

But they haven’t.

You see, the problem that people have is not one of automation: it takes all of a piece of paper and a pencil to handle a to-do list; in fact, I would argue that’s even more portable than just about any piece of software you can write.

The reason why people can’t get organized is much simpler: they don’t know how.

Now, obviously that’s a much harder nut to crack. How do you write software that teaches people how to become more organized? I suspect that even the experts wouldn’t know where to get started.

Yet, that’s exactly the kind of problem that to-do lists should solve, and they pretty much all fail miserably at the task, even though they are perfectly functional software programs.

And that, more often than not, is why software often fails while being perfectly successful: because it simply automates instead of encapsulating knowledge that goes beyond the user’s own.