The "Very cool" moment: Making useful software

The "Very cool" moment: Making useful software

Summary: Figuring out what your users want is not easy. Or is it? Maybe you're just going about it the wrong way.

SHARE:

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.

Topic: Software Development

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • Core functionality and other.

    Your effort is, as I think you recognize, based on the first part of your description, finding out what is required. There's most of the essential work after that still to do, especially how everything connects to everything else. But I expect you recognize that, too.

    There's an old proverb, The appetite grows with the eating. The more you continue, the more the software will be asked to do and the smaller the number of people who need the added functionality. Part of the problem is often that no one ever asked so directly before...

    So you end by having to determine what a large number of people need (not want) to do, and the set of definitions and procedures that apply to them. This process of abstracting can be difficult politically, but it's part of making certain there will be a useful finished product sometime before the organization changes unrecognizeably.

    But I expect you know that, too. Just wanted to say it.
    Anton Philidor
    • It's cool if it's appropriate.

      When it's a relatively small piece of end-user code with limited dependencies (or even at the very early stages of a large project) this can be good advice.

      Just make sure:

      1) you don't drive your users crazy with constant pestering for feedback. Especially in a business setting they've got actual work to do. Even hobbyists may choose to skip incremental releases of open source software because they value occasional periods of stability.

      2) you don't go crazy yourself by relegating forward planning to the back burner. "Reactive coding" can keep you so focused on specific feature requests that you lose sight of the primary purpose of the code. Sometimes it's best not to provide a feature, but to provide hooks to something that does. Example: in a database application you're usually better off using 3rd party reporting tools than building your own.
      dave.leigh@...
  • Specification Oriented

    "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?"

    Very likely if you do it right. The key is you can't go in with the idea that the only way you can succeed is to build an application. Sometimes preventing the application from being built has by far the highest ROI.

    "Three words of advice: agile, agile, and agile. "

    Agile only works if the cost of validating a system after modification is significantly lower than the cost of implementing the feature.

    There are a lot of variables that can affect the cost of validating a system, but it seems to me that the cost of validation tends to quickly exceed the cost of modification.
    Erik Engbrecht