Unused Functionality

It is common to have as much as 50% of an application not used. Imagine the amount of time and effort spent on creating functionality that is not used. The reason unused functionality was created in the first place is due to a lack of understanding of the customer problem and solution. When software developers do not understand the industry domain, they have a difficult time understanding the problem and an even harder time coming up with a solution. There is a tendency to stumble around developing functionality in the hope of solving the problem.

Software developers need to study their software applications looking for what functions are being used and what functions are not being used. They need to examine how users click through the applications. I often look at the traffic on my website. Using Google Analytics I can get nice reports on the most popular page and on how people click on pages. I can get a good understanding on the pages that people read and those pages nobody ever reads. I don’t want to spend much time creating pages nobody ever reads. The same type of strategy needs to be employed for software applications.

I was working with a client who spent hours working on a series of reports. The reports were requested and designed by the client liaison. Once the reports were implemented, the client went back and examined the number of times the reports were viewed. To great astonishment, many of the reports were never viewed. It should be obvious that developing reports or any functionality that is never used is a waste of time and money. The client liaison only thought these would be useful reports.

Perhaps the most horrendous story of unnecessary functionality was with a Hospital Information System (HIS). The HIS unified and streamlined hospital functions. One of the features was if a patient had included an email address with the hospital registration, then lab results were automatically sent via email as well as to the physician. Some patients received emails notifying them, that their tests for cancer were positive. Just because something is technologically feasible does not mean it is a good idea.

Not long ago I purchased a heart monitor to be used during exercise. I ended up purchasing one with what seemed like the most functions. I ended up not using all those functions and honestly, I ended up not using the heart monitor at all. There may be functionality intentionally developed that is not used that helps a product sell. The idea is creating functionality that the potential buyer likes and is impressed with but will never use. I am not sure this is a good business strategy.

Redundant Functionality

It is common for software applications to have redundant functionality. As software projects start to grow, it is hard to keep track of all the functionality being developed. This causes redundant functionality to be created. The functionality may not be exactly like other functionality, but they are close cousins. The point is, both pieces of functionality were not need.

Missed Functionality

Since the developers know little about the industry domain, they often miss large chunks of necessary functionality. It is common that missed functionality is discovered during the testing phase of a project. Typically, this is the first time customers get to see a working product. When the missing functionality is discovered during the testing phase of a software project it may be difficult to go back and implement the missed functionality.

Some organizations adopt a change control strategy. The problem with change control is it does not address the root cause of missing the requirement in the first place. Change control is an attempt to control spiraling costs and it frustrates customers too.

The code/test and change control strategies are just treating the symptom of missed and incomplete requirements. Neither tries to understand the root cause of missing the requirement in the first place. Those software organizations that study their customers experience growth rates that are one tenth of those software organizations that do not study their customers. They range up to 30 percent compared to 300 percent or more growth rates.

When developers learn the core business many positive things start to happen. The first is projects have much less growth rates and there is less functionality created. Their productivity rates are much higher, time to market is faster, and their products are of higher quality.