Triage Software Development

I was reading over TechnicalDebt, and it reminded me of something I'd written on my company log, about a style of software development, particularly related to shareware/independent software that I call Triage Software Development. I'm pasting from http://www.rogueamoeba.com/utm/archives/000019.php .

While TechnicalDebt deals with deferring items and taking on debt to accomplish something, TriageSoftwareDevelopment is about determining priorities, particularly with regards to new features.

You've probably heard the word "triage" used in relation to medical care – triage on the battlefield or triage nurses. If you're unaware, it's the practice of sorting the wounded when resources are low. For example, if Yossarian has a sprained ankle, and Milo has a rather persistent hole in his stomach, you'll treat Milo first (even if he is an asshole). Usually it's a bit more oblique than that, and triage nurses have to deal with determining who is more likely to die first and then decide on proper treatment order. And you thought coding was tough.

Actually, the term "triage" refers to dividing the wounded into three (hence, "tri") groups: The walking wounded, who would recover on their own, no matter how much pain they are in; the doomed, who will likely die regardless of treatment; and those who will likely die without treatment but recover with. The walking wounded are left to nurse their wounds, the doomed are allowed to die, and the third group are the ones who get attention from the surgeons.

In the world of software, 'tis not good to be on a project that is doomed.--ScottJohnson

On a broader level, triage is simply the idea of assigning projects a priority based on how resources can best be used. And this is how it relates to independent software development, since there's usually very little bloodshed in the industry. You may look at this and say "So basically, you're saying 'Do what's right.' I knew that already". Of course you knew that, don't be so snooty. But can you determine what's right? That's not so obvious.

As an independent software developer, you have limited resources - limited time, limited patience, and limited money to invest in the development of your product. In all likelihood, you have a full time job, or you're a full time student, and your software is a side project. Unlike the big boys, such as Apple, Microsoft, or Adobe, you can't throw programmers at a program until it's done. You can't work around the clock for 48 hours straight to fix a bug. And you can't toss endless streams of cash at a problem to make it disappear.

Sure, if you could, maybe you'd make your software your main focus in life. And if that battlefield doctor is worth his Hippocratic oath, he'd save every life out there. But it's just not possible, so like that doctor, you're in a triage situation. You've got limited resources to expend on many problems. Sometimes, like a sprained ankle vs. a bleeding stomach wound, the choice is obvious, but this isn't always the case.

Let's make a hypothetical situation in which we'll apply triage development. You've just released Peanut Butter 1.0, that great new topping software which compliments all that other software that's supposed to make you toast for breakfast in the morning. Reaction to Peanut Butter 1.0 has been mostly positive, with scattered few complaints that the software is sticking to the tops of users' monitors. So now what?

If you set things up right, you've seen a steady dialog with your customers. You've gotten praise, complaints, bug reports and feature requests in your inbox and your user forums. First things first, fix that bug that deletes the home directory for .1% of your users! That's a showstopper, that's a critically wounded general on the battlefield, that's something that needs an instant fix. Before you answer one more email or add one more feature, you need to track down that bug, fix it, and release an update. If you don't, users will jump ship instantly, and no one will be happy. Hopefully this hasn't happened, but if something like this comes up, it's a line jumper. Put it ahead of every priority you can, even sleep.

All right, so now you've got Peanut Butter 1.0.1 out there, and it's acceptable to sit for a few days or weeks while you work on your 1.1. So now you're going to add that nifty new Crunchy option a few people have been asking for that will only take a day. NO! Wrong! Did you prioritize? Did you make a list, even a mental list? Or did you just jump into adding the feature you wanted most? You are not your users! (More on this in the future).

Let's go over why this is wrong. First of all, adding that feature takes longer than you think. Everything takes longer than you think. Second, you need to consider "What is this feature going to do for me?". Users seem to want it, so it's probably a good thing to include. But is there something else users want more, a different feature which will provide more overall satisfaction? At Rogue Amoeba, we keep a list of just about every request we get. As more requests come in, the most popular items bubble up to the top. These are the things we evaluate first and they're the things we're most likely to add to the next version. As we move down the list, we look for the easier of these moderately popular features to add. When we get to the bottom of the list (those that are least requested), only the simplest and easiest of features will be considered.

It's pretty simple - just jot down feature requests when you receive them. Mull each feature over before adding anything major. Consider the following questions: Will this feature drive sales and make me money? Will it attract a new subgroup of users? Will it please reviewers and capture people's attention?

If the answer to at least one of these questions is yes, then it may be worth adding the proposed feature. Be cynical. Be capitalistic. Be sure you can add the feature without making the interface too complex or drastically changing the functionality of the application.

So when you're developing, think triage. Figure out what you can add that provides the most benefit at the lowest cost. And do what's going to be best for you – in the short term, that'll probably also be what's best for your users, and in the long term, it's certain to be. Developing with triage in mind means current users will get the most popularly requested features, and you'll attract more customers and make more money. This will enable you to continue developing the software, until every single possible request has been filled. And then you get to deal with the bloat 8).