Tuesday, March 03, 2009

On Prioritization in Software Development

I've been thinking for a bit about what makes software go from good to great. I realized something: the number of features is irrelevant. No, what makes software great is the little touches. Tiny little things that make your life easier. The itunes music player has a perfect example of this. On a feature-by-feature comparison with Windows Media Player, it probably loses big time, but it does the right thing more often. I can't exactly quantify what those are, but I know I enjoy using Itunes more than Windows Media Player.

The standard thinking about building a software product goes like this: You create a list of features. You sort the features by priority. Then you start writing specs. Each of those specs has subfeatures that each have their own priority. What ends up happening is that you end up selecting a large set of features due to optimistic scheduling. Then each of those features ends up having to cut back its scope or lose polish.

What happens next? Well now all those really neat things that would have made your product really awesome end up getting cut as they're "nice to have", instead of "must have" for the features.

Those "must haves" might be on a checklist for a business customer, but for an end user, those kinds of things aren't going to make them fall in love with your software. No, the "nice to haves" are what will make your end users love your software and tell all their friends.

2 comments:

Katie said...

Nice! I think you're spot on with your analysis here, but it makes me wonder where the line is between simplicity and flexibility, or simplicity and feature richness. It seems that the more complex the software is (e.g. media player), the more likely it is to be more flexible, but that flexibility introduces unnecessary complexity (and often faults). I see a big challenge in identifying exactly the features that will mean the most to the user and focusing on them - the "nice to haves." Regardless, you're right. Fewer features done well is better than many features done haphazardly.

MntlChaos said...

Hmmm... perhaps it's not the scheduling technique that's at fault, but the estimation. If the number of major features incorporated into a release is smaller than the time allotted for it, then the "nice to haves" won't have to be cut, and quality will go up.