> This led us to an interesting question: what if we just split all bugs into "will fix" and "won't fix"...
I feel like this already happens in some places, just implicitly rather than explicitly. There's a reason why people sometimes joke about the backlog being the place where lots of low priority things go to be forgotten about, and never be done. The problem with this approach is that even if you could get around to fixing low priority bugs in X months/years, with this approach you would prematurely toss them aside and decide to never fix them.
> ...and then prioritise every "will fix" above all new features....always. In other words: we commit to only ever adding new features when we're bug free.
This will decrease your ability to ship new features in a timely manner and will put you at a disadvantage if you're up against any sort of competition, that ships "good enough" things soon, versus you shipping "really good" software way later. The benefit of this approach is that it should lead to a more maintainable codebase in the long term, though how much this matters depends on your circumstances.
It will mostly depend on how you choose what goes under "will fix" and how much it matches what's necessary to keep the lights on (KTLO).
For example:
- Users can't view a page that's needed for legal compliance, in some popular browsers? Needed for KTLO, fix it, no brainer.
- There are errors when trying to use some niche functionality, which affects around 1-5% of your userbase? Probably should fix it, it depends.
- Some button's logo is offset by a few pixels in a settings page or an info message flashes too quickly after some redirect? Probably nobody cares that much.
Of course, all of that might also coincide with how you choose to test your software.
I once wrote some JWT code to allow multiple systems to integrate and communicate securely. I decided that I wouldn't ship it until I got something like 95% test coverage, enforced by CI and everything. It was doable and helped me discover a few bugs to fix during development, as well as refactor with confidence - but it took something like 4x more time than regular development would, which I can't see working well for the majority of projects out there, outside of core functionality and financial transaction related code.