Continuous Delivery Kills Software Quality

The recent CrowdStrike disaster is just the latest symptom of a much bigger disease plaguing the software industry: continuous delivery is killing software quality. Agility, when applied correctly, is a powerful force in software development. However, the relentless pursuit of fast and frequent releases has led to a situation where quality is being sacrificed in the name of speed. It’s as if the entire software industry has turned into a fast-food factory, where speed trumps quality.

Remember the golden age of video games? When a game was released, it was printed on a cartridge or burned onto a DVD. There was no going back, no fixes, no hot fixes. If your game was full of bugs or incomplete, it was a financial disaster. The pressure to deliver a finished product was immense. The result? The games were usually flawless.

Today we find ourselves in the era of “early access” releases. Games and increasingly others Software is released unfinished with the promise of “fixing it later.” Continuous delivery has become the perfect excuse for shoddy work. We literally tell our customers, “Don’t worry if your product isn’t ready now, we’ll finish it someday.”

This mentality is spreading like wildfire. And it’s not just about gaming anymore. Critical infrastructure, financial systems, even medical equipment and transportation infrastructure are subject to this reckless approach. The CrowdStrike incident is a stark reminder that when software fails, the consequences can be catastrophic.

We need to return to the principle of formal versions. Software must will only be launched when it is truly ready, with solid evidence of its accuracynot when it suits you. The bar for quality needs to be raised and developers need to be held accountable for the software they produce.

We can learn a lot from other fields of engineering. Take civil engineering, for example. When a bridge is built, no one opens it to the public until it is fully completed and has undergone rigorous safety tests. In Brazil, the ART (Technical Responsibility Annotation) requires engineers to approve their projects, thus assuming full responsibility for their execution. A mistake can have serious criminal consequences. Why should we expect less from software, which is increasingly becoming an essential part of our lives?

We know it is possible to build safety-critical software that works well. This happens when the organizations responsible are motivated not by economic forces, but by significant regulatory pressure. The problem is that as software continues to “eat the world,” more and more critical systems are being developed by industries that face no regulatory pressure.

So things can be expected to go wrong, and a major disaster resulting in the loss of many lives is a question of “when,” not “if.” Maybe then developers will stop treating their job as a perpetual beta and start treating it as the essential part of our lives that it really is.