Being Realistic about IT Automation Benefits

I'm a massive fan of IT Automation and I really enjoy doing it (especially the coding part), but at the same time I am realistic about the benefit of it.

I think there was a quote “if you do anything more than twice (in IT) automate it”. This is a fine thing to say, and yes, in an ideal world where you have the time to invest to automate all your tasks, it makes 100% sense, but in the real world it does not necessarily make sense.

My point is best illustrated with an example.


Say I have a manual task, this manual task takes up 10 minutes of my time, and I have to do it every week. So that's 520 minutes a year.

Now, say my manager says “you must automate it”. Okay fine. But how much time do I need to invest in automating this process.

Say it takes me 40 hours to automate this process (2400 minutes). That means that to start saving time, it's got to have run for over 4.5 years (2400/520). And that's not considering the fact that the automation might need updating in that time, constant monitoring that it runs, troubleshooting when it doesn't...

My point is this:

When considering automating something, also consider the investment in time in creating that automation, and when you will start to see time savings from that automation. Unfortunately this seems to get forgotten in the drive to “automate everything”.

Q: How much time is being spent creating the automation?
Q: When will you actually start saving time from the automation?

Some automations will never save time. Still, a benefit in going through the process of automating something that will never save time, is that potentially you develop tools and methods that can be used to automate something of more value in the future, and that thing will have clear time saving benefits.

Don't get me wrong though, there are massive benefits to be had in IT automation. Some task that regularly needs to happen is a perfect candidate for automation. Or a particularly complex task that won't happen often, but when it does happen you don't want it go wrong (like a Disaster Recovery workflow), is also a good candidate for automation. And many other cases...

DevOps Doesn't Work With Everything

I also think some people are getting too caught up with the word “DevOps”. DevOps is great for software that needs/benefits from constant evolution. But for a write once and forget application, there's really little point in shoe-horning it into a DevOps process, it just complicates things and wastes time.

End of ramble.


  1. "Never spend 6 minutes doing something by hand when you can spend 6 hours failing to automate it."

  2. Hello Vidad,
    I found this very similar to Solar Energy also. You will only start to retrieve benefits at certain point... But in IT clock probably when you get there, the solution is already different and you have to re-code again.
    Maybe sharing the code...could help others to automate the same thing, and that i think is the way.


    1. Hi Pedro,
      I totally agree that sharing the code would be the way forward. Alas, a lot of awesome code is developed within the walls of large enterprise or secure customers that will never see the light of day.
      Really, every IT person needs to have a blog, and when they do something interesting/useful, they should post it on their blog (removing any customer specific stuff and heeding intellectual property laws), then one can just google and find loads of awesome stuff :-)


Post a Comment