[throwawaythekey]

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

[oblio]

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 ;-)

[drewcoo]

I was there a little after and his division nor mine still had any such policy.

Joel worked on Office. Have you heard the hair-on-fire customer stories about Office from the 90s? It was a draconian response to what was probably seen as a serious company-wide problem at the time.

[gadders]

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

[wink]

One slightly different approach I've seen at some more old school industry customer: A bug with a semi-doable workaround is usually not urgent. This is less a problem with a more continuous deployment, but if your release cycles are measured in weeks or low-digit months, it's just often not feasible to roll back or hotfix, if the (even breaking) bug can be worked around somehow.

That made me rethink my usual "prioritize urgent bugfixes over features" stance, but it works better if you have a lower number of (known) users who communicate, over a mass audience.

[tagspace]

That's a really good point. If your userbase is feels listened to (which is admittedly easier in B2B than B2C) then these decisions become much easier.