DOI : 10.17577/A mid-sized insurer bundles all its software changes into a single release on the last Saturday of every month, on the theory that fewer releases mean fewer outages. Its worst incident of the year happened on one of those Saturdays. About 140 changes went out together, claims processing stopped working, and it took the team most of Sunday to figure out which change caused it.
That monthly release felt cautious. Years of engineering research suggest it was the riskier option.
Speed and Stability Move Together
The longest-running studies of software delivery, covering tens of thousands of technical professionals, keep finding the same pattern. Teams that deploy small changes frequently also tend to have lower failure rates and recover from incidents faster. The teams that release rarely, in large batches, tend to do worse on both counts.
The mechanism isn’t mysterious. A release with three changes is easy to test and easy to roll back. A release with 140 is a puzzle. When something breaks, engineers spend hours on detective work before they can even start fixing anything.
Getting there takes investment: automated tests people trust, a deployment pipeline that doesn’t require a war room, and feature flags so code can ship before it’s switched on. Teams rarely make that jump in one quarter. But “release less often to be safe” is one of the most consistently disproven habits in IT.
Most Cloud Breaches Start With a Setting
Security research tells a similar story about where risk actually lives. Analysts have argued for years that nearly all cloud security failures trace back to the customer, not the provider, and incident reports bear that out. A storage bucket left public, a database port open to the internet, a service account with administrator rights it never needed.
This is the problem cloud-native application protection platforms and CSPM tools are built for. Posture management scans cloud accounts for misconfigurations against known benchmarks. The broader platforms add workload and container scanning, identity analysis, and links back to the code that created each resource.
The first scan is usually humbling. A company with a few hundred cloud resources can easily get thousands of findings. Teams that try to fix them in list order give up within a month. The ones that make progress prioritize by attack path: a resource that’s reachable from the internet, holds sensitive data, and carries excessive permissions goes first. A misconfigured test server with no data can wait.
Ownership matters as much as the tool. Findings routed to a central security team that can’t change the infrastructure tend to sit in a dashboard. Findings routed to the team that owns the resource, ideally inside their normal ticket queue, get fixed.
Bots on Old Screens Versus New Applications
Automation gets lumped together in budget meetings, but the differences between RPA and low-code matter a lot in practice. Robotic process automation works on top of existing software, mimicking a person clicking through screens and copying data between systems. Low-code platforms build new applications and workflows with visual tools and limited hand-written code.
Consulting surveys have put early RPA project failure rates as high as 30 to 50 percent, and the reason is usually maintenance. A bot that copies claim details from email into a legacy policy system breaks every time someone adds a field to that screen. Some IT teams end up spending Monday mornings repairing bots.
My view: RPA is a reasonable bridge for systems with no API that you plan to replace within a couple of years. If the process itself needs to change, or will run for the next decade, rebuild it in low-code instead. That option has its own risk, mostly sprawl, with dozens of departmental apps that nobody owns once their creator moves on. Require a named owner for every app before it goes live.
The Finding Nobody Budgets For
Developer surveys regularly estimate that around a third of engineering time goes to dealing with technical debt and maintenance. Separate research on interruptions suggests it takes upward of 20 minutes to get back into focused work after a disruption. Neither number shows up in a tool purchase, and both shape what a team can actually deliver.
What ties much of this research together is uncomfortable. The monthly release, the bot that avoided touching the old system, the security alerts sent somewhere central all felt careful when someone chose them. The evidence keeps rewarding the teams willing to make smaller, more frequent, slightly scarier changes instead.
