As others have said, there probably isn't a tangible business justification to go back and fix a problem that isn't materially impacting a large percentage of c

As others have said, there probably isn't a tangible business justification to go back and fix a problem that isn't materially impacting a large percentage of customers. A lot of managers follow the Pareto (80-20) rule, which just means fix the top 20% of bugs, and 80% of your problems go away. The cost of actually fixing a bug is proportional to the amount of time which has elapsed since the code was written. The cheapest time to fix a bug, of course, is right when a programmer is initially writing something, and it only gets more expensive as time goes by. This is why writing unit tests is so important; if you can catch bugs up front you'll end up saving a lot of pain and agony of trying to go back and figure out what went wrong. Another important factor is there are a lot of politics in big companies. If there isn't an advocate (usually an engineer) who demands that a bug gets fixed, the bug probably isn't going to be fixed. The problem with advocating for something though means that you need to spend some political capital. When it comes to bugs, unfortunately there isn't a lot of positive political capital that you'll recapture as a result of fixing it. Managers aren't going to get praised for the lack of bugs in a particular piece of software, unless the software was buggy to begin with, someone complained loudly about it, and they went in and cleaned it up. If that happens and they were responsible for the bugs to begin with, they're probably not going to want to highlight the fact that it was their fault.