I have seen some dirty code in my time. I have heard varied feedback about dirty fixes too:a) a dirty fix is not a fix b) some fixes dirtier than others but dirty   fixes are not acceptable c) some fixes dirtier than others and some   dirty fixes are more acceptable than   others d) dirty fixes show a   pragmatic use of ones time but should   be discouraged e) dirty fixes show a   pragmatic use of ones time and should   not be discouraged f) otherWhich of the above would you agree with and why? How do you stop attitudes like (e) from becoming standard practice?
Are all dirty fixes created equal?
maintainability
A 'dirty' fix is a form of Technical Debt and whether you can afford it is ultimately down to a cost/benefit analysis.With apologies to Olve Maudel who (in a lightning talk(p3) at the ACCU conference) may have said something not completely unlike the following, compare:The immediate cost of fixing a bug properly + the immediate cost of not having it fixed in timevs.The immediate cost of a dirty fix + the ongoing long term cost of the dirty fixIf fixing it properly, means that you miss a deadline that would have got you a staged payment, or means that a competitor gets to market before you, then that cost could be quite high and it may have been worth incurring the technical debt instead. But remember that the longer you leave that debt unpaid, the more interest you are going to accrue in terms of the cost of supporting the code and adding new features.Beware though, if you use being pragmatic as an excuse for laziness and keep on racking up the technical debt, but never pay off earlier debt through re-factoring, you may find that the debt rises so high that bankruptcy is the only remaining pragmatic option. *8')