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

61–70 of 77 posts

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

#61

Post by tagspace »

edelans wrote: post #41

I have seen this problem solved with a super simple bug classification that anyone can leverage (even customer success) associated with priority and time to fix expectations. 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…

This is actually exactly what we had in mind. Except that P2 gets put in a "won't fix" bucket.

- P0 means drop what you're doing and fix it now

- P1 means fix after you've finished what you're doing

- P2 means "won't fix" (but keep a note of it in case we ever get to that perfect situation where we have more time than features to build ;))

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

#62

Post by oblio »

throwawaythekey wrote: post #19

This is known as a zero bug policy [1]. I've had decent success implementing it with my team. The main advantages are: - 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 obvi…

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Article from back in 2000, based on info from ~1990.

> 5. Do you fix bugs before writing new code?

> To correct the problem, Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code.

Please read the entire article, it's worth it ;-)

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

#64

Post by popcorncowboy »

"Does this move the needle most?"

There is only so much dry powder. Every hour spent doing something that has lower bang:buck ratio in terms of "moving the needle" is an hour of powder burned. Make those hours count.

That said, correctly diving what moves the needle most is startup alchemy.

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

#65

Post by JohnDeHope »

This is how I've run my 1-3 man internal corporate line of business development teams for ~20 years. I've always handled bugs first. The biggest side effect I think you'll notice is that you are much more conservative about your architecture and what new features you allow. When everything becomes a potential show-stopper as soon a bug is found, you're much less inclined to try dumb stuff.

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

#66

Post by gadders »

oblio wrote: post #62
throwawaythekey wrote: post #19

This is known as a zero bug policy [1]. I've had decent success implementing it with my team. The main advantages are: - 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 obvi…

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... Article from back in 2000, based on info from ~1990. > 5. Do you fix bugs before writing new code? > To correct the problem, Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zer…

Knowing that essay is 20 years old makes me feel old.

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

#67

Post by moomoo11 »

Going to extremes never works like ONLY bug fixes or address tech debt for X time. Or only shipping features even if the foundation is shit.

The best option is to accept software is soft and malleable.

If it prints money but it’s some legacy code that smells like shit and has bugs, just write a new clean interface on top and build to it. Over time you’ll end up replacing the underlying system while shipping new features and fixing bugs as they pop up. Oh and the money keeps printing.

It it doesn’t print money and the code is shit, the project should just be scrapped. Who cares.

If people constantly keep building shit code and never improve, just quit because that company probably sucks.

Be extreme by being practical.

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

#69

Post by AA6YQ »

I develop and support DXLab, a suite of interoperating, free (but not open-source) applications for the worldwide amateur radio community; these applications continuously populate databases with realtime information, and interact with many other applications and physical devices (radios, antenna rotators) via serial ports, DDE, UDP, and TCP links. Since the first public release 22 years ago, my policy has been "all reported defects are corrected within 24 hours". Interaction with the user community is direct - via an online group. I typically make public releases bearing new functionality 2-3 times per month.

This policy's results have been excellent: users are focused on learning to better exploit the applications and suggesting new functionality rather than complaining about long-deferred defect repairs; even minor, easily worked-around defects create a negative user community mindset that can snowball. The absence of defects increases user confidence, and reduces user-perceived complexity.

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

#70

Post by drewcoo »

Great. Now what's a "bug" and what's actually not a bug but some other category of thing so that we don't have to drop whatever else we're doing to fix it?

Places with zero bugs policies seem to have much branchier defect taxonomies than everyone else.

I've also seen shops just decide to ignore entire classes of problems so that they don't put too many rows in their bug database. So, willful ignorance is another option. I don't recommend it, though.

Post reply on HN