Home » process

Removing features

15 April 2007 One Comment

I’ve heard that about 45% of features and functions in software go unused. As a developer, I have control over removing unused functions and I do so quite diligently through refactoring and the courage that I have to modify my code through the practice of test-driven development.

But I believe that unused features can have a significantly worse effect on the quality of a software system than unused functions. The more code you have in your system, the more complicated your architecture becomes and the harder it is to maintain. But the dilemma that many developers have is that they are being asked to add features by product owners who might not have a good feel for the repercussions of doing so. In other words, as a developer I can control how many unused functions I have in my code, but I cannot control how many unused features I have.

I have often wondered if product owners should be as diligent with requesting feature removals as they are with feature additions. In order to do this, they would need to have some insight as to which features are being used and which are not. I feel that this is where a separation in responsibilities between the development team and the product owner is necessary. Developers should be responsible for calculating which features are used and at what percentages. Product owners should be provided with that information and make decisions on feature removal.

Of course, it is often hard to justify or rationalize feature removal because it doesn’t seem like progress. But it is progress; progress towards the simplest system that meets the needs of the user. Building simpler systems ultimately costs less money. Product owners have the tricky job of knowing and balancing good business decisions with good software decisions.

One Comment »