Zero Known Bugs in System

A radical notion for Software Engineers is to push for zero known bugs in the system. Most engineers accept that bugs are a part of a complex system. Being bug free is not possible. I’ve come to see this a little differently.

Bugs should be polarizing in my view. Some time ago I noticed an explosion in the total number of bugs in a system undertest and began a 2025 project to have zero known bugs in the system. The goal of course isn’t to get to zero bugs in the system, this is impossible. But to position ourselves so that we can tackle bugs quickly once we’re aware of them. If we could get down to zero known bugs then it will be relatively trivial to stay there. No need for backlog management, no need for grooming or prioritisation. In other words, we’d spend less time on admin, have less time on related support cases and have less difficulties with our release cycle.

Creation Process

Every week new bugs are logged and others are fixed. This bug balance, new bugs – resolved bugs gives us a general trend of fixes. However since the more concerted push towards application parity with our competitors its does seem as if we’ve de-prioritised bug fixes. This is not necessarily a problem as long as your aware of the issue. Starting from week 40 in 2024 we begin to see the average number of bugs being added to the backlog > 5 per week.

BUGS vs Technical Debt

During the review process its become more and more clear that not all of our logged bugs fit the ISTQB definition which is:

“A bug is a flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition.”

We’re proposing to split the existing backlog of bugs into bugs and tech debt. Bugs can then continue to be treated and prioritised by the PO’s while tech debt can be addressed by the engineering teams.

Bug: An error or flaw in the software that causes incorrect behaviour, crashes or security vulnerabilities.

Tech DEBT: Suboptimal code or architecture that was intentionally or unintentionally introduced, making future changes harder or more expensive.

Feature	Tech Debt	Bug
Nature	Structural problem	Functional problem
Cause	Poor design, shortcuts	Coding mistake or regression
Impact	Slows development	Causes incorrect behavior
Urgency	Can be delayed	Needs immediate attention
Fixing it	Refactoring, redesign	Debugging, patching

The real reason for making this distinction is responsibilities. The engineering teams have the responsibility for fixing, prioritising and advocating for the resolution of technical debt, whereas PO’s and PM’s are responsible for prioritising bugs. From now on team leads will be able to go to the backlog and filter on type “Technical Debt” and label “Your Team” and see your backlog of technical debt.

Thanks for reading this small project summary. The effort continues in 2026 but the effect of starting and clarifying such an iniciative have paid dividens for the 2 years.

Thanks, Lucas