Feature Creep
We were having a discussion this morning about the perils of building your business around a popular tool that you’ve made, and I thought it might make a good blog post. Really this is inspired by the impending upgrade I’m going to need to do to SmartSVN 6, despite having only just bought a SmartSVN 5 licence. It’s a nice package, especially the diff tool. And there are times when you really do want to navigate the changed files in a large tree of directories, and TortoiseSVN and the command line shell really suck at that.
My problem comes in that pretty much all of the functionality I needed from the tool has been present since version 3. Sure some of the new features are nice, and the overall application is prettier now. But mostly what has come in subsequent versions has been for me superfluous bloat. It means the installer is bigger, it means the application is slower to respond, and more complex to navigate the interface. And really what I actually would most value is if I had pretty much the exact same set of features, but a) bugs were squashed and no new ones added, b) the support for the underlying system (in this case Subversion) had been kept up to date, and maybe c) the interface was improved and streamlined.
It’s not just SmartSVN though, it’s lots of applications. GetRight, ACDSee, Word/Excel/Office, all of which have gone through many revisions, each one adding more and more features that I don’t really need or appreciate. In the case of ACDSee the later versions actually made the interface worse, which effectively removed the one feature that people bought it for – the quick and easy way to mouse-scroll through whole directories of images.
The problem here is that what the end users want is fundamentally at odds with what the business needs to do. The end user would be quite happy having the same application and just keep using it forever. But for the business that authors the application, that’s a losing proposition. They’ve made one sale, and they get no more. What they really want is to be able to sell more things to the same user. If they make a new version of the tool, they can put enough new features in to persuade the user that it’s actually a new application. The user isn’t an idiot though. They know it’s not a whole new application. Maybe they need or would like some of those new features, maybe not.
Most likely they’re buying the new version because it fixes bugs in the old version, and is better supported. I’d even go so far as to say that they’d be willing to pay for those bug-fix and maintenance updates – not as much as they’d pay for a whole new version, but something at least. Some companies, like Whole Tomato (who make Visual Assist) have a refreshingly straight-forward approach to this: you buy the application, and you get X months of updates along with it. After X months, you have to pay again a smaller amount to keep getting updates.
Even Whole Tomato though are guilty of the most annoying of the application developer’s sins (from an end user’s point of view at least) – feature creep. Every development has a Request For Enhancement list which is used as a back-log of items that might make their way into the application at some point. Anything reasonable the end users request goes on that list. And because the developer is a business, that makes its money from cranking out new versions of the application, they work through that list, pretty much endlessly. So an application which is clean, usable and decently featured in version 3 can turn into a Swiss-Army-Knife of an application by version 8; bristling with functions, features and options, which the majority of users, other that one user who requested it originally may never touch.
It seems that very rarely is the decision taken to just draw a line in the backlog and say “it’s good now, let’s just stop adding features”. Keep selling it, keep maintaining it, putting out bug-fix and maintenance upgrades, but no more features. What, I ask, is wrong with making compact applications with specific and targetted functions? Even if there are valuable features to be added, why not ask if there is value in maintaining a Core and a Premium version of the application? Or even multiple Premium versions? Find your users and target the groups who want to buy your product. Give them each their own version. Discontinue versions that don’t sell well, and maintain versions which have.
A well architected software development can maintain development on multiple branches simultaneously with not too much extra effort, certainly there is a cost but I believe there is also a reward. Give your users exactly what they need and no more, and you avoid becoming the behemoth application that is under-cut by a spunky fresh new competitor, that didn’t have all of your features but had “just enough” to be valuable, was cheap enough to develop to undercut you on price, and flexible enough due to its small size to adapt quicker and better to changing technology than you did.