Write deletable code
It may seem antithetical to software development, but I believe deleting code is often much more important than people think. The ease at which it can be done is often overlooked by engineering teams, so removing code is usually flat out tough.
Writing code is, however, usually pretty easy. Good code, bad code, adding it is the part that excites developers the most. It’s what we’re best at. Our job is to write code and contribute to whatever we may be working on. So doing the opposite and removing from the codebase simply feels backwards.
We can group our reluctance to remove code into two categories: 1) the wrong feeling you get from doing it, and 2) the technical unknowns and worries you have to overcome.
Selecting a block and hitting the backspace key feels wrong. It feels unproductive, it makes us feel like failures. We spent time writing this code, only to now be deleting it.
But what if we accidentally delete something unrelated in the process? Maybe we’re removing a defunct feature, and the code we deleted is actually shared amongst two features. Or, what if we want to reuse this code sometime down the road? Now it’s gone, gone forever.
We should fight these roadblocks. Removing code should feel right, productive, fine. It should also be easy, unexciting, and straightforward.
- Code that is deletable must first be well written code. Well isolated, readable, and testable.
- Removing code is required when refactoring, and refactoring is undeniably important.
- Smaller, more succinct codebases make introducing new team members easier.
- It’s easier to reason about code when there’s less of it, and when code is easy to reason about it’s easy to write, test, and debug.
What can we do to make this possible?
Or, what does deletable code look like?
- Our code must be properly isolated such that when deleting code, it’s obvious what we must delete.
- Related to #1, our code must be well tested. When deleting code we should be able to have faith that deleting one line won’t unexpectedly break something unrelated. Tests help us prove that.
- When adding or removing code, we should split our changes up into logical commits. Reverting additions should be easy, as should reverting incorrect deletions.
- As a prerequisite to #3, we should use Git or another version control system, so that deleted code can live in our history, and so that reverting deletions is possible.
- We should write clear code that is easy to reason about, so when we eventually delete it’s obvious what to delete.
This is in no way an exhaustive list of ideas, but it’s hopefully enough for you to consider and expand on.
The importance of removing code isn’t a new idea. I’ve actually visited offices with leaderboards on the walls displaying which team members have removed the most code. Additionally, many people smarter than I have written some great pieces on the topic.
I encourage you to consider the value in removing code, and keep the end in mind when contributing new code. Write deletable code. It’s usually hard, but it doesn’t have to be.