There are redundancies that should be set up in the development process for this reason.
Admitting the mistake gives you nothing but low opinion of everyone involved. (which is in itself sad) The only thing to do is to set up whole systems to prevent them from arising again. But that is expensive so is not done. Instead, everyone is moderately discontented with the junk they use.
The goal is to produce, as efficiently as possible, programs that work adequately for their intended purpose. "Work adequately" does not mean perfection. The optimal solution has failures in almost all directions - not-quite-rigorous processes, not catching all bugs, not testing all scenarios, just-barely-adequate code review, just-barely-adequate tests, and so on. To "improve" any of those would be to make the whole process more inefficient.
That's at best, when management knows what they're doing. At worst, those things are totally missing, and technical debt kills you later.
I'm assuming the above is sarcasm?
> There are redundancies that should be > set up in the development process for > this reason.
Of course there should be tests, redundancies, fault-tolerant mechanisms and recovery systems _when_ errors/disasters occur. But these constructs are only functions of investments in time and money - and there is no absolute endpoint for tests which can signal that a program is completely error-free, only sufficiently error-free. And that word "sufficiently" is function of money and time. Developers and sponsors make explicit decisions about how much and what kind of testing is sufficient.
> Admitting the mistake gives you nothing > but low opinion of everyone involved. > (which is in itself sad)
If that has been your experience, would you mind sharing the anecdote(s)?