My calculator app uses a fraction of a percent of my computer's processing power. I've never crashed it. Excel can manage millions of cells, run complex macros, and connect to external databases. I've crashed it plenty of times. I use Excel anyway because it's worth the tradeoff. Complexity and value go together. So do complexity and bugs.
Think of it like traffic in a city. The safest possible system is one with no cars. No accidents, no injuries, no fatalities. Also: less commerce, less mobility, less of everything roads are supposed to enable. The next safest option is very few cars moving very slowly with extensive checkpoints at every intersection. Perfectly safe. Perfectly limiting. No city operates this way.
Instead, cities optimize; they balance throughput against safety, cost against speed. They accept that accidents will happen and invest in response systems and continuous improvement. Software works the same way.
There's another option, of course. We could spend months testing every release, add layers of review and approval, and slow everything down in pursuit of fewer defects. We'd still have bugs. We'd also have projects that take twice as long and cost twice as much. That's not a hypothetical tradeoff. It's a real choice, and the answer matters: could we achieve near-zero defects? Probably. Could we do it at a price point that makes sense? Absolutely not.
The complexity we're managing keeps compounding, which makes this even harder. Every year, we ask more of our software. More accessibility, more security, more speed, more integration, more compliance. And we don't work in a vacuum. Browsers patch, frameworks update, devices change. The target moves constantly. As systems grow more complex, the number of possible interactions grows exponentially. Exhaustive testing isn't practically possible or economically feasible. It necessitates a risk-based approach: what's most likely to go wrong, and what's most damaging if it does?
Here's a truth that might seem counterintuitive: if you're not breaking anything, you're either not doing anything or not doing enough. Bugs are a byproduct of progress. They indicate that we're building, shipping, and creating value. The absence of bugs often signals stagnation. Or worse: over-investment in prevention that starves delivery. And in technology, stagnation is a death sentence. You're not reading this on a Blackberry or in Netscape Navigator. The landscape demands we adapt, level up, change how we build and what we build, or get left behind. When you're racing to stay relevant, competitive, and current, bugs happen. It's part of it.
At Silverchair, we make deliberate choices about the balance between bugs and growth. Apple, Microsoft, and Atlassian all maintain massive bug backlogs (Atlassian's is publicly visible), with known issues that may never be addressed because the cost of fixing them outweighs the benefit. CrowdStrike, a company whose entire business is security, shipped an update in 2024 that crashed 8.5 million Windows machines worldwide. Even the most sophisticated, well-resourced technology organizations in the world cannot achieve zero bugs.
None of this means bugs don't matter. They cost time, create frustration, and erode trust – for you and for your users. Nobody on our team wants to ship problems that make your job harder. The question isn't whether bugs are acceptable; it's how we balance proactive investment in prevention against the speed of our response when issues occur.
So what should we optimize for instead? Detection speed, so we find issues before clients do. The volume and trend of client-visible bugs, because leaks will happen but we should see fewer over time, not more. Severity, because a drip is different from a downpour. And recovery time, so when something breaks, it's fixed fast. All of these (speed, volume, and severity) are things we continuously monitor with each new release.
When I say there will be bugs, I'm not making excuses. I'm being honest about the reality we all operate in. Bugs mean we're building. No bugs and no progress? That's when you should worry. Our job is to be good stewards of that balance, shipping value while managing risk, and to keep getting better at it.