atomaka.com/_posts/2023-07-07-delete-your-code.md
Andrew Tomaka 864374959e
All checks were successful
continuous-integration/drone/push Build is passing
continuous-integration/drone/tag Build is passing
Linting...this is why we have PRs ( ͡° ͜ʖ ͡°) (#7)
Reviewed-on: #7
2023-07-07 13:28:11 -04:00

32 lines
1.6 KiB
Markdown

---
layout: post
title: Delete your code
date: 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.