The "Very cool" moment: Making useful software
After reading a few complaints about their open source product in a forum I monitor, a developer on the project replied:
"Our current product is a well used and good product for the use cases it was originally created for. However, that is not what the majority of users want to use it for..."
One of the nice things about open source development is the, well, openness: the transparency, and accountability that it encourages. It's not likely you'd ever see a proprietary developer get on a public list and write something like that. But having said that, how can you avoid being in this position in the first place?
There are three key insights in this quote. First, let's look at the part that says "the use cases it was originally created for".
In this particular project I happen to know that a lot of thought went into those use cases. The development process wasn't quite the traditional waterfall but it was definitely "requirements and specification" oriented. You know the model: a) you spend a lot of time figuring out what needs to be done, b) you spend a lot of time doing it, and then c) you give it to users and hope they like it. If you can do a good job at (a), and if you can do a good job at (b), and if the user's needs haven't changed by the time you get to (c) then you're all set. But how likely is that? Three words of advice: agile, agile, and agile.
Second part: "the majority of users". We've all been in a situation where a few vocal users or partners or competitive pressures convinced us to put in some, shall we say, questionable features. A few special cases here and a little bloat there can't hurt can it? Actually... We need to stay focussed on what the majority of our users need for the majority of their work.
That brings us to the final point: "what the users want to use it for". When it comes down to it, users don't know what software they want, not really. What they know is what they want to use it for. In other words, what can it do for them? Will it save them time? Is it going to solve their problem? If the software is not useful (literally, full of use), then everything else is moot.
There's no perfect model for everyone but here's a thought. Talk to your users a bit to get a feel for what they're trying to do. You'll get it wrong, but that's ok. Then code something up and give it to them right away. I mean, the same day or the same hour if possible. Listen to their feedback, especially the things you did that they don't mention since you were probably closest to the mark on those. Then make adjustments; rewrite it if you have to. Don't get too attached to that code. Don't worry about performance until later because chances are, you will be optimizing code that will be thrown out. The important stuff is in your head, and in the mental model you're building up of what the users need for your product to really do. Lather, rinse, and repeat.
I've been practicing this method on a project of my own lately, and it's working great. Here's an actual quote from one of my internal users from a few days ago:
"This is VERY VERY COOL.... VERY COOL indeed. If you hear the thumping on your ceiling, its just me on the fifth floor jumping up and down with glee. EEEEEEEHHHHHHHHAYAAA!!!!!!!!!!"
Of course, the next thing they did was point out a bug, but that's ok too. Forty minutes later, they had a fix in hand and we were moving on to the next task.
I know, it's not always possible to get this kind of feedback loop going with your users. For one thing, it takes a lot of their time and patience. But when it works, it is very cool indeed.