4 ms·

I really like the idea of zero-bug policies but I struggle with them in practice. For those who do this (post author or anyone else here), how do you deal with

I really like the idea of zero-bug policies but I struggle with them in practice. For those who do this (post author or anyone else here), how do you deal with low-impact bugs? As a concrete example, we're building a chat toolkit. One customer observed that in some versions of Firefox, when combining a particular set of features in our product, the scroll position wouldn't be remembered. This was 100% a bug. It's also an edge case of an edge case that likely only happened for this one customer, and even there, had a relatively small impact on UX for a small subset of their users. It was essentially a browser bug, and fixing it would require a big workaround that made one component of our product significantly more complex (and thus more prone to other bugs). With a zero bug policy, we'd have to fix that before shipping anything else. But it made no business sense to do so, very much in the same sense that building a niche feature used by tiny % of customers tends to make no sense. But once you let that one fly, there's no zero-bug policy left, right? You can just declare any bug as "not important enough right now" and -poof!- zero bugs! Yay, time to ship features. For context, I'm talking a comparably small, tight-knit team as the author.

joshdev 6y ago
I think having a zero P0 and P1 bug policy makes sense. As others have said some bugs may not make business sense to fix. I do think it is useful to set thresholds for other bug priorities as well. 1,000 P2 bugs may make your product feel unusable.
Alex3917 6y ago
>But once you let that one fly, there's no zero-bug policy left, right? If you know what the fix entails and have decided that the fix will make the product worse then that seems different than just not fixing a bug because it's not important enough to look into. If you don't know why the product is broken and what the fix will entail then there could be serious underlying problems that you don't know about and which are getting more expensive to fix with every passing day, but it sounds like that isn't a factor in this case. To me a zero bug policy doesn't mean that the product will work for every person and every use case, but rather that it's working as intended and there aren't things that are broken for reasons that no one understands.
- paulryanrogers 6y ago
  I.e. zero-unknown bugs?
  - Alex3917 6y ago
    More like you're allowed to make informed design decisions that have known trade offs. But you have to actually own the issue and promote it to being a purposeful design decision.
staticassertion 6y ago
Based on the article the goal is not to have 0 bugs, it is to strive for 0 bugs. Bugs are prioritized highly, testing becomes front and center, bug reports are triaged and well documented. I would perhaps call this "Bug first policy" vs "Feature first policy", or some such thing, versus "0 bugs"
Archelaos 6y ago
Have you considered fixing the browser bug by providing a patch?
- skrebbel 6y ago
  I have not. The browser is written in C++, a language that I have not touched for 15 years, and I'm 100% unfamiliar with the codebase. Just getting it to compile on my box would likely be more time consuming than I'd be willing to spend. I don't even think I have a C++ compiler on my computer anymore.
murgindrag 6y ago
I like zero bug policies in my code. If it's a browser bug, it's a bug not in my code. My experience is that you pay a premium early on, but it pays dividends down the line. At some point, little bugs interact. A big correlary of "zero bug" is "clean, simple architecture." If fixing bugs increases complexity, that's usually a symptom of something deeper....
oso2k 6y ago
For me, it's the Principle of Least Surprise [0]. While you may consider it a browser bug, but, your bug is not checking for the set of enabled product features and browser version then warning the user, or (better) protecting the user somehow from that situation. You might not have the resources to fix the browser issue. But, you are aware of the situation and it seems rude to not take the opportunity to "apologize" for issue when it occurs or you know it will occur. Imagine now your system is a Safety Critical System [1]. Not warning could harm someone by using your system or allow someone to be harmed by being caught unawares. [0] https://en.m.wikipedia.org/wiki/Principle_of_least_astonishment https://en.m.wikipedia.org/wiki/Principle_of_least_astonishm... [1] https://en.m.wikipedia.org/wiki/Safety-critical_system https://en.m.wikipedia.org/wiki/Safety-critical_system
jdlshore 6y ago
I follow a zero bug policy, and have taught several teams to do so. The policy is that we fix every bug immediately, or decide that it is so unimportant it should never be fixed. Bugs that are unimportant are neither fixed nor tracked. Edit: Example of an unimportant bug that I remember: “On Safari, when you resize the browser window, phantom lines appear temporarily in parts of the web page.” We decided it was unimportant because it only happened on desktop Safari, the impact was minor, and it would have been hard to fix.

joshdev 6y ago

I think having a zero P0 and P1 bug policy makes sense. As others have said some bugs may not make business sense to fix. I do think it is useful to set thresholds for other bug priorities as well. 1,000 P2 bugs may make your product feel unusable.

Alex3917 6y ago

>But once you let that one fly, there's no zero-bug policy left, right? If you know what the fix entails and have decided that the fix will make the product worse then that seems different than just not fixing a bug because it's not important enough to look into. If you don't know why the product is broken and what the fix will entail then there could be serious underlying problems that you don't know about and which are getting more expensive to fix with every passing day, but it sounds like that isn't a factor in this case. To me a zero bug policy doesn't mean that the product will work for every person and every use case, but rather that it's working as intended and there aren't things that are broken for reasons that no one understands.

paulryanrogers 6y ago
I.e. zero-unknown bugs?
- Alex3917 6y ago
  More like you're allowed to make informed design decisions that have known trade offs. But you have to actually own the issue and promote it to being a purposeful design decision.

staticassertion 6y ago

Based on the article the goal is not to have 0 bugs, it is to strive for 0 bugs. Bugs are prioritized highly, testing becomes front and center, bug reports are triaged and well documented. I would perhaps call this "Bug first policy" vs "Feature first policy", or some such thing, versus "0 bugs"

Archelaos 6y ago

Have you considered fixing the browser bug by providing a patch?

skrebbel 6y ago
I have not. The browser is written in C++, a language that I have not touched for 15 years, and I'm 100% unfamiliar with the codebase. Just getting it to compile on my box would likely be more time consuming than I'd be willing to spend. I don't even think I have a C++ compiler on my computer anymore.

murgindrag 6y ago

I like zero bug policies in my code. If it's a browser bug, it's a bug not in my code. My experience is that you pay a premium early on, but it pays dividends down the line. At some point, little bugs interact. A big correlary of "zero bug" is "clean, simple architecture." If fixing bugs increases complexity, that's usually a symptom of something deeper....

oso2k 6y ago

For me, it's the Principle of Least Surprise [0]. While you may consider it a browser bug, but, your bug is not checking for the set of enabled product features and browser version then warning the user, or (better) protecting the user somehow from that situation. You might not have the resources to fix the browser issue. But, you are aware of the situation and it seems rude to not take the opportunity to "apologize" for issue when it occurs or you know it will occur. Imagine now your system is a Safety Critical System [1]. Not warning could harm someone by using your system or allow someone to be harmed by being caught unawares. [0] https://en.m.wikipedia.org/wiki/Principle_of_least_astonishment https://en.m.wikipedia.org/wiki/Principle_of_least_astonishm... [1] https://en.m.wikipedia.org/wiki/Safety-critical_system https://en.m.wikipedia.org/wiki/Safety-critical_system

jdlshore 6y ago

I follow a zero bug policy, and have taught several teams to do so. The policy is that we fix every bug immediately, or decide that it is so unimportant it should never be fixed. Bugs that are unimportant are neither fixed nor tracked. Edit: Example of an unimportant bug that I remember: “On Safari, when you resize the browser window, phantom lines appear temporarily in parts of the web page.” We decided it was unimportant because it only happened on desktop Safari, the impact was minor, and it would have been hard to fix.