I don't believe your nitpick is valid here. True, sometimes one has to code under pressure, in the sense that money is lost (or, at least not made) while things are down, but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do. In fact, if the worst consequence of waiting 30 minutes to deploy a temporary fix is that some more money gets lost, I would argue you should almost always do that rather than deploying code that might have even worse consequences.

> but there's almost never a situation where you can't stop and take an extra 20 or 30 minutes to check to see that your code would do what you expect it to do

The implication in these examples is that you're doing it on your own, always, and... that's generally bad, especially with a known bug. Most of the bugs I have created have been ones where I've specifically not talked through the logic with someone else (usually a client/stakeholder, or domain expert, or whatever) to determine that my understanding is correct (might need more tests or to adjust existing tests to reflect a better understanding of the issue, etc). These 'emergency bug fixes that must be dealt with on the spot in minutes!' scenarios are more likely that cause of the issues in the first place.

I suppose we've been exposed to different parts of the software elephant.

When I say money is lost... it can potentially be a lot of money. Can you imagine what 10 minutes of downtime could cost Amazon, for instance? What about streaming the superbowl? Credit card payment processors? Even something simple like the test harness for a production line may mean that an entire shift of assembly workers now has to stand idle or sweep the floor. When your company is losing thousands of dollars per minute you will understand what I'm talking about.

I understand the concept of multiplication. In such a scenario, it is even more imperative that the fix you make (temporary though it may be) actually fix things. Take the time, get all the help you need, and get it done; don’t just commit code and pray.

There are times when you need to think about the fix, and times when the problem is more obvious. If possible, I'd hack in a fix and, once the pressure is off, go back and validate it more thoroughly.

For instance, my company had a very important demo of our new system on Monday. Friday night my friend was tearing his hair out in the lab trying to find the cause of some network corruption. We had a race condition in the kernel between our network driver and inter-processor communication driver. We're a uniprocessor system, so I suggested just using an if-check to see if we were in the IPC code when the network bottom-half handler hit. It was a disgusting hack but we made the demo and no one had to work the weekend. The following week, my friend crafted a correct solution which was robust even if we enabled more cores. It's not the high-pressure straw man I mentioned earlier, but it's fresh in my mind and represents the sort of on-the-fly hacks that often need to be made to allow businesses to make money.