If you have an appropriate test in place to ensure that the bug does not reoccur, then you are free to refactor to the better solution once the immediate pressure has been relieved.

I think one additional analogy to consider before we start thinking about the hippocratic oath of doctors: Take the following scenario. A patient has a serious infection in their foot. If antibiotics aren’t working the “best” solution would be to develop a better antibiotic, or maybe they know of a new experimental treatment that hasn’t been approved yet? And while it may look like a “hacky” solution to the problem, the only realistic & proven option available to save the patient’s life is to cut off the leg. A Dr’s oath is to do no harm but they don’t gamble with life.

96% (a laymans guess) of Software development is likely never to be life & death, but when it comes to delivering a product on-time at quality that you’re 75% happy with, or significantly late & 90% happy with? Sorry, I’ll choose 75% and live with it, but seek to improve that quality every chance I get. I strive to do no harm, but I do not gamble with other people’s commitments and money by insisting on unproven tools & technologies, or risk delaying deadlines with potentially risky re-factors. TDD helps, but it is by no means a safety net for big changes, tests are only as good as the developer that writes them. I am but 1 person working on a product used by thousands; I’m never going to think of every combination their devious minds come up with. I have minimum standards that I will fight to never drop below, and insist of with other developers I work with. Everything above that is icing on the cake that I propose to the people paying the bills to make the product better, but ultimately it’s their choice.