Avoiding Feature Bloat – Making the “good idea” better

Commercial software development is the art of creating sustainable revenue from a “good idea”.  Once upon a time, someone thought: “Wouldn’t it be good if there were a program that can do X?”.  Being the cunning entrepreneur / thrill seeker or in some other way just blind to the possibility of failure, this person then set about writing such an application, confident that because they wanted it, other people will too – and that those “others” will part with their hard-earned cash in order to get it.

In order to keep the sales ticking over, this idea expands with upgrades in an effort to keep enticing people to pay up.  Keep making it better, keep people paying…  The only problem is defining “better” for software is somewhat vague.  You can add features, or you can fix bugs.  Adding extra features treads the dangerous path of spoiling the software and according to Bill Gates, no-one wants to pay for fixing bugs.

In other words, there’s no defined science as to how to make the software better, but there’s plenty of circumstantial evidence that you can make your product worse.  The good ideas for your product are out there, but they are well camouflaged and hidden amongst the myriad of worthless potential features.

Dawn Foster is of the opinion that:

“Open source software seems to be better at figuring out which features are really needed by most people and not getting into the trap of trying to satisfy every need that a potential customer might someday have.
By providing the source code, open source software often avoids feature bloat. The source code gives a customer with a specific need the flexibility to add a feature.

It boils down to this. When considering feature bloat, open source software has an advantage over proprietary software because the source code provides more flexibility to the user community. Users can choose to add features and functionality as needed without relying on a vendor to satisfy their every need.”

However, it is worth remembering that the “good ideas” will come from a specific need.  This was what spawned the product in the first place.  But often, once the product is released it ceases to be “your need”.  “Your need” becomes a way to track and prioritise feature requests, bug reports, sales leads etc.  Basically, everything but making the software better.  This is the true advantage of the open source movement.  They aren’t interested in making money from an idea, so they remain faithful to their original need.  Often there is no communication gap between vendor and customer because the vendor is the customer – so the “needs” remain undiluted.

Adding features for the sake of it, will reduce the overall appeal of the product.  Commonly this sort of bloat leads to a performance drop off in the software but even if you can avoid lowering the performance of the software you can end up with a situation of more features = more complexity = more confusion = less customer satisfactionRob Goodlatte writes

“Bloated software is harder to sell. Marketing messages become diluted when theres (sic) too many features for too many types of users. Don’t extend software with features that stray from the original vision – both brand and product will suffer.”

Given that you need to eat and you’ve elected to make money from your “good idea”, the question then becomes: “How do I avoid straying from the vision?”.  I think you need to be of the conclusion that sooner or later your software will be “perfect” in terms of a feature set.  Perpetual motion doesn’t exist, so stop trying to write software thinking that it does!

This idea leads to several others:

  1. You won’t need to be forever looking for a useful feature to add.  At some point you will say that everything worth doing has been done.  The idea here is simply to avoid adding the bloat in the first place.
  2. At some point development of the product will be scaled back.  You are not euthanising the project – just re-prioritising resources.  Some market impetus may mean that in future you need to revive your program, so keep it on life support!  Regular bug fixes may not be a way to impress a new customer but you will be buying good-will from your existing customer base and reducing the burden on your technical support team.
  3. Creativity will not be restricted to only improving existing products.  The development team will recognise that their creativity should not be restricted simply to the product you are currently writing/selling.  The software industry is constantly changing and so should your product offerings.

Having said that, most software products are likely to have several (useful) ideas that will lead to upgrades.  Initially, these ideas will likely be features you wanted to put in to version one, but didn’t have the time or resources to do so.  Seeing this was your need to begin with, these ideas for upgrades are likely to please your customer base and are therefore worth doing.

After your initial crop of ideas run out, you are likely to turn to your customer feedback.  But who should you listen to?  I think Michael from “37 signals” is on the right approach:

“So what do you do with all these requests? Where do you store them? How do you manage them? How do you track all these requests? You don’t. Read them and then throw them away.

Yup, read them and throw them away. The ones that are really important will keep bubbling up. And those are the ones you’ll remember. Those are the important ones. You don’t need to track or remember everything — let your customers be your memory. They’ll remind you.

So, ask for requests, read the requests, listen to your customers, and then forgot what they said. Let them remind you over and over and over again. That’s how you find the real gaps in your product. That’s how you’ll remember what new features are really worth considering.

And one more thing: it’s not just about the sheer number of requests (we don’t recommend adding something just because X# of people requested it), it’s about customers planting a seed in your mind. If they keep reminding you of something, it forces you to think about it. Maybe it is a good idea. Maybe it isn’t. But at least it’s important enough to consider if so many people keep asking for it.”

It sounds harsh, but I think the idea is on the right track.  Personally, I am a little too conservative to just forget about the ideas.  I think the attitude should be to “log the requests, then you can forget about them”.  Storage space is cheap and having an electronic brain to quote the customer verbatim may be useful when determining exact requirements at a later date.  Of course, the catch is you will need to be able to find them again – but that may not matter:  I heard a story that Bob Dylan keeps all his lyrics in a book that he has with him on stage – in case he forgets the words to one of his songs.  If he ever needed it mid-song, he’d be in trouble of course, but he finds it reassuring to have… 

If you are going to use the “wait until you keep hearing the request” strategy to drive feature requests, then I urge you to remember the first word. “Wait”.  Good ideas take time, good software takes time, quality takes time.  But that’s a topic for another day.