We all had to do it at some point. We’ve all been in the situation where we needed to add some code — maybe a CLI command — just for a one-off operation. Or maybe the code would be needed just for the next month.

We promise ourselves to get back to the code in 1 month and remove it. We may even set an alarm for it so we don’t forget. I never missed an alarm before, have you? </sarcasm>

When writing such code, there’s always the risk that this code will stay in your codebase way longer than needed and anticipated. The team may eventually forget the original purpose and consider it a permanent part of the codebase.

These temporary pieces of code usually don’t follow the same quality standards as the permanent codebase. Maybe we were less careful when writing tests, or maybe we didn’t follow some architectural guidelines we would have followed with permanent code. Makes sense… we didn’t expect to maintain this anyway, so why spend effort in making it maintainable.

“So what?” you may think. It’s just a small piece of code, nothing compared to the 1000s of lines of code we already have that do follow proper standards. But this small piece of code can be the start of something worse.

Clean up the mess

Compare it to keeping your house clean. If you allow yourself to not clean up a small mess in your house before you know it things pile up, the small mess becomes a big mess, and you’ll need a big cleanup action. It’s better to not let it come to that.

One of the virtues we like to promote is radiating intent, as a team member and in our code. Our code must scream what it is and why it’s there. It should not only be a way to make the computer do something, but it should also communicate to our fellow programmers what it does and why it’s there.

Is our code meant to last or is this legacy code?

Usually, we think of this communication in business terms. What concept inside the business does this class represent? Which bounded context or module does it live in? We want this all to be visible in the blink of an eye. But we rarely speak about whether our code is meant to last. Perhaps we should start doing that more.

In addition to setting an alarm, why not make your code scream its temporary nature. Why not call your class TemporaryCliCommand. We could radiate even more intent by adding a removal date to the class name: TemporaryCliCommandCanBeRemovedAfterNovember15.

An additional advantage here would be that people will not accidentally start using this class in their code. Of course you don’t want to give every class you temporarily create such an elaborate name.

Annotate your temporary class as deprecated

To make sure other team members don’t accidentally start using your temporary class, you can annotate it as deprecated. Your IDE should recognize this and will cross out the class name when autocompleting.

We can make additional changes and move our code outside the permanent codebase. Next to our app/ or src/ directory, why not have a temporary/ directory, where we can organize using namespaces such as FixNewYearsBugToBeRemovedAfter1January2022?

Even if you forget to remove your temporary code, it will live a bit further from the permanent codebase and your colleagues will know whether this command can be safely removed or not.

So I hope these couple examples help you when adding temporary code to your codebase. Hopefully, that code won’t live happily ever after.

More guides on coding principles and good practices