From software company Linear, a blog post from last year titled Why we committed to a zero-bugs policy:

When we tell people that Linear maintains a zero-bug policy a common response is disbelief. It may sound like a ridiculous approach, but we do it because no other way makes sense.

The zero-bug stance means that we address bugs immediately, with the exact number of days depending on the severity: low-priority bugs need to be addressed within 7 days, high-priority bugs within 2. We formalized this approach two years ago. The impetus was actually a bug in a popular consumer app that I had reported to their team. Finally two years ago—and five years after I first reported the bug—I saw that it got fixed. I thought to myself, “wow, millions of users suffered through this bug for years for no reason.” If the company was going to fix the bug eventually, it would have been so much better to fix it right away.

That’s the big idea behind our zero-bug policy. We want Linear to be a solid, high-quality product, which means we’re going to address any bug that comes in. Fixing a bug takes the same amount of work whether we do it right away or put it off. But it’s not a zero-sum game: fixing it immediately gives us a higher-quality product and spares users unnecessary pain for the same overall effort.

It’s worth a read – especially if you’re a software quality process wonk – with some interesting observations on context switching and other things, for example:

I’ve heard stories of companies whose backlogs grow to thousands of bugs. Eventually, instead of fixing the bugs, they just delete the whole thing and start over. It’s a reflection of how when you put bugs in a backlog, in most cases what you’re really saying is you’re never going to get to them.

I also applaud the team for recognizing and pointing to the momentum boost and virtuous cycle on both sides – makers and their customers – when something gets fixed quickly after being reported:

It’s not uncommon for Customer Support to file a bug in the morning—often through our Intercom integration—and have it fixed by lunch. That kind of turnaround allows us to turn a bad experience—an encounter with a bug—into an excellent one that changes their whole perspective on what it’s like to reach out to a company when something is broken.

Over time these experiences have molded the way our user base reacts to imperfections in the product. Instead of coming to us angry or frustrated, we find many users write to us in a spirit of collaboration—working hand in hand with us to make Linear a better product because they trust we’ll respond quickly. It also often turns them into Linear advocates.

However, there’s one thing that feels unresolved. The post says “low-priority bugs need to be addressed within 7 days, high-priority bugs within 2” – but what if a bug cannot be fixed within these time limits? I can think of a few reasons:

• a bug has a dependency on another, slower-moving piece of software (e.g. the browser or the operating system),
• the fix is a bigger systemic or change management challenge that will take months if not years to complete (e.g. a keyboard shortcut change or an internal migration),
• the fix requires a redesign larger than initially suspected,
• the team disagrees internally on the fix and needs time to hash it out.

I know getting deeper into the weeds would not make for a nice post with a punchy ending, but I also think the system feels incomplete this way – as with every process, a careless application of a “zero-bugs policy” could fall prey to a sibling of Goodhart’s Law, as the team starts deluding itself into categorizing things as “not bugs,” or find other ways to avoid bigger challenges if they cannot be fixed within the given time limits. Black-and-white systems struggle with shades of gray, and I’d be curious what is Linear’s answer to tackling this tricky part.