Why are some things hard to do? If we want to make complicated tasks easier, which is one of the goals of DevOps, we need to have some theory of why they are difficult in the first place.
Richard Garfield, a mathematician and game designer, presents two factors that make tasks more difficult: time constraints and complexity. Our ability to solve a problem depends on the amount of time we can spend working on it and the complexity of the problem.
Time and Difficulty
DevOps discussions generally focus on time as the relevant dimension. Business value is measured in time: time to market, time to recover, and lead time for change are all important metrics for DevOps. Doing the same amount of work in a smaller amount of time is better. But an emphasis on time can also be misleading. Allotting less time for a task isn’t the same as truly being faster.
So what makes something take more or less time? Part of the difficulty of a task is relative to the person doing it. Provisioning a new server might be straightforward for an administrator, challenging for an application developer, and impossible for a graphic designer. Hiring good people and matching them with the right tasks reduces the difficulty of the task and the time required to complete it.
Complexity and Difficulty
But regardless of who’s doing it, the task to be done is the same. The specifications have an objective existence outside of whatever person is doing the work. The objective part of a task’s difficulty is its complexity.
The parallel between time and complexity is evident in the thought experiment Richard Garfield proposes. Imagine you are standing in front of two doors. One has a dragon behind it, the other has treasure. Each door is printed with a math problem that reveals whether the door contains a dragon or treasure. If you have a very short amount of time to decide, you will only be able to solve a fairly simple problem before being forced to guess which door is safe. Similarly, if you have a lot of time but must solve a very complex problem, you will again be reduced to guessing. Either insufficient time or excessive complexity can force a person to guess in a situation where a knowable answer exists.
Automation and Complexity
DevOps typically aims to reduce complexity through the “automation” leg of the CAMS definition. Now that we have examined the problem more broadly it’s clear that automation is a subset of the class of “things that reduce complexity.” Before automating, or if automation efforts at your organization have yielded disappointing results, a good check would be to ask “will this reduce the complexity of deploying code?”
Automating without visibility into what/how you are automating will move complexity around but it won’t reduce it. You’ll be able to spin up new builds really quickly—once you’ve tracked down the person who pushed the latest version and forgot to mention the three little configuration settings you need to change for it to work. Configuration drift or pockets of automation reintroduce complexity. Without visibility and monitoring, these problems grow on automation systems like mold on untended fruit.
This is not to say that automation is bad. When done in a mature environment with testing and visibility, automation is the greatest tool for reducing complexity. But without independent validation and monitoring, you’ll find that automation can also be one of the biggest sources of complexity.
