5 Tips for Avoiding Shelfware

It is interesting that we work in an industry which has developed such a bad reputation for overselling that the term “shelfware” was coined. According to a poll, which was conducted by IE Software, companies in the U.S. spend $12.3 billion per year on maintenance for software that nobody actually uses. Every organization has shelfware, which generally refers to software that has been purchased but never used. However, not everyone realizes that this unused software could pose potential quality or security risks, which in turn impact both customer satisfaction and brand reputation.

For example, what if the software in question is intended to check your code for potential security issues? If you (or your organization) are developing a customer-facing web application and buy a software testing solution for code assurance, you want to make sure that it is actually being used and that it is an integral part of your development cycle. Why would you purchase software that enables you to build security in at the code level, yet not use it?

To understand shelfware better, it is helpful to recognize that buyers are just as responsible for this situation as sellers. Organizations often bulk-buy licenses for software and services with little additional consideration or outside research. As a result, they seldom consider the real cost or purpose of this software until it is too late. They also tend to invest in future enterprise rollouts of big business applications, although typically only a small amount of the licenses purchased (and in some cases zero) actually are used.

If you are in charge of a development organization, shelfware should definitely matter to you. With that in mind, here are five tips for avoiding shelfware:

Confirm a clear path to adoption. An organization’s purchase decision should be made around a viable solution. This solution must be able to function in your environment and be a part of your process. Do not make a purchasing decision until there is a clear path to adoption.
Train and educate your employees. Organizations should strive to train an internal team of power users. Make sure that there is some initial deployment strategy, which includes training/educating your employees or guaranteeing that they are knowledgeable and aware/cautious of shelfware and the risks that can arise from it.
Run an audit. Once the organization’s software solution is deployed, make sure that you contact the vendor to complete a thorough audit. This will ensure that everything is functioning properly and that the organization is getting the most out of the solution.
Confirm that product is actually being used. Confirm that your employees are actually using the product. Before making a purchasing decision, ask yourself the following question: “if you buy it, will they actually use it?” This is the most crucial question that you should be asking your team and any vendor that you work with. For example, a new testing solution may be “ground breaking,” but will it work within your existing development environment? Obviously, this product will only work if you are able to get your developers to use it. The product needs to become part of their process.
Use trials. Learning to use trials can be beneficial when making a purchasing decision because it can verify that a feature or aspect of a program works. This can be an important step in eliminating shelfware.

Having a deployment plan for your software is important when it comes to shelfware, so make sure that you stick to that plan. Remember this the next time that you have gone through the stress and experience of buying a software solution, and know that you are prepared and have a process in place.

[This article was syndicated with permission from development testing company, Coverity. Coverity is the trusted standard for companies that need to protect their brands and bottom lines from software failures. More than 1,100 Coverity customers use the Coverity Development Testing Platform to automatically test source code for software defects that could lead to product crashes, unexpected behavior, security breaches or catastrophic failure. Coverity is a privately held company headquartered in San Francisco.]