Ask HN: What would happen if we prioritised all bugs over all new features?

You are bug-free, start working on new feature, new bug reports come in, and you have to pause and work on them.

Fixing bugs is not fun work because there is usually a quick fix in an ugly way, and then a perfect fix via a large refactor and re-architecture. This results in that "soul-destorying" feeling of: if I had enough time I could fix this properly in the right way with clean code and avoid huge amounts of bugs, but alas I am just piling on tech debt.

Also you’d be surprised at what gets classified as a bug when you apply this.

Ultimately though, everybody does this. Critical bugs get fixed first. Anything too far down the backlog de-facto doesn’t get fixed. I like the intellectual honesty that this approach brings, in that it forces you to set a bar for bugs not worth fixing and consequently marking them as won’t fix.

Final note: whether a bug is worth fixing changes over time. Maybe your best engineer can’t find it after two weeks. Maybe your biggest customer just ran into it. Maybe you can’t reproduce it. Maybe the platform causing it got acquired by Google.

Can it work? Yes, but it doesn’t look very different to what you’re probably already doing in practice.

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.

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.