Companies around the world and across many industries have felt the pressure to release faster, yet they struggle to do so in a safe and reliable way that doesn’t compromise user trust. 

A lot of these companies think there’s a dichotomy between whether you can move fast or increase value. 

“I think the move fast and break things got a bad rap. It’s kind of horrifying to think, Hey, a developer that I’m not even talking to could suddenly blow up my entire customer base without all these gates,” said Edith Harbaugh, the CEO of LaunchDarkly, during a recent SD Times Live! tech talk.

However, releasing slower today could actually make the software more unsafe, according to Harbaugh.

“If you’re doing the old software releases of 20 years ago where you do a release every year, every release has so much heft, weight and gravity behind it,” said Harbaugh.

Not only are the releases heavy in technical complexity, requiring developers to check all of these different branches and features, but they are also risky from a business perspective because the value that was planned a year ago might not even be relevant anymore. This could cause a large release to flop when out in the field. 

With the proper distributed architectures and guardrails that limit the blast radius, both speed and value are mutually possible. 

One such method for safer deployments is canary deployments, which can limit the blast radius from 100% of the user base and have it down to where it maybe affects 1% of the most progressive users. 

Canaries are typically an engineering activity and feature flags – which are a core part of this activity – help unlock value way up in the stack, according to DROdio, the CEO of Armory.

“You have to have the seatbelt on before you want to drive the Ferrari fast. The company has to have that psychological safety to be able to flip that cost-benefit analysis in their heads that it is worth deploying out to that 1% of the population so you can deploy 10 or 100x faster,” DROdio said.

Also, distributed architectures such microservices, serverless, Docker or Kubernetes limit the blast radius so that any one change becomes is a lot less risky.  

Once the mindset of an organization is changed to be able to validate changes, get more into production and get real usage in, releasing at cadences of up to even multiple times a day gets a lot less terrifying, according to Joe Duffy, the CEO of Pulumi.

Another benefit of a faster production cycle is that developers will also get quick feedback on all the features that they are working on and have more incentive to constantly interact with that feature’s code. 

“I think of developers as artists. They have code and they want to get their code out into the world and they want to learn from that code as quickly as possible so that they can have an iterative cycle,” DROdio said. “I don’t know that executives often understand that there’s anything more soul-sucking for a developer than having code sit on the shelf for a month or a quarter and it makes the best developers not want to work at companies that have that lack of sophistication.”

Listen to the full tech talk here.