Remove Dead Code

I enjoyed this article on the importance of removing dead code as part of managing technical debt. In the article, which is an interview with Kevlin Henney based on a talk he gave at the European Testing Conference 2017, Kevlin gives the example that some of us may have heard about where unused code in the New York Stock Exchange system caused $440MM of losses in 45 minutes when it was mistakenly awakened by a 3rd party high-speed trading system.

Obviously an extreme example, but the root cause was something that any developer can relate to: code that is unused, in this case for years, but not removed from the system. Dead code is something I specifically look for during code reviews. When I see that a new method is created and some code is changed to call this new method, I always look to see if the old method was deleted (often it wasn’t because developers are focused on the new functionality only). That old method might still be used, and if so it is good to stay. But if the caller was the last reference to the old method then I request that the old method be deleted. Not commented. Deleted. One can always recover the old method from source control.

Removing old code reduces the extra noise and makes the code easier to understand. It reduces the amount of code that must be maintained long term (baggage) for things like dependency updates or source quality rule updates. It also results in fewer tests (less code to test) which decreases the test automation bed run time. All good things.

The best time to delete the dead code, as is the case with most technical debt, is when implementing the change that renders it dead (keep a clean kitchen). Sometimes it may not be obvious that the old code is now dead. It may take some research to see if the old code still has other references, but with ability of most IDE’s to quickly show method references, it is easily worth the time for the long term health of the system.

The other excuse I sometimes hear on not cleaning up the code immediately is to wait and make sure the new code works as expected. This is just like commenting out code inline. If you thought it belonged then you wouldn’t have commented or developed a replacement. As I mentioned above, remove the code and utilize the source control system as it was intended, to keep past state.

In summary, you wouldn’t want that code to cost your company $440MM would you? Make removing dead code part of your standard development process.

Like what you read? Give Brandon Bryson a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.