Kosli speed skating althete

Is faster actually safer? How software physics beats human psychology

Bruce Johnston
Bruce Johnston
Published April 28, 2021 in features

Sometimes doom-scrolling through Twitter has its rewards. A few weeks ago, in between the Ever Given🚢 memes (how we miss the big boat!) and the usual screams😱 into the void, I came across this tweet from Charity Majors (@mipsytipsy), CTO at @honeycombio

That’s it. That’s the Tweet.

charity majors tweet snippet

These are such great analogies. Unless we’re running away from imminent danger🦁, humans have a really hard time processing that faster is safer. Usually, when we feel threatened or uncertain, we slow down, take our time and look at our options. 🤔

Even in relatively comfortable situations we sense that increasing our speed will also increase our risk. And in the world of software these “deep seated biological impulses” create human barriers to automation.

y tho meme

Yeah, why is that?

There are several reasons why tech leads and managers cling to these deep seated notions of predictability, safety and routine. Continuous delivery scares them because…..

  • They don’t trust their teams to push desirable changes to PROD every 20 minutes ❌
  • They think batching changes means more oversight (also great for spreading any potential blame around 👍)
  • They think slower deploys 🐌 make for higher quality and fewer bugs

DevOps people know none of this is true. Low frequency deploys and batched changes aren’t good for productivity, but they do give managers the illusion of control. And because the idea that “faster is safer” doesn’t feel right, people will make all kinds of trade-offs to hold on to that illusion.

Wizadora, nothing’s surer.

As ever, DORA❤️ has findings that back up what we see in the field. In the 2018 report they found that “misguided performers suffer from a cautious approach.” It’s worth quoting at length:

“We often hear from organizations that prefer to take a cautious approach to software development and delivery. They assure us—and their stakeholders—that releasing code infrequently can be an effective strategy as they use the extra time between deployments for testing and quality checks to minimize the likelihood of failure. For the most part, they achieve that goal.”

Notice the positive reinforcement. They believe slow is safe and they’re even seeing results that confirm those beliefs. It’s all fun and games until someone loses an eye though. The report continues:

“Developing software in increasingly complex systems is difficult and failure is inevitable. Making large-batch and infrequent changes introduces risk to the deployment process. When failures occur, it can be difficult to understand what caused the problem and then restore service. Worse, deployments can cause cascading failures throughout the system. Those failures take a remarkably long time to fully recover from.” 😬

How long exactly⏰? DORA found that anywhere between 1 and 6 months was a reasonable ball park for full recovery. And it was all going so well! We were on the ice and inching along. Suddenly, we’re flat on our faces with no easy way of getting back up. Turns out slow wasn’t that safe after all.

Plus ca change!

We found something similar in a previous post on the FCA’s report on Implementing Technology Change.

Asked to grade their own homework ✅, managers thought that their costly and time-consuming change management processes were effective precisely because they were costly and time-consuming!

If it costs money and takes time it must be doing something, right? Managers were buying into that illusion even as they reported that change failure rates were the single biggest cause of incidents. Cognitive dissonance to the moon! 🚀 🌝

Charity’s tweet inspired me (thank you🙏!) because the idea that “speed is safety” applies to change management as well as continuous delivery. They’re part of the same value stream. If you can automate🤖 your change and release controls as part of your DevOps pipelines, there’s no reason to delay release candidates because some guy👨🏻‍💼 with a clipboard needs to eyeball 👀 them first.

Managers still see their job as a high wire act where a pinky toe either side of the rope means disaster. We need to encourage them to go faster by thinking more like ice skaters and less like tightrope walkers, and adopt DevOps Change Management.


About this article

Published April 28, 2021 in features

About the author

Bruce Johnston

Bruce Johnston


ABOUT THIS ARTICLE

Published April 28, 2021, in features

AUTHOR
Bruce Johnston
Bruce Johnston
Live in Git Blame? Don’t spend hours searching for the change that broke your application! Query, search and discover all the changes in one place

Latest articles

Kosli announces Innovation Partnership with DNB and Firi

We are pleased to announce that Innovasjon Norge has awarded Kosli an innovation grant of 3.4 million NOK to pursue a R&D project with DNB and Firi. In this blog we’ll give you an overview of the …

The Ultimate Guide to git blame: A How To with Examples

Source control tools give users many powers and one of the big ones is traceability. With traceability tools you can know exactly who made each change and when they made it. In Git, you use the git …

Git Blame in VS Code: The 4 Best Options

Most production projects have a team collaborating on them, so even in a single file there can be multiple contributors. When things go wrong, it’s useful to understand how and why certain changes …

Sign up to our newsletter

We'll let you know about the Kosli launch, product news, features and updates
Kosli is committed to protecting and respecting your privacy. By submitting this newsletter request, I consent to Kosli sending me marketing communications via email. I may opt out at any time. For information about our privacy practices, please visit Kosli's privacy policy.
Kosli team reading the newsletter

Let’s chat!

Got a question about Kosli? An idea for a new feature? Join Kosli Slack and talk to us.

Join
Developers using Kosli