And you're right, most companies tier their application importance. "Does the business die if this doesn't work" gets the top tier. "Does it make us money" comes next. Then after that point the amount of oxygen left in the room starts dropping significantly.
And you think "Well, if I was working on that low tier project, I would want to do a good job". And that's the thing, if you start doing good work there, you're going to get yanked off that team and moved up to something more important. You end up with either a dead sea effect on unimportant projects, or so little time for them it cannot possibly be polished.
I _wish_ the quality were better, but I can totally see why "good enough" is king, especially when times are good.
Introducing bug fixes may ship additional bugs. That's a real risk.
The scale of the system needed to get you and your luggage flying overseas in an economically viable way says a lot about how amazing the current system is. But sure, complain about HTML tags being printed and assume you could do better.
I appreciate the scale of the system. If your argument is that such a large system cannot be more bug-free than it is, we can just agree to disagree.
But if you're saying it's not worth it financially to fix these bugs, then we can at least agree with that.
Fast forward a few centuries, everything is being automated, and what happens...
Or it was fixed, but not commited
The fix wasn't the right fix, or applied to the right place, because the bug report was bad
The fix worked on the tester's device
It worked, but was broken by another fix
It wasn't checked again after it was 'fixed'
etc
I figured none of these things stopped me from paying them, so they have no reason to fix them.
But like the PDF with the HTML on it--no one even looked at the output. No developer, no QA, no test users. Or if they did, they didn't care. They just shipped it.
I'd have been embarrassed, but since having a dev fix it would apparently be a net loss to the company, it would have been wrong to do.