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

It would really depend on the severity of the bugs... assign severity levels as part of triaging.

Also what kind of bugs are coming up is important... I think bug do tell stories; it might help you identify issues with feature assumptions on workdlow or use-cases and that needs to inform your product development as a feedback loop to avoid technical debt and having to rewrite stuff later.

Depending on the size of your team, I would have a 2-4 people focusing on just bugs / QA (so you can catch most bugs going forward) while the rest of the team focuses on new features.

Once you start factoring in reputational damage it becomes easier to choose what/if to fix. If you add new features but the resulting product is something that gives the idea that the platform is unstable or broken you'll end up with people switching to some other provider.

If the product has actual customers it makes ALWAYS sense to prioritize fixes along the hot paths. And it you should be easy even for non-technical people to understand. You lose customers.

A feature is not done until all major bugs or regressions are fixed.

Microsoft rather famously tried this[1]. And it seemed to really help them.

I've worked places that have tried it, too. It does work; in my experience, it literally always improves software quality. But I think it is like how pretty much all diets work, at first, but not over the long term.

It becomes unsustainable, as the pressure to work on features grows.

Continuing with my diet analogy, I now think of it like bulking and cutting phases. When you are bulking up your product with new muscles (features) you are also adding fat (bugs). At some point the percentage starts growing unhealthy, slowing you down and causing all sorts of ancillary problems.

Might be time for a cut phase then.

My analogy breaks down (because it's not really a good analogy) with a bigger team. Then you can have people assigned to bug cleanup. But this leads to its own set of problems — do you pay bug cleanup engineers a bunch extra? Because they will tend to be reading Who's Hiring top to bottom after a few weeks of that.

I think this does work great, though, when it is for a pre-determined fixed duration of time. (e.g. "3 iterations" or "one quarter").

[1]: I think where I read about this is now behind a paywall, but this seems to be the same initiative: https://sriramk.com/memos/zerodef.pdf

On a sufficiently complex product it is impossible to fix all known bugs, even classified as will fix. Another issue - it will take so much time that your company will be left behind by the competitors. Maybe less so in the web, but with hardware it's a question of multiyear contracts, so getting abandoned by a big customer in favor of a feature rich competitor may mean that you won't get a second chance with them any time soon. Of course a reverse happens too - if your market leading product is more and more buggy over time, they may abandon you or force to fix most bugs, or force to do significant structural changes etc.

- New features help close sales.

- New features also add tech debt, complexity, cost, bugs, makes you slower, and will lose you some sales that way.

- At 0 features you really need to implement features instead of messing about with the bugs in the devops scripts.

- At e.g. Windows scale, maybe stop messing about with new features nobody asked for and fix some bugs, yes.

- In a Laffer-curve-like effect, there must be a point where it peaks and it's better to fix bugs than to implement a new feature.

- It's a very difficult to identify where you are in the curve.

- One of the measures is simple "do X, get money from this guy I have on the phone"

- The other measure is fuzzy, lags, is subjective, can't be traced to a particular feature.

Good luck!