What Do You Do When Your Mind-Numbing IT Job Should Be Automated?

jfruh writes Not everyone has a job like Homer Simpson, who's been replaced at various times by a brick tied to a lever and a chicken named Queenie. But many IT workers have come up against mind-numbing, repetitive tasks that probably could be automated. So: what do you do about it? Well, the answer depends on how much power you have in an organization and how much your bosses respect your opinion.

And who the fuck will maintain it?

[Anonymous Coward]

I always hear managers and programmers say, "We'll just automate it!"

But that's usually the easiest part of the whole process. They rarely look beyond it, to the maintenance phase.

The maintenance phase, of course, often lasts far longer than the implementation phase. It often outlasts the people who pushed for the automation in the first place, and the people who initially implemented it.

No automation is perfect, and no surrounding environment is static. Things will break, or change will eventually be needed. And this is where automation can often fall flat on its face.

I can't count the number of times I've seen companies with scripts or apps that perform some simple operation, but it only saves a few minutes each day. Yet at some point something with the automation breaks or needs to be changed, but the original developers are long gone, and now some other developer has to investigate.

This poor developer will end up needing hours, days, weeks, or even months in some cases in order to find out where the fuck the script or app is running, where the hell the most recent version of the source code is, how to get it running on a development system, and how it works, all before being able to make the fix or the change. Then it takes time to fix it or make the change, plus some time for testing, and then it needs to be redeployed, and finally it needs to be monitored for some time.

So the automation saved maybe a few dollars a day. Yet just a single fix or change to the automation can end up costing hundreds, thousands, or even tens of thousands of dollars once all is said and done. Merely one small fix or change can literally wipe out any cost savings that the automation has ever brought in the past, and then wipe it out for the next few years!

It's all rainbows and roses to claim that "documentation" or "training" or "best practices" will solve these problems, but even when those are in place and actually working, they rarely reduce the actual cost of maintenance.

So do some real analysis before screaming, "JUST AUTOMATE IT!" The cost of even simple or minor automation can quite often far, far exceed the benefits it'll ever bring. Maybe it's better to have the intern or low-paid employee just do the work manually for a few minutes each day.

Re:And who the fuck will maintain it?

[Anonymous Coward]

Please mod parent up! There are some decent points in this posting, regardless of it coming from an AC.

I've spent a good 15+ years doing process automation. And process automation itself is indeed a process. It's significantly more than some server monkey slapping together a script together during lunch to do something. Don't get me wrong; such an approach is fine if it's going to sit on an admin's machine and be used every once in a while. But once enshrined in day-to-day operations, the game changes.

What are the specifics that the script is going to do?
What is the "Happy Path" operation of the script?
How will common / uncommon errors / exceptions be handled?
How will the script handle unknown or unexpected errors (ie. is it written to be resiliant)?
How will the script be monitoried (e.g. snmp stuff) to ensure it hasn't choked?
Where are these scripts being maintained and managed (ie, groupings of P.A. scripts in version control)
WHERE IS THE DOCUMENTATION ABOUT THE SCRIPT?

Stuff like that.

Do some planning. Be a software developer about it. Just because it's a [Perl | Python | Groovy | Bash | DOS ] script does not mean it should be treated differently than compiled source or a more complex app.

Do you need to turn this into a full-blown project, with 8x the overhead of just writing the damn script and sticking it in place? No.
Do you just write the damn script and hope for the best? No, not if you want the system to die a horrible, disfiguring death.

So, put a bit of planning into what's being done. Prove the script out first. Test it (remember that?). Manage it.