We committed to a zero-bugs policy(linear.app)
linear.app
We committed to a zero-bugs policy
https://linear.app/now/zero-bugs-policy
4 comments
It would be interesting to know how many of bugs are triaged and declared as "won't fix" in order to comply with the zero bugs policy.
Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.
Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.
Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.
Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.
It leaves close to no room for prioritization because the prioritization is predefined via the policy. We've had bugs on edge cases - the odds of an end user hitting them was very small (but not zero). Either the product owner (or whatever you want to call them) gets to prioritize the backlog, or its someone else - in this case it sounds like the engineering team.
In the world we have more than just bugs. We also have features, and refactoring and whatnot. Prioritization should be done across all tasks, so a bug could be "medium" but the team might not even work on bugs this week unless they are a show stopper.
Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?
Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?
> The zero-bug stance means that we address bugs immediately
That's the key part. What does it mean "address"? I worked in organizations, where a dev could push any fix to dev basically anytime. CI pipeline would get the fix deployed in 3 minutes and it's there. However, getting that fix to production and to the end user was a completely different story. It required hours or even days of concentrated effort in managing all the communication. Justifying an out-of-process deploy was painful enough. So most people wouldn't do it, the bug will be fixed in the next quarterly release anyway, and my paycheck is the same, so why bother?