Recently several people have said to me that DevOps cannot be a good choice for all software development. In fact, it seems a commonly held belief that certain categories of application (usually those with a high cost of failure) are not appropriate candidates for a DevOps approach. This is a misconception: DevOps can and should be applied to all software development within an organisation. In my experience, the misconception that DevOps is not always a good choice is built on the following argument:
- DevOps means faster development
- Faster development means less control and rigour (and consequently increases the risk of failure and the amount of downtime)
- Therefore DevOps only makes sense when the increase in speed is worth the increased risk
First let’s consider whether DevOps equates to faster development. I have said before that adopting Agile will not guarantee that you deliver the same amount of software faster or at a lower cost. But then, delivering the same thing faster is not the point of Agile. Several times I have presented on this topic and I usually get a chuckle and some knowing smiles when I quote the words of Scott Sehlhorst:
“If an agile team builds me a better dresser faster than a waterfall team builds me a not-as-nice dresser, I’m not better off if what I actually needed was a coffee table…Getting faster is nice, as long as you’re getting faster at building the right product.”
There is evidence that DevOps can reduce costs, through a combination of increased automation and decreased rework (cost of non-quality). However I see little evidence that DevOps enables you to build the same software faster than using traditional methods. What it does do is encourage more frequent releases of smaller increments of functionality and therefore enables the delivery of more value sooner.
So to answer the question of whether DevOps means faster development: it rather depends on your definition of speed. Don’t expect to get something that would have taken 6 months in 3 months. Do expect to see more frequent releases and, overall, more value delivered earlier.
Now let’s consider whether the increased agility and more frequent release cycles that come with DevOps inherently increase the risk of failure and the amount of downtime. Gartner’s paper on Bi-Model IT  characterizes Mode 1 as “emphasizing safety and accuracy” and Mode 2 as “emphasizing agility and speed”. Unfortunately many seem to have interpreted this as meaning that Mode 2 is inherently unsafe and less accurate! Gartner’s paper does not state this at all. In fact, it suggests that the opposite can be true:
“A Mode 2 team believes that when operating amid uncertainty, you don’t have to be slow to achieve high quality and be secure. Perhaps surprisingly, this team is often more rigorous than its Mode 1 counterpart, testing as it goes.”
This is backed up by the findings of the Puppet Labs 2015 State of DevOps Report which correlates more frequent releases and lower lead times with higher quality:
“High-performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster”
In fact for many (including myself when I was a development manager), the driver for adopting a DevOps approach was not increased agility or shorter lead times, but improved reliability. When Michael Rembetsy and Patrick McDonnell described the drivers for introducing DevOps at Etsy they said:
“Deploys took hours. Code didn’t work…Deployments would routinely fail, causing “HTTP 500 errors” across the entire site, with no easy way to restart the services or rollback changes.”
After making significant changes to how they built and deployed their software, they deployed into production 6,419 times in 2012 and those deployments were performed by 196 different people. They also reported reduced downtime because, although they were deploying more frequently, the likelihood and severity of problems was reduced and the speed with which they could rectify them was faster.
So should the choice of whether to adopt DevOps be based on a trade-off between speed and risk? The answer is no. Because this dichotomy does not exist. Yes DevOps increases agility and reduces lead times which allows you to respond faster in rapidly changing complex business domains. But this is not at the expense of robustness. The opposite is true: DevOps is more rigorous and achieves higher levels of quality. And it achieves all of this whilst also reducing overall costs.
So rather than asking where it makes sense to apply DevOps I’d like people to start turning the question around: where should it not be applied? Ask yourself this: in which part of your organisation do you notwant to see increased agility, higher quality and lower costs?
 Bimodal IT: How to Be Digitally Agile Without Making a Mess, 2014 No. 5