Many software developers have a pet peeve about customers calling their software “useless” (see here and here). It’s absolutely true that it can be infuriating to have all of your work declared “useless” because you didn’t implement some fringe feature. The uncomfortable truth, however, is that sometimes it’s true. The absence of a single feature really can render your software useless.
An alternate rendering of “useless” is “without use”. Or, in the semantics of software, “without a use case”. In software, a use case is a way of mapping out user interaction with software. It is generally a list of steps required to achieve a goal. When we start to understand “useless” in this way it becomes easier to see circumstances that would indict supposedly capable software as useless.
Imagine a microwave that didn’t let you set the time. You could no longer start it and walk away, trusting it to stop on its own. Thinking back to use cases, we can’t claim to meet a use case if a step is missing. The lack of a timer means that a whole class of use cases is eliminated. If one of those is the only use case of the owner, it really is useless to them. And importantly, it doesn’t matter what else the microwave can do.
I was reminded of this lesson with a recent Google Docs near-disaster1. I used Google Docs with a class project as I thought it would be a great answer to the need for collaboration and shared editing of the assignment. I had used Google Docs in the past for similar purposes but normally I would copy and paste into some other program (like Apple’s Pages) to do final formatting and printing. As my group’s document got larger, I decided I would use Google Docs the whole way through, saving myself the time it would take to copy, paste, and reformat. I did all my formatting in Google Docs and had a pretty nice looking document. When it came to getting the document out of Google Docs, however, the formatting would mess up in some significant way. It didn’t matter if I downloaded it as a PDF, Word doc, or other format the resulting document would be incorrectly formatted2.
Google Docs had gotten me 90 percent of the way there. Without that last 10 percent, however, the software was effectively useless for me. It didn’t matter what else it could do. It didn’t matter that I could collaboratively edit, or browse past versions, or view the document on my iPhone. It couldn’t finish the job.
As a result I’ll never use Google Docs except as a “roughing out” tool again (at least not for a few years).
This is part of the reason focus is so important in software. If you try to do too many things, and you do them all 80 or even 90 percent of the way, for many users you have created something that is no more valuable than if you had done nothing. Think about that. Even worse, you can actually create negative value, because you have convinced them to trap their data in your system that now can’t complete the job. It’s better to pick only those things you can do 100 percent and know that, at least in that area, you have created value for your customers.