We’ve been building our flagship application (RoofWright) for nearly 15 years now. The bespoke nature of conservatories and windows makes specification extremely complex. And we’ve learned a great deal on the way.
More features often equals more complexity
Features = Sales
Over that time we have added thousands of features, the majority of which were required by one or more customers. This has resulted in a very large number of satisfied customers. And each new feature means we may gain access to additional customers.
However, each time a feature gets added, the software gets a bit more complicated, which may in turn put off some of our existing customers. Over time, the customer who originally requested the feature may not be a customer anymore, or may operate differently, and no-one else may ever need it again.
Evolutionary Baggage
Unfortunately, it is almost impossible to work out when a feature is no longer required, so it gets left in, even if no-one ever uses it. A bit like the way in which humans have retained the appendix although it’s original function (the digestion of foliage) is no longer required.
An Alternative
Almost all long-running software businesses have the same problem. The cost and risk of removing a feature may exceed the short-term cost of leaving it alone. And it’s not a very exciting thing for developers to do, so it rarely happens.
One potential way of identify unused features is to add accurate auditing of feature use. This would involve recording the frequency of execution of each routine in the software, a bit like a software version of the measuring strips put across roads to measure traffic volumes and speeds. This is almost certainly a candidate for automation,as doing this manually would be infeasible. Assuming that the software is properly factored, any rarely or never-used routines would indicate potential simplifications. It would then be a matter of careful analysis before culling any unused feature.
Another Alternative
There is another alternative, but it’s much harder to bring off. Rather than adding features, it can sometimes be better to generalise what is already there. For example, replacing special-case switches with lists of expressions (which could be empty much of the time). This will mean less confusion for the majority of users who don’t need lots of special extras.
My money’s on this approach, and we’re definitely going to do more of this in future…
