Temporary Applications

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 your primary application, it is far more likely to contain bugs, inefficiencies, and the like, simply because they haven’t been caught (yet). In a social sense, your temporary application will be blamed for any problems that occur in the main system if it was run recently or touches the area that broke. Logs help you disprove this assertion.

Idempotency is critical

Realistically, you may have to run your application multiple times. This means that any data changes that your application makes should not cause problems on subsequent runs.

Be aware of situations where you are updating records to set their values to their current value; if your audit trailing strategy is not great, you can end up with a lot of noise in your logs. Also be careful of anything that your main system might send out in response to a change (such as notification emails) and make sure those don’t happen, or that you can keep them from happening.

Try to include a rollbackback mechanism

Requirements gathering for one-off applications tends to be sparse and rushed. Its likely that you will have to stop the process, or attempt to undo your changes. Expect it. When rolling back, unless your work is already in a single transaction, make sure that you are rolling back to a correct state before committing.

Break your process into steps that can be executed, stopped, and restarted independently if it takes a while to run.

You will want to verify your work in smaller steps, just to decrease the number of things that can go wrong. If one of your steps is particularly demanding on system resources, you may need to run it off hours. If things are broken into smaller steps, this might mean that you can run some of them in advance, meaning less time stuck in the office after hours.

Prefer queueing mechanisms to loops and separate execution of the queue from filling the queue.

Transient failures are the bane of temporary applications. Try to use structures that mitigate some of the problems. Such mechanisms make it easier to scale if you need to do so, which was likely not considered when you planned the application. Separating the thing that fills the queue from the thing that processes the queue can allow you to fill the queue during business hours while processing it after hours.

Have an audit/simulation mode for your application

Nothing is worse than the feeling of wondering whether something will work. Being able to simulate the work helps. This is especially important if the app lives longer than expected and needs to be run again in the future. Breaking things into steps can help with this, especially when combined with robust rollback mechanisms and/or testing databases.

Allow restriction/configuration of the dataset that you application will work with.

Don’t hardcode things in a temporary applications unless there is no possibility of them changing. The app may get run again on accident. You will likely also find that you either have to repeat a run of your application with a smaller dataset, or a different dataset. Basically, the idea here is to make it relatively easy to re-run the application again later under different circumstances, without code changes.

Allow invocation of your tool from within your application

While it may not seem like it is worth the effort, allowing your one off code to be run from within your application makes it much easier for other team members to do it. This practice also gives you tighter integration with the app, meaning that your code isn’t forgotten during system changes and refactorings. This approach can also make QA efforts around your code much easier.

Allow partial application of application processing results, along with restarts.

Unless your one off requires that the entire system be in maintenance mode for the duration, your code should ensure that each state change leaves the system in a valid state. Basically, you want to avoid transiting an invalid state so that you can avoid errors and can restart safely at will, instead of having major failures and having to run your code at an inopportune time.

One thing that can help with this is the use of staging tables to arrange data before using another call to actually change records. Separating the loading of data from the updating of data can limit the amount of time your app is in an invalid state if you can’t avoid it entirely.

Have a mechanism for providing statistics when the temporary application completes.

You should be able to tell how many records you touched, how long it took to touch them, as well as the count of any side effects. If you can’t, it makes it hard to prove that your code worked, especially if you aren’t the one executing it.

This is also important for subsequent runs. If someone asks how long it takes to do something, being able to give an intelligent answer can keep you out of trouble later. Be sure to include this for rollbacks as well – you want to make sure that you fixed as many records as you messed up.