Why Companies Don't Fix Bugs

It depends. Some other reasons:

1. It's an enterprise product and the economic buyer doesn't know or care about bugs as much as checklisted features.

2. The company is not connecting the impact of fixing bugs to their bottom line. Or they are and estimate the impact to be low.

3. The code base is due for a rewrite so it would be a waste.

4. It's a side bet not worth the extra resources.

1 and 2 is the actual answer for any BigCo that I’ve been involved with. It’s quite simple: does fixing the bug affect the money firehose in the short or medium term? If so, fix it. If not, go work on things that involve widening the firehose of money.

3 is sometimes given lip service, but ultimately the only way 3 ever gets done is if someone in upper management pretends to care that 3 is important. Which is pretty rare

4 also happens but everyone thinks they are skunkworks engineer even when they are not

In my experience there is also a fifth possibility: If client is unaware of the bug, would “fixing it” lead to them filing a ticket because the application now behaves differently than expected?

I’ve also encountered several “load bearing bugs” where subsequent integrations/workflows were designed to accommodate the bug. Sometimes this was because the bug was known but couldn’t be fixed at the time, or the developers assumed the program was working correctly and accommodated the bug thinking it was expected behavior.

Therefore fixing the original bug would raise questions about what else needs to be updated as well.

With a lot of the products I support, I suspect the real reason is that they had originally hired outsourced programmers, or got rid of most of their in house programmers over the years, and literally have no ability to fix simple issues in a cost effective way. It's why they always try to push you to the next version of the program that is a ground up rewrite instead of continuing to support the existing version.

I like to call that category of bugs "landmines". Hidden till you step on them, then all hell breaks loose.

Obligatory xkcd: https://xkcd.com/1172/

For all the phone developers out there:

5. Fixing a bug means you have to go through a re review of your marketing assets that haven't changed in 3+ years and there's a non zero chance each time your review could result in _your app being removed from the storefront_ and losing _days_ of revenue after you appease whatever whimsical issue wasn't an issue the hundreds of times you've submitted previously and wait for the next review slot.

At work, we've also delayed the rollout of bug fixes by a month or three at times. If the customers are in a big Christmas / end of year / event rush, a known bug - that takes a minute to work around - is sometimes preferable to an unknown fix - that might cause the entire operation to stop for an hour.

We make a niche B2B software for a low-margin sector. For us it's definitely point 1.

We of course fix the serious issues, but we also leave a lot of bugs collecting virtual dust in our tracker.

While I know our customers get annoyed with bugs, they care a lot more about essential features and low price.

Now, we're in the process of incrementally rewriting our 20+ year old software, and code quality has a very high priority now. So hopefully the future will be brighter.

That said, our users are incredibly good at finding weird issues.

Never underestimate the power of the steady state of the system. Sometimes inaction is better than perfection :)