When we settled with a standardised approach on how to do the work and we simplified it as much as possible, we can finally enter the phase of automation. In this last phase we face a new set of challenges that may left you baffled. Let us explore the traps so that we know what to look for.
A small reminder
We get the biggest benefit with automation when we automate things that we do often. The more we do a process, the higher the return of our investment will be. This is a heuristic and not an absolute rule, but when in doubt, start automating the processes that you do most often.
Should there be no clear priority based on the number of executions, you can go for the processes with the most manual steps.
Reduce risk with automation
There is another reason to automate a process: risk reduction. Processes that are complicated and high-risk, but we only do them a few times a year may still profit from automation. Here we may not gain much efficiency or save a lot of money, but we can reduce risk. The automation creates a documentation of the process and with its repeatability it can prevent us from doing the steps in the wrong order or forgetting about them entirely.
Do not automate things you do only once!
When it comes to automated code generation, we end up with an interesting conundrum. First, we get scepticism from the developers and hear that the automation is not possible at all. After this wave of resistance, things start to change and jump to the other extreme – now everything should be automated.
The first part that now everyone wants to jump on to automate is most likely complex, complicated and a one-off thing. The combination of high-risk tasks with next to no knowledge about automation will end in a disaster. Go ahead with this second wave only when you want to ruin your automation project.
It is understandable that developers want to work on difficult and interesting problems. And they should, but not when it comes to automation. The goal of automation is that at the end we no longer need to do the now automated task by hand. Therefore, glue-code and code we only write to satisfy a pattern are great candidates to be automated. On the other hand, important logic that gives the business an advantage is not a great candidate for automation, then here we expect a lot of complexity and many changes over the lifetime of the application.
If you need a piece of code only once, do not automate it. The automation of something we only need once is a complete waste of time. We need to write it once anyway, and the automation only adds unnecessary complexity for no gain at all. Then unlike a process we seldomly do, the code itself documents the different steps already. There is no need to automate for documentation when the code documents that aspect anyway.
The big exception: data migration
In an ideal world we only would run a data migration once. And while it is the goal to do exactly that with the production data, there will be a lot of inconsistencies and problems that show up. Therefore, it is a safe bet that any meaningful data migration project will need to run multiple times to weed out all problems. That is why we should automate a data migration project right from the start and despite its intended single use.
Repeatable code generation
You can gain a lot with automated code generation, even if there is no way to regenerate the code once more. However, to fully profit from the automation, we should settle only for approaches that allow us to regenerate the code should new things pop up. If we learn more about the problem, we may want to incorporate that knowledge into the code. It would be a waste of time when we must make those fixes manually.
We had that situation as we found a security bug in one of our repositories. Instead of going thru the application and repeat that fix left and right, we fixed the generator, rerun it, and got all repositories fixed in no time.
When it comes to security problems, speed matters. Our automation can help us to get that speed. But even if the problem is not security-related, when we can fix one generator and apply that change everywhere, we make it much simpler to introduce new knowledge into our code base.
A partial automation is better than a complex solution
As soon as we get the automation rolling, the next danger awaits us: the automation of the specialisations. While we can solve most of the goals we have for automation with a direct approach, there will always be the last one or two little things that lead to an explosion of complexity. To automate this last bit may require us to write ten times more code. Try not to fall into that trap.
Instead of automating all the specialities, we may go and solve that problem with a partial automation. If we need to get meaningful test data for our generated integration tests, we could make an elaborate list of what values to use in our generator. A much better and faster approach is to automate the call to a test data generator. We then can write that test data generator by hand and find the meaningful data that we return to our automated code. This gives us the flexibility to use specific test data while our code generator keeps the logic at a minimum.
The manual work we need to do once is neglectable compared to the additional work we would need to put into our code generators.
Next
To succeed with automation, automate the boring, repetitive tasks. That gives you the quick wins and you can then focus on the more challenging parts that you want to do manually.
Next week we put this theory into action and create an automated code generator with the T4 template language.
1 thought on “Automate the Repetitive Work”