We had a backend process that connected out to a network and did some things. However, the network it connected to changed their protocol, so our backend process was broken - didn't do anything - completely non functional.
We created a fix, but had to wait for it to go through QA for ages. What's the worst that could happen? It doesn't do anything like the current version? It wasn't even a massive update. Maddening.
Likewise, more likely it could just not work well, be buggy and require several updates to get it right, burning out your team's (or your company's) image with the customer. Before you deployed your fix, it's whoever changed the protocol at fault. After that, it's you that can't fix it.
Again, not justifing it taking ages, just saying there's never an excuse to skip QA.
The worst case was that it maxes out the connection and burns through bandwidth. But that's something that can be monitored.
The customer would have rather had something working with the network, than something broken with the network.
In that particular circumstance, there's always an excuse to skip QA. IMHO.
No, there isn't!
Thats a good point (even though in this case it turns out not to be true).
Seems like the right answer is to back out the change.