I have recently been tipped by one of my colleagues to this article. It is an UX-perspective about avoiding to add too many features to a maturing product. It has many noteworthy points, among them:
However, we reached a point where there was just no more room for new features. Adding another feature was no longer a 1-hour job. Where to place that new button? How to explain a new feature to customers? Our overloaded product was also much harder to maintain. A small change in one place could easily cause a bug somewhere else.
Along with the product’s new features, its number of use cases grew exponentially. We were surprised by some of the ways in which people used our product.
Complexity is the enemy of every maturing software product, I believe. Good architecture, modularization and thorough automated tests help – but at least I have never seen the beast of added complexity tamed completely by those techniques, I am afraid :-( .
The article also does contain some advice on what to do when you realize you have a bloated product with too many features. It is a bit scattered across the article and I don’t agree with it to a certain degree – which is the reason for this post. Let’s get down to the details, here is what you can do:
- Hide features from certain customers and give them only what they need
- Remove features from the application completely
- Rewrite your application from scratch
The problem I see with point 1 is that it does not solve the problem. The application may look less cluttered – but the complexity remains. If you have gone down that path, different customers will want to have different feature sets – and now you suddenly have to test not one application, but many. The number of potential versions of your application that will need to be tested doubles with every feature switch you introduce. The only chance I see to survive here is to have good automated tests for every feature, as otherwise your testers will drown in feature-switch hell. Then, and only then, this can work out.
Point 2 is also not easy. To be fair to the article, it does not say it is ;-) . Even though your customers are probably only using 10% of your applications features – all of them are using a different 10%. So whatever you take away will be leading to difficult conversations and potentially lost business. There are companies who can afford this and there are companies who cannot – you have to judge that yourself.
Last but not least, rewriting from scratch. Uff. To be honest, I am not a big fan of rewriting from scratch. Your code may be ugly and bloated – but there is probably a reason for each of the work-arounds in there – and the reason is probably not documented anywhere anymore. Yes, I know that should not be the case and we should all be having fully documented and tested code-bases – yet, we all don’t have that luxury and need to cope with what we have :-) .
I believe in another way: refactoring your existing codebase, one piece at a time. Take away small features where needed and see what the reaction is. If your customer base is screaming, it is easy to get them back, as they are still in your revision control system. If you had rewritten from scratch you would now be scrambling to implement the features you had deemed unnecessary again – and all of them at once. Seen it so often it is not even funny anymore ;-) . Iterating over what you have is the better and more sustainable way in practice, I believe.
Of course, sometimes this is hard to do or even impossible, e.g. when you want to change technology completely (such as going from a desktop app to a web-application). Or maybe it is hard, because the UI needs to be rebuilt completely and just nothing fits anymore. Or your code is really so broken beyond repair that even refactoring appears to be a monumental task only a magician could achieve – but then I guess you have bigger problems than bloated UI’s to worry about – e.g. the quality of your workforce. But that is definitely a topic for another post and would go too far here…
