I agree. At some point you have to admit to yourself that the hacks and workarounds you're piling on are getting too intricate, and could collapse under their own weight, and certain parts of your code are going to need a serious refactor.

I think the battle we wage in our minds is that smaller fixes and additions require a lot less time in and of themselves, and because they touch less of the code, are less likely to introduce bugs. However, the more of these fixes we implement, the more time we spend on them, and the harder they can be to understand. They can require a lot of documentation (because someone not familiar with the code might look at it and think "what the *^&^%'s going on here?!"), and generally cause a headache for everyone.

There's a not-easily-definable point when working around design flaws becomes a more time (and money) consuming endeavour than refactoring. (And even if you can define that point, a bigger task is often convincing management that only urgent bug fixes can be attended to while you rewrite several core modules).

I don't agree that these changes should never be applied to production code. A good release policy and regression tests will help to catch any introduced bugs, and it's often worth the pain in the long run at any rate.