Tag Archives: Feature Creep

Software Design: Feature Bloat

Posted on by
3

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

Project Priorities Perspective – Time and Cost versus Performance

Posted on by
Reply

This continues our review of the Project Priorities Perspective. See the Project Priorities Perspective post for the concept behind this and Time and Performance versus Cost for a look at those trade-offs.

 

Here is a visual view of this set of trade-offs:

projectpriorityperspectivelogofc1

Project Priorities Perspective – Time and Cost versus Performance

 

Reducing performance can decrease cost and it can also decrease the time it takes to achieve an outcome. This is the classic marketing dilemma. In general:

 

  • More features or more performance increases cost
  • More features or more performance increases time to market
  • Do I know the relationship between these and the market share I can achieve?’
  • Will a lower featured product at a lower price point give me better overall profit?
  • What features MUST I have as a minimum?
  • What performance MUST I have as a minimum?
  • Will delaying market release reduce my overall profits?

 

Of these, the last is the only one that is usually true. The rest all depend. It comes down to how well you know your customers, your competitors, your market and how good your marketing plan is.

 

Going for the ultimate product is usually fraught with difficulty, firstly because there is no such thing as Perfect Information, and secondly because it takes longer; sometimes the equivalent of forever in marketing terms.

 

Another way of expressing this is Feature Creep. This problem often exists before the product is even ready for market. Not knowing the market well, the temptation is to add every possible feature to ensure no objections at the point of sale. It normally results from a lack of confidence in the marketing position rather than a genuine evaluation of the benefit of features to overall profitability

.

The final way of looking at the challenge is expressed in an old adage, “Perfection is the Poison of Profitability“.

 

So now the trade off exists:

  • Will I add more features in the hope of better sales?
  • Will I reduce features to decrease cost and time to market?
  • Which features will I keep and which will go, and why?

 

In my experience, this is one of the most common trade offs that is handled poorly in less successful companies. And it stems from not knowing their market well enough to be able to position the product.

 

The answer – know your customers and why they buy from you. Then you have a basis for deciding. Up until then, it is guesswork.

 

You might have noticed that although we focus on low cost electronics manufacture in Australia, these principles can be applied to product development in general.

 

Next we will look at Time as the primary priority.

 

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile. This post is Copyright © Successful Endeavours Pty Ltd.