“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 migh

“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.