Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 77 posts

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

#1

Post by tagspace »

At Trevor.io we recently released some fundamental changes to our platform, which, unsurprisingly, came with a handful of bugs. This triggered a debate among the team: which bugs do we fix now? Which do we fix later? And when is later? If we don't fix them now, will we realistically ever fix them?

This led us to an interesting question: what if we just split all bugs into "will fix" and "won't fix", 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.

Has anybody tried this? Can it work?

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

#2

Post by DamonHD »

If you fix all problems before doing anything new, assuming that you (team, customers) can even agree a threshold of seriousness for 'bug', you will ossify. A reckless opposite of never bothering to fix bugs, and just being 'disruptive' for the sake of it, is also unworkable.

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

#4

Post by tagspace »

DamonHD wrote: post #2

If you fix all problems before doing anything new, assuming that you (team, customers) can even agree a threshold of seriousness for 'bug', you will ossify. A reckless opposite of never bothering to fix bugs, and just being 'disruptive' for the sake of it, is also unworkable.

What do you mean by "ossify"? You think in practice there will always be bugs, so we will stop moving forwards?

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

#5

Post by bradwood »

This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience.

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.

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

#6

Post by bradwood »

Ask yourself: given the system in its current state what change will make my customers most happy? Is it fixing this bug, or is it shipping this new feature?

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

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

#7

Post by drstewart »

bradwood wrote: post #5

This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience. 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…

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

Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean.

Okay, I'm joking. Sometimes those bugs become old enough they refer to features that no longer exist or can't be reproduced and then get marked as "won't fix"

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

#8

Post by bradwood »

drstewart wrote: post #7
bradwood wrote: post #5

This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience. 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…

>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. Of course, in practice this just means 3 or 4 levels of bugs that will never get fixed and languish in a backlog until the team / project gets re-orged and the entire backlog is wiped clean. Okay, I'm joking. Sometimes those bugs…

So be it, if that's the case. At least it showed that a proper trade-off between features and bugs was made at the time. Remember that the triage can and should be rerun from time to time. Already open bugs could then be down- or upgraded in their severity as context evolves.

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

#9

Post by DamonHD »

tagspace wrote: post #4
DamonHD wrote: post #2

If you fix all problems before doing anything new, assuming that you (team, customers) can even agree a threshold of seriousness for 'bug', you will ossify. A reckless opposite of never bothering to fix bugs, and just being 'disruptive' for the sake of it, is also unworkable.

What do you mean by "ossify"? You think in practice there will always be bugs, so we will stop moving forwards?

Yes.

And in the extreme case one customer (or a competitor on the sly posing as one) decides that one minor (mis)feature that they don't like is a bug and doesn't accept any fixes to it as adequate, what do you do?

Overserialisation of life (and other extreme position taking) is unproductive. Some new things will happen while others get fixed or not. Sometimes you won't even know how to fix 'bugs' without trying new things out.

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

#10

Post by ricardobayes »

bradwood wrote: post #5

This is a blunt and unworkable approach. Stopping the shipping of any feature because some bug exists doesn't take what is important into account: the user experience. 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…

I think the opposite is unworkable, namely just shipping new features and thus building on top of a murky foundation. I know a company that did this and basically needed to set up a taskforce and spend 2-3 months of the whole department's effort (around 50 people) on fixing a bug that that was low in the stack but they just kept building on top of it. So in my experience, a correct approach is indeed to try to eradicate all known issues in every release cycle by running and completing the regression tests. Yes if that means slowing down a feature release by 2-3 days then that's the cost of having a bug-free application. I read somewhere that users don't care about features if they encounter bugs, they abandon the product rather easily.
Post reply on HN