Delete All The Codes

This article is about is not about writing code, it's about deleting code. Ok, maybe not all the code. But hear me out.

When I was in fifth grade and starting to program, I was fascinated by big programs. .EXE files that had megabytes in file size whereas my programs only had a few kilobytes. Professional programmers are able to write huge programs and that's a cool thing, I thought.

But, there reality is that code is a liability. As soon as you write it, is your team's legacy. A legacy in reality can be something good like a house but it can also be something bad like debts. In software development, it is quite often the latter, unfortunately.

Feed Your Code

One might think that code once written can just stay there for free. It doesn't do harm, right...right?

Code needs to be maintained. It needs love and care to stay healthy otherwise it might break and take your beloved app with it.

There are all kinds of things need to be considered:

• Upgrading to a new version of a library or framework that requires code changes
• Updating to a new version of the language you use
• Fixing security vulnerabilities in your code base
• Keeping builds green (timing changes might break things)
• Changing requirements might require changes in code that you thought you'd never have to touch again
• Changing infrastructure (e.g. new data base) might require changes (especially if the code is not decoupled)

The Best Code Is No Code

Where my younger me had a deep admiration for big program, my older me has learned that code that does not exist is actually the best code. It doesn't need any of the things discussed in the previous section.

I don't have any personal relationship to my code anymore (which is actually not my code by our team's code anyways) and so you shouldn't.

I actually feel happy and relieved deleting code.

Tidy Up

To delete code, I actually follow a couple of practices:

Boy-Scout-Rule

The Boy-Scout-Rule is a general practice of continuous improvement. It basically says: Leave the fire place cleaner than you found it. Or in more technical terms: If you are working on a part of code, try to improve things in the area that you are working on even if it is not strictly necessary for your current task.

That includes cleaning and deleting code. Most often, your editor or IDE will tell you about unused code. Delete it. No excuses. There should be tests covering it, if the code is actually necessary.

Refactoring

Sometimes you start with a new bigger feature and implement it in the most basic way (TDD, wink wink). But as soon as you add new features around that code, it might need some refactoring.

If you did it right, most of the time you should be able to actually delete a significant amount of code. For me, this is like the reward I get when I we did a good refactoring. It let's me delete code. I love it.

Zombie Code

This is a tricky one. You might have code that is used (by tests) but actually not in production anymore. So it looks like it is used but it is actually some undead code disturbing your neighborhood. This is the case e.g. when you have APIs that are covered by unit tests or even integration test but which are not used, neither by a UI nor by customer.

This needs a check from time to time. Could be done as a regular item in a team meeting or task in a maintenance sprint etc. Obviously, you could also explicitly deprecate APIs which are used by customers and mark them for removal.

Time Travel

You might say "But I might need that code!". You might also know the answer. Use your version control system of choice to get the code back. Yes, it might not immediately work but the effort to keep code alive is most often higher. Also, in 99% of the cases, no don't need that code ever.

Conclusion

Keep you code clean and tidy. Delete as much code as you can. Thank me later :)

Cover image by Ujesh Krishnan on Unsplash