[Yizahi]

On a sufficiently complex product it is impossible to fix all known bugs, even classified as will fix. Another issue - it will take so much time that your company will be left behind by the competitors. Maybe less so in the web, but with hardware it's a question of multiyear contracts, so getting abandoned by a big customer in favor of a feature rich competitor may mean that you won't get a second chance with them any time soon. Of course a reverse happens too - if your market leading product is more and more buggy over time, they may abandon you or force to fix most bugs, or force to do significant structural changes etc.

[ThomasRedstone]

As systems get more complex slowing down and getting bugs fixed becomes more and more important. If you don't fix them fairly quickly you end up with code elsewhere (either consumers of your APIs, or within your own application) adapting to your bug, leaving you with new bugs when you get around to fixing it!

[tagspace]

> On a sufficiently complex product it is impossible to fix all known bugs

You really think so?

Surely it's just a matter of picking a sufficiently high bar for "will fix" and then focusing some time on it.

[Yizahi]

We had a P0 bug which caused unplanned device reboots in the field with unclear cause. It is still open, 3 years since first detection. And it looks like it will be open until device end of life. We have a mitigation for which affects performance, and that's about it. It was tracked down to deep inside Linux kernel and some firmware interactions and no amount of work produced a fix for it. And that was a mission critical bug, which was pushed by the biggest and super important customer (and others too).