atomaka.com/_posts/2023-07-07-delete-your-code.md
Andrew Tomaka 3e3dbc2555
All checks were successful
Linting / lint (pull_request) Successful in 14s
Linting / build (pull_request) Successful in 15s
Revert "break lint"
This reverts commit 74edf4d8bc.
2024-07-12 23:04:54 -04:00

1.6 KiB

layout title date
post Delete your code 2023-07-07 13:20 -0400

One of the most consistent things I have observed over the last two decades while working with software engineering teams is an unwillingness to delete code. Functions and files left long after they have been replaced. Hundred line blocks of commented code held on to for years. Single purpose tasks kept in place just in case. We developers are always planning for the worst.

Don't get me wrong. I have lived the same life. Leaving around treasure troves of code I had carefully crafted just incase I needed it in the future. But what if the worst thing that could happen is that we have given ourselves more code to maintain. Or that we have left behind an outdated trail to follow that influences are decisions despite drastically changed requirements. Or that the dead code becomes a ticking time-bomb of likely untested code waiting to accidentally be interpretted.

Code is only an asset when it is directly providing the required functionality. Anything beyond that is a liability. Even if it is never run in production, it still needs to be maintained. It needs to be reviewed and updated when deprecations pop up, revisited when its automated tests start failing, or breakfixed when it somehow halts the application boot cycle. Every line that is not executed is maintenance cost waiting to be incurred that provides no value.

These days, I aggressively delete lines of my code bases as much as the teams I work with allow for. I strive for PRs that have more deletions than additions. And if I ever really need that deleted piece of code? That is what version control is for.