In my experience in larger software companies, the hardest part of automation is convincing management that it's worth it to stop other development for long enough to automate a problem away. A lot of managers are fine throwing people at a problem if it means meeting a date and making the team look good while under the hood all the knobs are being turned by hands by an ever struggling staff.
And then the worst case I've found myself in is where the people you hire specifically to automate are told to do things manually at first "until we get the automation out." Then you end up in a constant cycle of promising automation that will never exist because all of the workload is falling to the automators who have no time to fix anything.
Why have we ended up in a place where a developer is asking a manager to raise a ticket so they are allowed to create something only she will see. What happens if you just did it without the ticket?
Having great end-to-end tests are awesome for this exact reason. I spend 99% of my time adding new cool features instead of fixing bugs. While people I work with spend all their time complaining and moaning about all the bugs that keeps popping up in their production code.
That is why I went for totally stupid-silly automations.
I don't write "reusable" automations - I don't write scripts with parameters. I write a lot of scripts where I open it in notepad to edit and fill in variables.
Most of the times I just put copies of these scripts on specific servers and have variables filled in.
Variables need to change only if I change server or really change config of a server which is almost never.
This way "Automation" xkcd "Theory" fits reality.
Because then instead of rehearsing commands and what was the configuration I just go to the server and run the script and instead 30mins simple task takes me 2 mins.
XKCD 1319 gets the economics of automation wrong because it makes the assumption that you value the time spent on every activity the same, in particular that you equally value drudge work and programming.
The reality (for me at least, and I’m sure for others) is that I’d much rather be writing a program than doing drudge work.
XKCD 1205 is completely wrong because it fails to account for the fact that manual work tends to introduce random errors into the mix which are difficult to reverse. Whereas if automation is well designed, it's often very possible to correct any errors you made in the automation, and once you get it right it will always be right.
The other thing is that a task that takes 30 seconds doesn't just take 30 seconds, the context switch is actually quite a burden and even just having to remember to do the thing.
You should be fired if your automation is breaking 10% of the time.
All I'm saying is that the true costs of manual work usually isn't accounted for correctly. I see these costs spiralling into so much wasted work that it starts incurring more and more risk. Preference for gradual decay over Big Bang collapses isn't nessecarily rational, people tend to prefer living next to coal plants than nuclear plants despite the fact they're far far far more likely to die living next to the coal plant. It is in fact that irrational bias which needs to be resisted.
And then the worst case I've found myself in is where the people you hire specifically to automate are told to do things manually at first "until we get the automation out." Then you end up in a constant cycle of promising automation that will never exist because all of the workload is falling to the automators who have no time to fix anything.