Refactoring code without modifying its external behavior is necessary to keep your code base manageable. That is nowadays a well-established fact.
However, it can only go so far to prevent your code base from swelling permanently. In theory, if your revenues keep growing, you can keep recruiting more people in your development team, and all will be good. Unforunately, that’s not usually how software works.
Like many other things in life, software goes through well-known phases: birth, growth, maturity, and decay. At some point, the costs of maintaining the software are just not justified anymore and the editor pulls the plug.
However, we can do a little better than that. If the project still has some life in it, it can be a better plan to reduce its complexity, in order to lower its maintainance costs and increase its life. In fact, there is no need to wait for the product to decrease in popularity. Housekeeping should be done as early as possible in the lifecycle. No need to maintain features that cost more than they pay.
My current customer has exactly this problem. Their project suffers from feature creep. Regression tests become more and more costly to maintain (it is actually planned to delete some of them regularly — though, of course, nobody really knows which ones we can afford to throw away).
I would call the activity I’m promoting “Feature Refactoring: the process of changing a computer program’s list of features (and corresponding code) without modifying revenues significantly” (balancing short- and long- term revenues). This means that it is OK to remove some features, as long as it is acceptable to your customer base, in terms of money to make in the long term. Basically, you want to avoid the classic pattern where 80% features that are little used or not used at all.
Note that I am not merely talking about features representing significant weight in terms of code, tests, or documentation. Rather, I want to target anything that costs money to maintain, understand (for new hires), market, etc.
How can we do this? Well, here are a few smells that can help
- your client representative tell you about it — the easy scenario
- you detect that few customers actually use your modules – monitoring tools can help you here
- you find bugs in production… and few people actually complain about it — should this feature be there at all?
- you upgrade your project… and nobody complains — if your features are popular, someone is bound to complain about any change
- specs for a particular feature are not updated — features that do not evolve tend to rot
- run workshops with customers — a interesting format for this is Speed Boat
My point is that there are even more potential benefits in term of code maintenance when removing features, compared to refactoring the code base (which is a good thing to do, too).
Refactor your features. See this one there in the corner? You Aren’t Going to Need It.
You’ll be happier. And you will probably save money.
