I always keep a manual safety step for unofficial automation for this exact reason.

Current example: I have a script I run for my wife that de-duplicates some data against historical excel files and submits it via an API to Mailchimp, to tag members for a triggered email. I run this manually for her about once a week. It does not alter anything unless I supply the '--go' option. That lets me check the output to see that it makes sense (sometimes they add extra data columns or she forgot to do contact/tag setup on her end).

I absolutely never have the computer run stuff without me watching unless I control the entire process end to end, it's non-critical, or management has requested it officially so I can point to specs when it goes wrong. Usually when I have a semi-automated process that is proven to work, then that's the time to bring it up with management to try and make it more official (if they're not the sort to drown it in red tape).

Oh absolutely.

My scripts ran, then quit as soon as they saw something wonky.

The real result was that they didn't do anything other than check the data.

I had tried to get them handed off to IT for official support but it got lost in the years due to silly politics.

I have had similar experiences. I've taken very tedious tasks that involved a lot of monotonous paperwork and automated them and that turns everyone's problems into my problem when they don't work the way the user thinks they should. I've also had people use the fact that my tool, which just automates a process that everyone had to do manually in the past anyways, use me and my tool not functioning correctly for them as an excuse to not having the work done on time.

> that turns everyone's problems into my problem

I see software as a new form of literacy, and this argument is, for me, a clincher.

Imagine a world where, you were the reader/writer in the company. And if there was a problem with the letters sent from head office, then because you are the reader/writer guy who does all the writing the problems are all yours

Yes, that is correct, as the only reader writer they are your problems. but the wider problem is why are you the only one?

True, but software is only one such department that this reasoning works for. Legal, Public Relations, Accounting, HR, facilities, etc, are examples of other departments that need specialists for fields that everyone really ought to get some literacy in.

If you're head of human resources at your company, any human resource problem the company has, is your problem, because you're the human resources guy.

To be fair, most of those departments demand certification to participate in, but if everyone was able to make spot fixes to the companies software, then I'd start demanding that only certified software people be allowed to touch our git repo.

“use me and my tool not functioning correctly for them as an excuse to not having the work done on time”

Sorry, bud, that one’s on you. If you don’t understand your users—really get in their shoes and walk around in them—how can you hope to build automation that works for them?

Change is Risk, and here you are trying to sell them on the mother of all Changes. Burn them, they won’t give you another chance.

--

[And yeah, I know some users will always be obtuse reactionary assholes who blindly reject any sort of change as a direct threat to their status quo. Work to accommodate them—if you can make your solution work for them then it’ll work for anyone—and if they’re just being a petty sabotaging asshole after you’ve done all that then bump the issue with the full papertrail up the management stack. Let their superiors handle their crap; they don’t pay you to deal with it. Take solace in knowing that once all their rivals at smashing it with terrific automation, those backwards losers will be first out their jobs.]

I can attest to this. I had similar experiences when I was in Aerospace. The complete incompetence of management is staggering and the mentality to stick with what has worked keeps efficiencies down. They instead went after the workers to "work harder" instead of allocating time and money to automation. I finally left and went to work on automation for industries that were receptive to creating tools that would make them more efficient. It's exceptionally frustrating to be in such a position, and you are right, it's better to do nothing and find yourself a place that fully understands what it means to save time and money by spending a fraction of it to fix while putting functioning processes in place to mitigate the risk of someone changing anything without going through the proper channels to ensure that the tools continue to work.

“I finally left and went to work on automation for industries that were receptive to creating tools that would make them more efficient.”

Congrats on finally realizing: Not your paygrade, not your problem to fix.

First rule of automation success: choose the jobs that are amenable to it, not the ones that aren’t. And never forget that people, not machines, are the heart of it.

> My incentive to automate anything for them ever again was gone.

I feel that a lot people have this exact problem.

There's not a word for it, but there should be. It's definitely an anti-pattern.

In my case, the way I got into "software development" was by automating things in my work. It has a lot of pluses and it looks like delightful magic to people who aren't expecting it. It can bring enormous value in places that desperately need it.

But there's a dark side to it. The dark side is that you find yourself alone dealing with problems using only stuff that you built. Like you said, you're at the focal point when things go wrong. No Q/A, no help-ticket system, no buffer, no one to manage expectations.

To make it worse, your boss, your peers and your PM's eventually find that, all of sudden, their workplace has a mini "software development department" that is integral to the mission. That's kind of jarring if they're not adaptable enough to handle it. If you try to get involved with actual software development folks in other teams, you're shunned because you aren't "really" a software engineer until you prove yourself to them (which may never happen depending on how rigid the org is).

I've find that to make this kind of arrangement work, I have to be willing to be a "one man band" for much longer than I feel comfortable.

“Then someone in the process changed things that the scripts did not understand.”

Change control is an utter pig in any system, and bad process is bad process anywhere. The difference is that humans, being highly adaptable, tend to dynamically mask defects in manual processes, whereas automation—efficient but utterly unforgiving—reveals those defects for all to see.

“when you change things you need to tell people before the day of and they were quite upset with me”

And this is why we always put things in writing.

In an ideal world, the organisation’s [manual] processes would all be nailed down and documented first, before any automation is introduced. This not being an ideal world, it’s not until the automation is being brought in that anyone stops to think about how things work. Alas, you can talk till you’re blue in the face about how the company really needs to formalize and document all of its change management processes, especially now that automation is in the mix, but you can’t make the bastards do their jobs; especially when they don’t even understand what those jobs now entail.

Thus the challenge in achieving successful automation is not in delivering a task-specific software but in cultivating a more general culture change across the organisation; one that understands that the purpose of automation is not to replace humans but to provide them tools to do their jobs more efficiently. Which means providing those humans the additional information and resources they require to use those tools both safely and effectively, even as the organisation and its processes and requirements continue to evolve.

If software design is about managing complexity, systems design is about managing liability.

You can be the best task automator in the world, but if you can’t protect the greater system—or at least ensure a damn good CYA papertrail—then you should seriously consider if introducing automation at this stage is the right thing to do. Never underestimate the strengths of manual processes, nor the immediate incremental benefits to be had in fine-tuning those first; even as you play the long game in your head.