The conventional story about unfixed bugs goes like this: companies are lazy, underfunded, or just don’t care about quality. Engineers file tickets, product managers deprioritize them, and the backlog grows until someone does a “tech debt sprint” that fixes three things and closes forty as won’t-fix. Repeat forever.
That story is wrong, or at least incomplete. Most bugs don’t get fixed because, under honest economic analysis, fixing them is the wrong decision. The real problem is that we’ve built organizational systems that make rational bug-triage look like negligence.
The economics of a bug are almost never in favor of fixing it
Consider what fixing a bug actually costs. A developer has to context-switch out of current work, reproduce the issue (which can take hours for intermittent bugs), understand the relevant code (which may be years old and written by someone who left), write a fix, write tests, get a review, and ship it through whatever deployment pipeline exists. For a non-trivial bug in a mature codebase, you’re looking at a day of work, minimum, often more.
Now consider the benefit side. If the bug affects a small percentage of users, in a flow that most users don’t hit, with a workaround already documented in a support article, the measurable user-facing improvement from fixing it is genuinely small. Product managers aren’t villains when they deprioritize this. They’re doing math.
The Standish Group has tracked software project outcomes for decades and consistently finds that a large fraction of software features are rarely or never used. Bugs in those features carry proportionally less weight. Nobody should feel morally obligated to polish code that serves almost no one.
Bugs become load-bearing walls over time
Here’s where it gets structurally interesting. Many bugs, especially in systems that have been running for years, are not actually safe to fix. Downstream systems, integrations, and user workflows have adapted to the buggy behavior. Fix the bug, and something else breaks.
This is not a hypothetical. The POSIX standard famously documents behaviors that were originally bugs in early Unix implementations but had to be standardized because too much software depended on them. Microsoft’s Raymond Chen has written at length about Windows bugs that couldn’t be fixed because popular applications (including, at various points, some by Lotus and Netscape) had written code that specifically relied on the incorrect behavior.
When a bug has been in production long enough, fixing it requires understanding not just the bug but the entire ecosystem that has grown around it. That is frequently more expensive than the bug’s ongoing cost to users.
The measurement problem makes everything worse
Companies track metrics for things that are easy to measure: new feature adoption, conversion rates, load times, crash rates. They rarely have good visibility into the cumulative friction cost of bugs that don’t crash anything, just make the product slightly worse for a portion of users.
A user who quietly stops using a feature because it misbehaves in a specific edge case generates no alert. A user who calls support gets logged. A user who silently churns may never be attributed to the bug that pushed them out. So the cost of unfixed bugs is systematically undercounted, while the cost of fixing them (engineering time, risk of regression) is visible and immediate.
This asymmetry is not an accident or an oversight. It’s a structural property of how software organizations instrument themselves. You can only optimize for what you can see, and most companies can’t see the full damage their bug backlog is doing.
The counterargument
The obvious pushback is that this logic, taken to its conclusion, justifies never fixing anything. And there are certainly companies that use “rational triage” as cover for genuine neglect. Technical debt compounds. Systems that never get cleaned up become increasingly expensive to maintain and eventually impossible to extend.
That’s real. But it’s a different problem from the one I’m describing. The failure mode of over-zealous bug-fixing is rare in practice. The failure mode of treating every unfixed bug as evidence of organizational dysfunction is common, and it produces perverse incentives: teams spend time closing low-impact tickets to hit “quality metrics” while genuinely painful issues that are hard to reproduce stay open for years.
The bug backlog needs honest triage, not guilt. Some bugs should absolutely be fixed immediately, especially anything touching security, data integrity, or the core user journey. Others should be documented, triaged, and left alone. A few should be closed as won’t-fix with a clear explanation. What shouldn’t happen is the pretense that all bugs are equally worthy of attention, because that pretense just generates noise.
Software quality is not measured by the length of the bug backlog. It’s measured by whether the software reliably does what users need it to do. Those are related but not identical. The sooner engineering organizations stop treating them as synonymous, the better the actual decisions will get.
