Some people refer to this trend as “creeping featurism”. Creeping featurism is a term used to describe a tendency for systems to become more complex over time as more features are added. In software development, these added features often come at the expense of simplicity of use. Superfluous functionality increases the complexity of the user interface … and simply put, it makes off the shelf software applications less intuitive and more difficult to use and learn.
One sure way to develop bloatware is to leave product design decisions up to the developers of the software. If left unchecked, developers have a natural tendency to add in functionality that they think is neat, without asking the product’s user base. Best practice is to develop new functionality only where market feedback indicates that it adds value.
As a cautionary note, be aware that no two Clients have the same needs. Functionality that is an “absolute non-negotiable” for Client A could well be a “rather not have” for Client B … and it’s entirely conceivable that the reverse scenario exists too. It is for this reason that companies that develop off the shelf software often declare that their Clients should carry a part of the accountability for their application having become bloated.
Sidestepping the bloatware problem
So, how does one side step the risk of inadvertently developing a bloatware application? Some principles that we have followed when developing the Therefore BPMS, which forms the basis for the Therefore StratIQ™ and Therefore Quantum™ products, are detailed below.Stick with your knitting
If your application is a Task Management application and your Client is looking for a Customer Relationship Management (CRM) application, stick with your knitting. Do you really want to develop CRM capabilities within your Task Management application? If you did, would it take your eye off the ball? Would it see your hereto contained Task Management application becoming bloatware? Wouldn’t it be better to recommend an existing CRM application to your Client and stick with doing what you do best?It is imperative that you remain clear on the niche that your software is designed to service. Entertain any move outside of your core area of strength only after having given it some very careful thought.
Simply put, you need to accept that you can’t be everything to everyone. Trying to please everyone is a slippery slope that often leads to pleasing no one … and the eventual development of bloatware.
Always ask the market
New functionality should be the consequence of market feedback. Continually speak to your Clients / prospects, show them your software and take note of their questions and suggestions. When it becomes clear that their questions and suggestions are pointing to functionality that your system is missing … go to it!When you do decide to develop new functionality, remember to run your wire-frames, and eventually prototypes, past your Clients. Asking your Clients what they want invariably unlocks huge value.
Keep an eye on usability
As you increase the number of features available within an application it becomes increasingly important to make sure that your application’s usability does not suffer.Money spent on improving the usability of an application is always well spent. Again … there is no substitute for taking steer from actual users of the application when it comes to driving usability enhancements.
Benefits Vs Features
You don’t take a product to market because of its “features” … it’s actually the “benefits” that sell a product. Developers often have a feature centric view on the world, whereas Clients are typically looking to the benefits associated with using your application.Make sure that all of the features that you add into your application play either a direct or indirect supporting role for a product benefit. If your proposed feature does not add direct or indirect value to a benefit, the chances are that you should probably not be going there.
Functionality on demand
As already mentioned, no two Clients have the same set of needs, given that they are generally operating in different markets with their own / unique contexts and working towards achieving different strategies. Naturally, this introduces the potential for some degree of application bloat.Off the shelf software should be developed in such a way that features can be turned on or off, as dictated by the needs of the Client. We call this design principle “Functionality on Demand”. The Functionality on Demand design methodology allows your Clients to turn off functionality that they believe doesn’t add value, given their context. Simply put, it allows them to turn off the “bloat”.
We always encourage our Clients to turn off as much as possible, because the less superfluous functionality, the less cluttered the user interface and ultimately the better the application’s usability. Besides, your Client can always turn on previously deactivated functionality as their needs change or their experience in using your application deepens.
It’s more than just a software problem
The bloatware pheromone is more than just a software problem.There are many examples or products and services that have become bloated by superfluous features and / or options. In the product and service space, bloat tends to unnecessarily increase your costs and work against your levels of customer satisfaction.
Should you be in the game of selling products or services, you will probably find that the above bloatware avoidance tips still add some degree of value in your environment. You may also find that a previously written blog article that talks to implementing Strategic Flexibility would be of interest to you.
