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.