
The Zero Bug Policy - elorant
https://sookocheff.com/post/process/zero-bug-policy/
======
makecheck
“Zero” rules are vulnerable to abuse and leads should not be naive about this.
You’re not fixing bugs, you’re sweeping them into a hole.

For example, how might a team reduce its backlog easily? It could close year-
old bugs (that obviously look bad), giving vague or no explanation, and assume
that any _real_ issue will be opened as a new bug again. The project clearly
doesn’t have any fewer problems, it just has problems that are now much harder
to track.

Also, “zero” is a number, saying nothing at all about realistic strategies for
getting there. Some bugs are fundamental flaws requiring gargantuan rework.
Some take weeks to understand but _literally one line fixes_ (like setting a 0
to 1). Shouldn’t we at least have a handle on categories of problems and how
to “zero” certain subsets of issues, and how to make progress? How do we keep
people from getting promoted for closing 50 trivial bugs and firing the guy
who spent a month on nothing but one huge and more-crucial problem?

And pity the new manager who comes along and sees “few” bugs; they’d better
start looking under rocks. The entire state of the project that they’re taking
over may be misrepresented.

