Continuous Delivery Office Hours Ep.9: The compliance ratchet

In the last episode, we talked about AI efficiency and effectiveness. That meant thinking not just as a beneficiary user but also as an end user. In this episode, we bring the authority to bear when we discuss the compliance ratchet. It turns out that there is an equal and opposite reaction in software, just like physics. If you speed up your software delivery velocity without the right practices in place, you encounter trip hazards that cause your organization to tighten controls.

The most dangerous part of this reaction is that compliance controls are added very easily, but are difficult or impossible to remove. That means you can trigger a one-way ratchet that permanently hampers your software delivery performance.

At the moment, it’s common for teams to use AI to increase the volume and pace of their software development. If this results in outages or high-profile bugs, compliance controls are slapped on the team. This often pushes the pace of change back to pre-AI levels, preventing any return on the AI investment.

Watch the episode

Watch Continuous Delivery Office Hours Ep.9

Balance the AI investment

One of the mistakes of introducing AI coding tools is expecting immediate gains. This puts pressure on teams to produce more changes and discourages them from introducing the pipelines and practices that will unlock the velocity and safety of sustainable high-performance software delivery.

On top of balancing the need for enabling practices, it’s also crucial to balance where you apply AI. If you only use AI to increase coding speed, the increased change volume will be absorbed by downstream bottlenecks. That means you need to consider where the investment has the greatest impact on the end-to-end flow of value, rather than speeding up individual stages and pushing more work into queues for review, approval, deployment, and feedback.

Unlock the ratchet

The controls you have in place for software delivery were likely created for a different time. They accrue as a result of organizational trauma: a bad deployment during a peak period means a 3-month deployment freeze, or a bad dependency means every change needs a senior developer review. Even if the team has learned from those mistakes, the controls remain.

Now might be a good time to revisit your path from a developer’s laptop to production, documenting each control and deciding whether it’s still necessary, and whether there’s a better way to manage the controls you decide to keep, optimizing for both speed and stability. Each past decision made on the assumption that there was a trade-off between velocity and safety should be reconsidered to find a way to achieve both. Automated validation is often faster and more repeatable than manual validation, so you likely have a way to achieve both easily. Replacing manual stages with automation provides far better control than adding additional slow checks.

Direction often beats speed

If you’ve been hanging around in software development for any length of time, you’d think all people cared about was speed. This is one of the great distractions of the past 3 decades. Teams adopted Agile for speed, they adopted DevOps for speed, and now they’re buying AI coding tools for speed. As described in The Bullseye Model, the ultimate goal isn’t speed, but a combination of speed and direction. When you aren’t sure what users want, delivering software versions early and often helps you discover their needs and what works. Ultimately, though, you’re trying to hit the bullseye with perfect software, and that means direction is at least as important as speed, perhaps more so.

All of these insights point to a necessary shift in software delivery; one that is long overdue. For a long time, we’ve treated technical practices as optional, but with the velocity and scale of modern software, that’s no longer true. We’ll be talking more about this in the future.

Happy deployments!