Over a million developers have joined DZone.

My Views On Automation

DZone 's Guide to

My Views On Automation

My view is that automation should be used primarily for consistency. But how should you decide what's worth spending the time to automate?

· Agile Zone ·
Free Resource

One of the things I like doing at my job is automating repetitive tasks. For example, when a particular error occurs as part of the morning health check, an email needs to be sent out to the business owners of the source application (I work in middleware) to notify them of the situation. (I know I'm doing it wrong – Special Cause/Common Cause, burnt toast, etc. – but that's the situation I'm in.) The process was manual, meaning extract the relevant data, compose an email, and send it out. All in all, about 5 minutes worth of work. Not long in the grand scheme of things, but very boring. So, I automated it. Now an email gets sent out automatically every morning. We don't have to worry about it anymore.

Now, many times when you want to automate a task, there is the argument of "is it worth doing or not?" comes up. In the above example, we are saving a task that only took five minutes a day. How long should we spend automating this task? One hour, four hours, one day, one week? For the record, it only took me about 20 minutes for the first version, then about another 20 minutes over several days to get the formatting right for something so trivial.  Then again, let's look at another scenario. Say that you have a task that will take you five minutes to do. However, after automating it, the automated process itself takes an hour – not the writing of the process, but the actual execution. Should it have been automated? 

In both these cases, there are arguments against automation because the time involved to either build or run the automation takes too long. In my view, you are looking at the wrong metric. 

My view is that automation should be used primarily for consistency. Spending a day on writing an automated script that saves five minutes will mean that that process will be run consistently forever and a day. The secondary benefits are that you don't have to worry about the process anymore, at least until it is no longer required. You have the knowledge on how it was automated which can be applied to automating future tasks. Finally, if you are lucky, the task may run quicker. 

The same goes for a task that takes five minutes manually, but one hour automatically. You have the primary benefit of having the task consistently done. Human error has been removed. If the task needs to be done in a quicker time, then spend the time optimizing the automation script. 

Now, there are always exceptions to this rule; there always are. You have to use good judgment as to when to and when not to apply the rule.

Now, how do you determine what priority to automate? I'm not talking here as a manager (I'm not one) but as a person doing the manual work. I work on one simple question. "What annoys me the most at this point in time?" I then spend time outside of my normal tasks trying to make that process better. Then I repeat. For the more common tasks, they get fixed pretty quickly. If they are not fixed properly, it annoys me and I go through the process again. For tasks that have long periods between them, I start working on them. I may not finish, but I document what I have found for the next time the task occurs and then work on it a bit more then.  

The benefit of asking, "what annoys me at this point in time?" is that it is something that directly affects me. It becomes personal and thus I'm more likely to fix it. That is not to say that management cannot assign improvements, but generally, they are not the ones doing the daily work and therefore do not see the pain points. 

automation ,agile ,software development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}