It was (probably) Murphy who said (something like) if there are two ways to do something and one of them with have disastrous consequences, the probability that someone will do it that way is 1. Thus, all good programmers ensure that pressing the wrong button at the wrong time will not cause things to blow up. Lumped in here are things like checking input, clicking in the wrong spot, pressing the delete key at the wrong moment. For these things and more we can ignore, correct or confirm inputs. Good. But you can't be pissed off when you click the wrong, but valid from the context, button and that functionality completes successfully.
For instance, there is functionality A and functionality B that both act on the current input. These functionalities are both executed thousands of times per day, there is no way to tell from context (previous operations) which one is more likely, and there is no time to have a confirmation. So when you have operators that click B when they mean A (and not notice - it is not like you can't cancel you B and put in an A) you have a training issue. There is nothing the system can do about it! That is not the worst of it though. What I really love is the service calls and bug requests saying that the reports for the operations on a certain terminal are “all screwed up, there are B's where there should not be.” So I take the 10 minutes that it takes to verify that there were no problems with the processing and what I find amounts to “That place where there was a B is because the operator pressed B.”
“Why is my transaction cancelled?” Because the operator cancelled it.
“Why did the upstairs bell ring?” Because the person pressed the top button.
“Why is there a charge of $0.01 on my credit card?” Uhh, because the cashier ran a transaction for 1 cent on your card?