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

A more refined approach is to triage the bugs into 4 or 5 levels of severity and then you might reasonably agree that at least all sev1 bugs must be fixed before new functionality is added.

Just using a bug triage categorisation of "will fix" or "won't fix" is not granular enough.

Do the thing that will produce the most customer happiness in the shortest amount of time next.

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.

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.

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

- Prioritizing is hard, so avoid wasting brain cycles deciding how important your bugs are

- It encourages all of your team to get things right the first time, because if they don't they know they will be going back to fix it immediately.

- If you want to create a culture of quality then it's an obvious first step.

- It saves time in the long term by addressing problems when you have the most context and by avoiding building hack upon hack upon hack

In extreme cases you can relax the policy, but be aware that if you don't quickly correct course then things will be permanently worse. Also accept that hard external deadlines are not suited to this approach, but using triage some of that can be mitigated.

[1] https://sookocheff.com/post/process/zero-bug-policy/

- 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!

In fact, I'd love something like this so much, I'd even be willing to sponsor efforts like that with a bit of cash.

Therefore go for release cycles. Lock features, fix all bugs, then release the version. Repeat for every cycle.

You might be forced to release with a few bugs. The conventional procedure is to publicly document the known bugs for each version.

If you are fighting fire with bugs, then you don't have stable product yet. Cut off up to a reasonable feature set and fix all bugs when you want to release.

Is it worth not making progress on any new features, all because of a smaller bug or issue? Can just one person work on the small bug while the rest of the team starts a new feature?

Sometimes the best bug fix is a new feature that depreciates the bug, so be sure to consider the estimated lifetime of the bug if you keep progressing your platform and maybe don't spend too much time fixing things that will be soon phased out anyways, unless they're really major issues that are rapidly hurting the business or reputation and need immediate fixing.

If you really want to halt all new features, I might try putting it on a calendar. Maybe you can afford 1 month, 1 quarter, or half a year on just bug fixing but eventually you have to keep moving forward in some way. Unless your platform is already pretty feature complete (which it doesn't sound like it is) you might do more harm than good when delaying your next core feature releases.

Another way to look at it is the delayed effect of doing nothing in either area. Bugs creeping in over the months and years may only become a problem when a competitor starts to be noticeably more stable.

Features that are delayed may have a delayed effect of a competitor getting ahead of you in the market and launching months before you'd be ready.

So I would say, "it depends". If you're in a growth market and are trying to capture market share, features might be best before non-critical bugs.

If you're in a stable market serving a huge amount of people, then fixing bugs has a much larger impact on your users.

You also have to consider the team and their morale over time. Too much churning through low value bugs can be demoralising where individuals might need some type of higher level thinking and creativity.

If it were me, I'd look at bugfix only sprints and adjust the frequency based on the above factors.

Two problem cases likely to pop up.

1) Lots of fixing when a bigger refactor is required. A poorly written area of code, or a poor design, may be causing high churn and wasted effort. The solution I’ve found to this problem is to track defects by code area and review once metric exceeds heuristic.

2) A team choked on defects only for a long period of time. This obviously has many negative side effects. It tends to happen in really important component and require most experienced developers. Any new starters run for the hills when a team gets into this state, therefore compounding the issues. The solution to this (though this is just my opinion), is to never allow 100% of time over [fixed interval] to be spent on defects. No more than 50%. The bugs will still get fixed, just take longer, and new development is still happening.

Overall though, I think a “defects first” approach is the right one, just have a plan for these negative cases.

Effectively, "I think this is important so I will argue you should work on this before that bug" is much better than "I think this is important so I will argue this is a bug."

YMMV, you have to adapt it to your usecase (B2B / B2C? contractual SLA? ...). But it can be something around:

  - P0 : a bug prevents a significant part of the customers (= paying users) to perform one of the core functionality of the product : at least one dev drops what he is doing right now and investigate, fix it himself or send it to someone responsible for the bug who should drop what he is doing right now and fix it. Target is to have it fixed in under a few hours. 
  - P1 : a bug prevents a few customers to perform an important yet non core functionality of the product: next dev available have a look at it. Target is to have it fixed in under a few days. 
  - P2 : a bug customers can live with (concerns few customers / there is a workaround / ... ) -> fixed in best effort, in practice, we fixed them when doing other features near that code. It can take a lot of time to fix them (if we ever fix them, and it's ok. The good thing about tech debt is that it's a debt you don't have to pay, when you remove/replace a feature for instance).