Removing Kode

Dear KV,

Your columns often discuss issues that come up when adding new code, but when is the right time to remove a piece of code? I have been working on an enormous legacy code base and most of the questions that come up in our stand-up meetings concern which modules we think we can remove from the system.

Ready for Removal

Dear Ready,

I am surprised and amused at the narrowness of your question. Most software developers, when confronted with a legacy code base, simply want to throw it out and start again. I have to say this happens to me at least once a week, just looking around at the astounding mountains of legacy that pass as software.

Removing dead code from systems is one of KV’s favorite coding pastimes because there is nothing quite like that feeling you get when you get rid of something you know was not being used. Code removal is like cleaning house, only sometimes you clean house with a flamethrower, which, honestly, is very satisfying. Since you are using a version-control system (you had better be using a VCS!), it is very easy to remove code without worry. If you ever need the code you removed, you can retrieve it from the VCS at will.

As to when you should be removing code, there are several answers. The first, of course, is that if you have truly dead code that can no longer be reached from anywhere in the system and that is not simply conditionally compiled-out test code (see my February 2017 column, “The Unholy Trinity of Software Development”) then that code should be removed immediately. A good compiler or other tool will tell you when you have dead code, which should make the job fairly straightforward.

Complications arise when you have code that is infrequently used but has been in the system for a long time. At this point, you have to do a bit more thinking about your code and whether or not the code you are looking at is—for want of a better term—nearly dead. Any system that survives for a number of years will tend to grow functionality that is used—sometimes briefly—and then discarded or ignored. The logic for not removing dead features is usually stated as, “If it ain’t broke …” which is actually quite foolish. If your software is so fragile that removing a feature breaks the whole system, you have much bigger problems than needing a bit of code cleanup, and that means the system as a whole probably needs rototilling if not an outright rewrite.

A dead feature is different from a dead function. Dead features are either completely unused or used by only a minority of users. The risk with dead or nearly dead features is that they leave a larger attack surface in your code. Once upon a time, we also cared that dead features left code in the executable that bloated the system, but only those of us working in the embedded-systems area seem still to care about that. For modern server-based systems, it is the risk of the dead feature giving an attacker a place to infiltrate your system that is probably preeminent in your mind, or at least it should be.

Sometimes a dead feature will have a noisy minority of users or an internal champion who has tended that feature for many years. At this point, the removal becomes a political (that is, human) problem. There are several ways to solve political problems at work, but some of those will get you 10 to 20 years in jail if you carry them out. If the noisy minority is very small, it is possible that feature could be broken out into its own separate program so that the code is no longer part of the larger whole. If the problem is developers, well, it is time to give them a new challenge, far away from their pet features. Once you have developers with pet features, you have a very different sort of management problem, one I will not address here.

You will notice I did not give you a definite timeline in answer to your question, and that is because there really isn’t one other than removing truly dead code as soon as it is dead. For feature removal, that really depends on how you deal with your users and developers. A good rule of thumb, though, is to remove features only at a major release so as to limit the level of surprise.