Code Spoilage vs. Breakage

I was recently on an SD Times panel titled "Move Fast & DON’T Break Things: Modernize Your SDLC without Compromising Customer Trust" with Edith Harbaugh, the CEO of LaunchDarkly, and Joe Duffy, the CEO of Pulumi.?Our premise: you can move fast — and do it safely. In fact, all three of our companies help companies do just that — and, in today's world, it is becoming more of a 'must' than a 'should'.

I love doing panels like these with other progressive leaders in our space because I always learn something new — and on this panel, one point Edith made really struck me: Quantifying the cost of code spoilage. You can listen yourself (video below), but here are the highlights for me:

• Code that has been written but is not yet in production is effectively inventory sitting on the shelf. Many companies that prioritize safety end up with weeks, months or even quarters of "code inventory" that has not been released to production.
• It often makes a company less safe to batch code into large, infrequent releases — what Edith referred to as the "push and pray" method.?As you deploy code in smaller and smaller chunks of value, risk mitigation/amelioration is much more identifiable and manageable.
• Increasingly, infrastructure is being thought of differently — the static infra old-school model is being replaced by a more dynamic and fragmented one: Changes to infrastructure are being shipped continuously, and increasingly you see a software person running the infrastructure organization. The distinction between infrastructure vs. application layers is becoming more blurry.

As we riffed on this idea of the often unseen cost of having massive amounts of code inventory sitting on the shelf, we ended up talking about it as "code spoilage" — just like physical inventory creates a large cost for companies, code inventory is no different.

I find that many executives at Global 2,000 companies are laser-focused on ensuring they do not break customer trust by deploying bugs, errors, and outages to customers in production. And that makes a lot of sense — a company's brand equity is directly tied to its ability to maintain customer trust.

But what I often find is this laser focus on eliminating code "breakage" leads to large amounts of code "spoilage," because the companies cannot innovate quickly, leading to code sitting on the shelf for extended periods of time.

And just like Edith pointed out in the video, what we find is that having to choose between spoilage vs. breakage is a false choice that is dictated by a lack of sophistication in a company's software delivery tooling, which is typically home-grown, creaky and brittle.

With increased sophistication, a company can not only be safer, reducing breakage, but also move faster, reducing spoilage.

This sophistication requires an investment in the company's ability to deliver software in consistent ways, at scale, across the entire organization. It requires an acknowledgment by the executive suite that the company's ability to compete effectively in the coming decades will be predicated by its ability to turn its ideas into complex software-driven user experiences. This "assembly line for ideas" already forms the basis of the growth engine for technology companies that are increasingly dominating their industries, and moving into adjacent industries. It will also serve as the growth engine for traditional enterprises that lean into building sophisticated tooling to unlock the additional enterprise value that will be available to them as they digitally transform.

Specifically, it requires enterprises to invest in software delivery tooling that enables:

• Its thousands of developers to write code and get that code into production across multiple targets (Kubernetes running on-prem, AWS, GCP, Azure, etc) in consistent ways, with a standardized "golden path" to production
• Advanced strategies for delivering code, like blue/green and canary deployments, that limit the blast radius of errors, vs. nuking the entire user base when there's an error in production
• Reducing the cost of failure by enabling 1-click rollbacks at scale
• Building quality into the software delivery process using advanced methods like Policy-Driven-Deployments
• Enabling infrastructure to be provisioned in realtime as a part of the software delivery process — for example, using Pulumi's Spinnaker Plugin
• Enabling Feature Flags — where LaunchDarkly excels — so you can divorce the delivery of code from the actual user's experience

Investing in your software delivery platform will enable you to reduce both code breakage and code spoilage, by increasing both the safety and velocity of your ability to innovate at scale. This is the value that Armory, LaunchDarkly and Pulumi deliver.

Here's the video from our session: