Zero-bugs policy is a myth

2 hours ago 2

By Michael Dubakov in Posts — 26 Sep 2025

Zero-bugs policy sounds great — but it’s a myth. Even top projects have bugs. Fix the critical 80% instead of chasing every tiny issue.

Linear recently claimed that they have a zero-bugs policy. It means they fix any reported bug within seven days. It may sound like a fantastic practice! Who wouldn’t want to have a bug-free software product? The reality is not that simple, though. Linear still has bugs. Any software product has bugs (well, except maybe trivial ones — but Linear is not trivial). So “zero-bugs” is somewhat misleading.

Open-Source Reality Check

Let’s check some popular open-source projects. They have great communities full of enthusiastic contributors. How many open issues do these projects have?

Rust: ~5k open bugs
Linux: 1.5k open issues (this is impressively low!)
VS Code: 3.5K open bugs
Tensorflow: 0.5K open bugs
...

As you can see, any relatively large and popular project has quite a few bugs. Why don’t communities fix them all? Because any community (and any company) has limited resources. With unlimited resources, of course you’d fix them all — but in the real, non-ideal world, you have to prioritize what to work on.

Linear fixed 2000 bugs last year! We fixed 1400, but we still have 2200 open bugs (and we fixed 7600 bugs in total in all these years, so ~80% of all bugs are fixed in Fibery).

Bugs ❤️ the Pareto principle

Let’s say you’re doing house cleaning. You could spend three days hunting down every tiny dust particle, scrubbing every small spot on the wall, and enjoy the total cleanliness for… a few hours. Or you could spend one day and remove almost all visible problems. I bet most of you would spend even less than that — like three to four hours tops — and be happy enough with the result.

I think the Pareto principle works well for house cleaning, and it works just as well for bugs: fix 80% of bugs and keep the 20% low-pain bugs open (pain isn’t so easy to measure, but still).

Importance

A zero-bugs policy treats every bug as if it’s very important. But that’s just not true.

Let’s say 1,000 users are complaining that your fancy task tracker lacks multi-assignment, and one user is unhappy about a misaligned icon in Arc browser. With a zero-bugs policy you’d have to fix the icon, but I’d personally go with the multi-assignment feature, since it generates much more pain for the product’s users right now.

Time vs. Importance

Some bugs take a lot of time to fix. It’s perfectly OK to spend days fixing a security vulnerability, a crash, or a data-loss bug. These have an outsized impact: they can break trust and cause churn. But spending that same amount of time on an obscure rendering glitch that only happens in Safari 14 when the user has three monitors and a custom zoom level? No way.

Time is also unpredictable with bugs. Sometimes you think, “I will fix it in 5 mins” and it turns into a day-long rabbit hole of debugging and refactoring. In our company we even have internal meme about "looks easy" phrase (said with some, but minor doubts), since in some cases it becomes very very hard.