Recent Posts

Software Design: Feature Bloat

Monday 9th April 2012

Software Design

This continues on from my posts on Software Architecture and Operating Systems and is part of the Software Design series.

 

Feature Bloat

This is also known as Feature Creep but I prefer the term Feature Bloat because it better describes the effect it has on a single project. This is rather like eating too much and ending up feeling uncomfortable for an extended period of time. For this part of the post I will focus on a single product version release.

 

Feature Bloat

Feature Bloat

The worst part about Feature Bloat, is that it adds features to the product which probably don’t improve the market success, but definitely delay the product release. This is always a profit reducer. And when you are working as independent developers as we do, it is also not obvious to the client which features are going to be easy to add and which are not. For instance, adding an ‘UNDO’ feature is often very expensive if it is not allowed for up front as this often requires restructuring of all the data handling methods to include history tracking.

 

So the first thing to do when looking at adding new features, is to ask the following questions:

 

  • Do I need it now or can I add it later?
  • Will it require substantial restructure?
  • Will not having it reduce sales?
  • Is it adding value or just clutter?
  • What degree of timeline risk does this feature add?
  • What degree of budget overrun risk does this feature add?

Perkin Elmer and Varian competed in the market for the sales of spectrophotometers amongst other things. I was working for Varian in Australia in the 1980s. Perkin Elmer were the market leader with Varian usually having better instruments but getting beaten at the overall sales game. How did Perkin Elmer do that?

 

As a young Electronics Design Engineer I was mostly focused on the core Engineering Design associated with my role at Varian. I was part of a small team that achieved a few ‘World First’ outcomes at that time. Amongst these was a UV/VIS Spectrophotometer in the Cary range that had a dynamic range of 6 ABS or 6 decades. This is a million to 1 ratio. It also removed the need for a rear beam attenuator for may tests and allowed streamlining many test processes. While I am proud of that achievement, the most striking thing I learnt at that time was that Perkin Elmer were number one and expected to stay in that position regardless of the quality of the engineering work I was doing. These reason as explained to me like this:

 

  • Perkin Elmer are designing a new instrument
  • They have some good ideas during the development process
  • So they take a note of all of them but probably don’t implement any of them
  • They release the instrument on time knowing it isn’t the best they could have done
  • Immediately the pick from the new ideas pile the feature for a second version of the product
  • They release this is 6 to 12 months time as an incremental model
  • And they go around the cycle again, and again, and again

 

In the time Varian can release one technologically superior instrument, Perkin Elmer have released 2 models. While Varian build sales of their instrument Perkin Elmer will release another 2 model updates. Every year at the annual sales conventional Perkin Elmer have something new on the stand. Salesmen love new models and customers love having the most recent model. This strategy gives them market dominance. So that was a very interesting thing to learn. But it was not the primary lesson here.

 

Varian knew this was how Perkin Elmer achieved their market position but would not change their strategy, even while they knew it would not bring them the success they wanted to achieve. So I learnt that the organisational culture can mean that successful strategies are not adopted, even when it is know it will improve success.

 

So what does that have to do with Software Design and Feature Bloat?

 

Software Feature Bloat

Software Feature Bloat

You do need to design with the end in mind, but unless it can be proven that a new idea will substantially improve the sales success of the product in the same timeframe, then hold it in reserve for a future update. It is better to be selling the product earlier than getting those profits in and improve the product over time than to wait until it is perfect.

 

Both Microsoft and Intel built enormously successful companies using this philosophy.

 

Software Bloat

This is different to Feature Bloat or Feature Creep in that it tends to occur over successive software releases. This also leads to software known as Bloatware. In this case, the product has features that are either not necessary or which in fact reduce the overall usefulness of the product for most users. As much as I love Microsoft Word as a product, the Office 2007 release broke a number of features that I find really useful and Office 2010 has made one of them very hard work indeed. In particular I am referring to outline numbering which has gone from incredibly useful to almost mystically unwieldy.

 

Software Bloat

Software Bloat

But the real impact here is that it proves you don’t know your customers very well. Apple have done very well with their iPod, iPhone and iPad range because they have only implemented features that most of their users will want and have stringently avoided Software Bloat.

 

So lesson 2 is to know your customers and to keep making it easier rather than harder for them to use your products, especially new customers who don’t have the history with the product to understand why it is the way it is now.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2012 Successful Endeavours Pty Ltd

3 thoughts on “Software Design: Feature Bloat

  1. Love all three images in the post. Could you say more about the context of the pie chart? And did either of Varian or Perkin Elmer end up the victor, or another surprise candidate??

  2. Hi David,

    the pie chart is taken from a study by Standish Group chairman Jim Johnson presented to the XP2002 conference. The statistics are taken as an aggregate from a number of IT projects and show that this is not a problem specific to any one product. In the same presentation he also cited 2 IT developments which were comparable in scope and requirements. One took one year and $1.1M, the other took 15 years and $170M. Leading to this fabulous quote: “Inside every large project is a small project trying to get out”! Love it. Myki anyone?

    This is actually one of the reasons our USP exists:
    “We make electronics and embedded software work the way they should, saving you up to 2 out of every 3 dollars you otherwise would have wasted, so you can manufacture your market leading product in Australia at a profit.”
    This isn’t trying to say “We are cheap” although I recognise the risk that it is read that way. What I am trying to say is that if you work with us we can get you there faster and better. This also turns out to save money. But we aren’t cutting corners. We are delivering the little project that you actually need and not the behemoth it can become in the hands of someone who just wants your money. In 2009 and again in 2011 we received some trophies for our engineering design practices. You can check them out at:
    http://blog.successful.com.au/2009/09/18/edn-innovation-awards-2009-2-trophies/
    http://blog.successful.com.au/2011/08/23/industrial-electronics-future-awards-winners/

    Varian Techtron ended up being spun out as Varian Inc and purchased by Agilent whereas Perkin Elmer is still going strong. So I think the Perkin Elmer model prevaled. Of course there is always room in any market for a number 2. One of the rules of branding is that a strong number 1 needs a number 2 and they usually have 80% of the market between them.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.