Hacker News Reader

Comment by bradwood | Hacker News Reader

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.

View on HN

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.

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

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.

"in practice this just means 3 or 4 levels of bugs that will never get fixed" - this is so spot on! This is exactly what we were thinking: realistically, if we don't fix it now, it will never actually get fixed.

So, if it's important enough to fix, why not fix it now.

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

I've never had much success getting a "won't fix" decision out of a PM or designer, and my time is too limited and valuable to spend debating it. If developers all know "low priority" means "never do" and "stakeholders" believe that their pet quibble will be fixed one day (even though they will never allocate time to do that) then work can continue in a sensible fashion.

Reply on news.ycombinator.com