Software Design: Feature Bloat

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 (now Agilent) 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 two models. While Varian build sales of their instrument Perkin Elmer will release another two 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 time frame, 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 found 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