Temporary Applications

We’ve all been there. Your boss tells you to write a “quick and dirty script” to move some data over from another system, help onboard a client who has an unusual setup, or simply process some records that have something wrong with them (often from another one-off script that someone else wrote a while back). You could just write the quick and dirty code and go on with life, however, you also know about several “one-off” scripts that have become semi-permanent residents of your codebase. Odds are also good that these scripts have been a source of frustration and weird errors for most of the time you’ve known about them. In development, we have to constantly fight the temptation to treat certain parts of our code as being less worthy that the rest. These “second class citizen” pieces of code are considered less important, tested less thoroughly, and are often given much less attention when it is time to refactor or clean up code. They may include reports, testing scripts, build scripts, support tools, one off applications, data import/export scripts, and the like. While it’s easy to rationalize treating these things as less important, it can often come back to bite you. However, due to them being used less often (or less prominently…), you may not be able to always give them the full attention that you would give to the flagship portions of your application. This is especially true of one-off scripts or small short-term applications, because you are told from the outset that they won’t be around for very long. Thankfully, there are some things you can do to make these kinds of applications and scripts a more sustainable part of your development workflow, for however long you end up keeping them around. If you do it correctly, you may even be able to salvage the script when management “discovers” that it really should be a permanent part of your application. Best of all, these practices can also help ensure that your “one-off” script or application doesn’t end up being a huge maintenance burden for however long you keep it around. We all have to build and run one-off applications and scripts from time to time. While you can tell yourself that you are only going to need the code for a single instance of a single issue, your own life experience will tell you that this assertion is false. Further, because you are actually touching code in a production environment, you need to go to a lot more effort than you would in a development environment with data that isn’t critical to the business. Finally, you also need to make sure that other people can safely run your process and that they can reason about it in the event that you aren’t there to monitor it. Episode Breakdown Keep the code with the main body of your application in the same source control repository. There are several reasons for this. First, this makes the code accessible to the rest of the team, which means they can run it while you are on vacation if that is required. It also means that other people can review what the code did, which can often help troubleshoot when a weird error occurs due to data modifications that weren’t made in the main codebase. If you are using a language with strong compile-time checking, this also makes it easier to keep your code up to date with the rest of the system so that it can be used without having to change it as much. This also exposes your code to your test suite, which means that you could make sure that it has tests around it. Log things at least as well as you do in the main application, if not better. Because one-off applications and scripts are often run outside the main application, much of your main application instrumentation strategy will not apply here. Also, since the code won’t be run as frequently as yo...