Some years ago I’ve been reading “DevOps in Straight English” by Magnus Hedemark ¹ and encountered the Release Frequency vs. Risk chart that supposedly illustrated the advantages of DevOps. It seemed convincing enough to not give it a second thought. The other day I’ve been looking for something unrelated and ran into a similar chart showing the advantages of continuous delivery. This time something made me take a closer look at the logic behind the picture.

So here’s the original chart, as best as I could scribble on my iPad.

This seems to make sense: you mitigate the risk by increasing release frequency, thus not letting problems accumulate beyond your ability to deal with them. This is sort of like going to your doctor for regular checkups.

But here’s another way to interpret this picture:

So, no, this is nothing like going for regular checkups. It’s more like doing exploratory surgery every couple of weeks. As a developer, this would make your life easier (frequent code releases – not surgery), as you would be reducing the complexities of your work at the expense of business stability.

It is not surprising that the concept of DevOps got so much traction among programmers. How this idea was sold to the business is a bit of a mystery, though. Perhaps the managers were told that while the frequency of disruptions may go up, the overall duration of downtime will be reduced.

That’s unlikely, as more frequent releases leave less time for meaningful testing. Automated testing in a CI model is useful but simplistic. When looking at software testing, automation is the tip of the iceberg. It will alert you only to the most obvious issues.

One constant in the world of programming is that there will be bugs. Big bugs, little bugs, few bugs, many bugs. How these inevitable problems will distribute themselves in the space-time continuum is entirely unpredictable.

Increased release frequency does not provide for even distribution of stupid mistakes. However, it does guarantee more frequent downtime of uncertain duration. In the example below less frequent releases resulted in the same downtime duration as more frequent releases, but provided for a longer uninterrupted period of stability.

What seemed like a simple and logical illustration of the DevOps advantage is nothing more than an optical illusion. The sawtooth wave of changes and disruptions never goes away. It is really all about defining frequency and duration of downtime that works for your business. The rest is just buzzwords.