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.