Thread by @damovisa

The #1 sticking point I see with teams buying in to DevOps? Allowing things to go wrong.
“Move fast and break things” seems at odds with “getting things right”. In reality, they go hand in hand.
<thread>

It’s totally reasonable to be uncomfortable with failure. The thinking is if only we were more _careful_ with our software releases, nothing would go wrong.

But it does go wrong, and it will continue to go wrong. No matter how careful you are, there’s nothing like production to show you what you missed!

But by adding more governance and working as hard as you can to avoid failure, you ensure two things:
1) You won’t be ready to handle failure when it happens, and
2) You’ll slow down and _add_ risk by shipping more change with every release.

There’s a clear parallel to “Agile” vs “Waterfall” here. As an industry, we realized no matter how much we worked on our estimates and planned ahead of time, we’d still get it wrong.

Gantt-chart-holdouts argued that we just needed to plan _more_ and _better_. But it didn’t work. Only by accepting we didn’t know it all up-front did we make progress. We could handle the reality of change and uncertainty.

This certainly isn’t the first time I’ve said these things and they are definitely not my ideas.

For example, check out the State of DevOps (#ASoDR) report by @devops_research/@nicolefv et. al.: cloud.google.com/blog/products/… - the research is clear: more frequent, faster releases _correlate_ with fewer failures and faster fixes.

And being comfortable with failure, and putting yourself in a position to learn from it is what @RealGeneKim’s “Third Way” is all about: itrevolution.com/the-three-ways…

There’s an awesome totally-out-of-context-but-still-relevant quote from Lord of the Rings that I love: “The closer we are to danger, the farther we are from harm”.

If you’re comfortable with the _chance_ that your deployment will fail, you put measures in place to manage it. You build your delivery pipeline and monitoring solutions based on this assumption, and can recover and learn when things do go wrong.

But if you’ve put all your effort into preventing failure in the first place, you’ll be ill-equipped to recover when it does.
</thread>