Programmers hate repetitive tasks. I mean, really hate them with a passion. Tedium is our number one enemy, and we're prepared to go to great lengths to eliminate it. And our tool of choice for that is task automation.
We automate our tests, our builds, our deployments, and our monitoring. We'd automate the programming too if we could. You could argue in some ways we're already doing that by means of abstraction: Programming in a high-level abstraction means automating the stuff that happens on the lower levels.
The thing is, just like premature abstraction is dangerous, so is premature automation.
One reason is that you just might not need to do it. You might not face the task a sufficient amount of times to justify the time spent automating it.
But the main reason premature automation is dangerous is that once you've automated a task, you stop learning more about it. Dan North has made this point on several occasions in a way that really drives it home. On the trade-offs of doing build automation:
By automating a build, what you're doing is you're saying: My knowledge of what it takes to build this thing is detailed enough and accurate enough that I can enshrine it. I can seal it in a build, in a script. Because once it's locked in there, I've locked in that knowledge, I've locked in my assumptions, my beliefs, my understanding of how that build works.
We tend to put automation on a pedestal. You have to have automated tests. You have to have an automated build. Automation is the thing. No! Delivery is the thing. Providing a capability to your stakeholders is the thing. If automation is useful, only in the extent that it helps you do that better. As soon as it doesn't, or if it isn't yet, then don't do it yet.
The metric I use – my heuristic – is "don't automate something until it's boring". Because boring means you've done it enough times that it's annoying you. You've done it enough times that you're probably screwing it up from time to time, cause that step 5 you keep forgetting. And you've done it enough times that you understand it. Now it's probably OK to automate it.
Dan North - Decisions, decisions from NDCOslo on Vimeo.
Builds and deployment are just one of the contexts in which you may fall into the trap of premature automation. Another example is something I've been doing recently: Gathering conversion and usage metrics of our product, Deveo.
Now, I'm a programmer, so of course I have a tendency to automate something like this right away: I just need a script that counts the number of new customers in this cohort, and how many logins they've done, and stuff like that. But I've tried to fight this tendency, because I don't know what the most useful metrics are yet. Whenever I go collecting the latest numbers, I may notice something else that's interesting, in addition to what I was looking for.
As time passes, this task might become boring because I end up doing the same thing over and over again. But I'm not there yet. So I'll just keep doing it manually for now.
Are you planning on automating something? Are you sure the time is ripe?
by: Tero Parviainen