Vestigial features are a common plague in software. There’s a special type of this that often goes unnoticed. Vestigial features are usually usable features that simply aren’t used. But under the hood, every system has some code that isn’t even exposed. It doesn’t support a feature users can access. It’s often the result of experimentation, or perhaps a vestigial feature that wasn’t fully extricated. I like to refer to this as dead code.
A little bit of dead code isn’t a problem. However, as the amount grows it can quickly get out of hand. And, dead code tends to grow, not shrink. Why? Because most developers are afraid of removing code. They would prefer to get in, make their changes and get out. All while disturbing as little of the system as possible. There are many reasons for this. They may not understand what the system should do. There may not be a decent explanation of what the system should do. They may not know what is and isn’t dead code. There might not be many tests to help them have confidence they aren’t breaking something important. They probably aren’t given the time to find and remove it. And if they ever make a mistake in the process of trying to pick up some of the garbage under the hood, they’re chastised.
Most version control systems are so advanced that every change to the system is instantly accessible even without an internet connection. And yet, it’s still more common to see developers comment out or leave dead code behind, instead of removing it. For many developers there’s simply no incentive to remove dead code, and instead, every reason not to. That’s why it tends to grow.
But why does it matter? It matters because it’s clutter. If you’ve ever visited the house of someone that hoards stuff, you can imagine what it’s like to study a code base that’s plagued with dead code. Imagine you need to find something in a hoarder’s house. It’s going to take a while. Same thing when we try to change a code base that’s overflowing with dead code. Dead code gets in the way of useful code.
Dead code isn’t always obvious. It has a tendency to impact how developers think the system actually works. Often, it requires studying the system in detail to uncover. Without the time to do this, dead code competes for the mental capacity to understand how a system works.
Dead code begets dead code. Dead code often uses other code. This code in turn may be dead code if it’s only used by other, dead code. Think of a hoarder’s house. That extra set of shelves, to store all the things they will never use. That extra set of shelves wouldn’t be necessary if it weren’t for all the clutter.
But it’s not just clutter. Because dead code is hard to recognize, developers will go out of their way to protect it. Just like the rest of the useful code in a system. And rightfully so, they don’t want to be reckless.
Possession doesn’t come without a cost, dead code costs real dollars to maintain.
Dead code makes it difficult to change a system. Refactoring, or what writers refer to as rewriting, is much more difficult if you have to consider the impact on dead code. Critical components of a system are constrained by dead code. These constraints get in the way of adapting to new functionality. Dead code tends to solidify and never change, thus anchoring other parts of the system. Much like anchoring a boat.
The secondary consequences can be disastrous. Dead code may accidentally be used when someone changes the system in the future. Because it’s dead code, it’s highly unlikely it behaves as expected. It’s likely incomplete and definitely not well tested. Consequently, using it can **introduce defects*.
Fortunately, it’s really easy to clean it up. Growing up, I loved weekend camping trips as a Boy Scout. After a weekend of fun, we did our best to leave the campsite better than we found it.
After a hard days work, leave your code a little better than you found it.
If everyone buys in to this philosophy, efforts will compound. Developers should keep an eye out for dead code. Managers should support, not discourage, developers. Before you know it, the dead code will vanish. Then, you can move on to bigger problems.