Automation is a local optimizationLocal optimizations often are useful. But they also often aren't.
You have a task that consumes an hour per day of your time, every work day.
You could automate the task for a one-time investment of $10,000.
I can hear you thinking already… “Well, my effective hourly rate is $X… $10,000 divided by $X equals…”
If you continue, you’ll soon come to a number of work days until the investment pays for itself.
Well, such a calculation isn’t a bad idea. But it’s not the end of the story. In fact, it shouldn’t even be the beginning.
Automation is a local optimization. And while local optimizations often are useful, they also often aren’t.
Consider an example from Simon Wardley’s blog post (and book) about Wardley Mapping (edited for brevity):
The company was expanding and needing to increase its compute resources. The process however had a bottleneck. Once servers were delivered at “goods in” they needed to be modified before being racked. This was time consuming and sometimes prone to failure. They were focused on improving the efficiency of the process flow as it was important for their future revenue generation. A proposal was on the table to invest in robotics to automate the process of modifying the servers. Whilst the proposal was expensive, the benefits were considerable especially given the significant future revenue that was at risk. A strongly positive ROI had been calculated.
What is worth noting is the racks were considered custom. On investigation, the company had always used custom built racks and it even had a friendly company that made them for it. Dig a little bit more and we come to reason why the servers needed modification. It turns out that standard servers are designed to fit standard racks. They didn’t fit the custom built racks that the company had so lovingly built. Hence additional plates needed to be added, holes drilled into the servers — this was the modification that was required.
Let us be clear, on the table was a proposal to invest in robotics in order to customise standard servers in order that they fit into custom built racks which the company was buying. Does the proposal still make sense? Is it a good investment? Are there alternatives? Do I hear you shout “use standard racks?”
With this story in mind, let’s consider our hour-long daily task again, versus the $10,000 investment.
What alternative investments could we make? Is that hour-long task something we should not do at all? Could it be replaced by some other process that doesn’t require automation? Is that hour-long task compensating for some other legacy decision?
Automating a task that shouldn’t be done isn’t an improvement. It’s like pouring water over a chain-linked fence in a flood.
Taylorism is dead. Long live Taylorism!
Taylorism has gotten a lot of flack for being inhumane at worst, and ineffective at best. But DevOps is about applying Taylorism to computer systems.
The misunderstood MVP
Many people are confused by the concept of an "MVP". If you wait until your product is lovable, or even complete, you've wasted time you could have been learning.
Improve your software delivery