Automation is software. People get paid to work on it. Even 50 lines programs can have bugs.
I prefer to minimize the work in the first place. I look for existing tools that already have the automation I need. I look for alternative solutions if a process is going to have 50 steps.
I use GUI programs like converseen for one off bulk conversion tasks.
I make programs display the output people need right in the UI, rather than parsing the output with another automation.
I use sqlite if I can, rather than automate the setup of postgresql or something. I'll avoid modules with some compile step outside the package manager when I can.
I don't have backup scripts, I have back in time.
I rarely use build scripts, I use IDEs. And I prefer languages that don't make building into a nightmare. Android Studio has "automation" built in.
And when something does need automating, I have Ansible.
Automation is custom software. I don't start new software projects without looking for alternatives.
In the same vein, a lot of automation is working around process problems. It's all to easy for us technically-inclined folks to reach for a technical solution. A problem is stated and we immediately begin to draw up requirements, incorrectly assuming that a business process is a static thing.
Often times a little discipline, coordination, and documentation would more than suffice.
I'm a fan of what I call the 80% solution. Often fully automating is fragile, as the article pointed out. Instead automate the 80% that's safe to do, with a human in the mix to ensure it doesn't do the wrong thing. This can sometimes be as simple as a Go button or a multi-stage approval with a human in the mix.
It's not a perfect solution, but can often create a safer, more effective, overall system.
Sometimes the automation turns out so complicated that the work you put into the automation would be sufficient to do the task manually for many years.
If the task of automating something is complex, that might indicate that the process itself is complex. If that's true, then it might be worth automating anyway, because it would eliminate the error-prone parts of the manual process and give you a better end-to-end understanding of all the steps and how it all fits together.
30 minutes of recurring work everyday for years is not the same as a few months of directed work.
Automation forces you to understand and document a process, and usually do it more thoroughly and correctly. From then on, it relieves you to do other stuff.
The reality is that most companies have people manually working around the limitations of the software they are using. Without them the company would not function.
I prefer to minimize the work in the first place. I look for existing tools that already have the automation I need. I look for alternative solutions if a process is going to have 50 steps.
I use GUI programs like converseen for one off bulk conversion tasks.
I make programs display the output people need right in the UI, rather than parsing the output with another automation.
I use sqlite if I can, rather than automate the setup of postgresql or something. I'll avoid modules with some compile step outside the package manager when I can.
I don't have backup scripts, I have back in time.
I rarely use build scripts, I use IDEs. And I prefer languages that don't make building into a nightmare. Android Studio has "automation" built in.
And when something does need automating, I have Ansible.
Automation is custom software. I don't start new software projects without looking for alternatives.