Sometimes it may be tempting, upon getting a whiff of a CodeSmell, to develop a workaround for the problem and thus "neatly" side-step it (WeWillCleanItUpLater - also known as WillyWonkaConflictResolution). Don't. This approach, if used often, will lead only to your producing a BigBallOfMud. AnalyzeMercilessly, then RefactorMercilessly. If you do this enough, then your code may be WhatWeWantedAllAlong.

This should be fairly obvious, but you'd be surprised what people do sometimes to avoid what they perceive as harder work (a common problem with clueless newbies).

''But,''

''This is not universal advice. Sometimes the symptoms are important to treat as well, especially if they are dangerous in the short term. If I've got a high fever from a bacterial infection, I should take antibiotics to treat the infection, but I should also take an ice bath if the fever is so high that it could damage my health before the antibiotics kick in. In software, if I need to ship the software today in order to meet a hard commitment to the customer, I should apply the 1 hour patch now and ship it, rather than apply the 1 day solution and miss the ship (and then of course apply the 1 day solution after the successful ship).''

I was talking about CodeSmell''''''s, not infections. As to shipping, that's a StrawMan. Of course you're not going to have time to go in and rework the code from scratch when you have one day left. My point was that one should explicitly avoid WillyWonkaConflictResolution.

[I agree.  Treating symptoms works so well on humans because humans have built in repair systems.  Many human diseases will run their course (trigger the creation of antibodies then die out or go dormant) if the symptoms don't kill you first.  With code you still have to refactor by hand.  Maybe someday software development will have automated processes that treat the cause.  Part of the lure of XP has been that it comes close to automating that sort of thing.  MercilessRefactoring, OnceAndOnlyOnce, UnitTest''''''ing applied rigorously can work marvels on smelly code.  And since big chunks of them are simple enough to be automated, the effort required to apply them is decreasing rapidly.  I've been using the latest version of Eclipse (2.1, I think), and it's amazing how little thought or time is required to for me to create a unit test, use it to guide debugging and perform some really useful refactorings.  The IDE needs less and less of my input to keep the code clean at the source.  It seems awfully close to doing it on its own. -- EricHodges]

The point is that you cannot apply TreatTheCauseNotTheSymptoms blindly, because sometimes the symptoms are the right thing to treat and not the cause. We shouldn't forget about the number 1 thing software should do: deliver value to the customer. It is irresponsible to 'treat the cause' and if the customer doesn't need the long fix. This is just a restatement of YouArentGonnaNeedIt. 

''No it's not. That's about doing things that you don't need. This is about not doing things that you ''do'' need. Anyway, I disagree - the customer ''always'' needs the long fix. They may well not know it, though. Did you hear about that whole MillenniumBug thing? Those big companies needed the long fix, but they thought they were getting plenty of value twenty years ago when their systems were programmed.''

I agree with the sentiment, but the context sometimes mitigates against this approach. DoTheSimplestThingThatCouldPossiblyWork, and all that. The XP guys are particularly harsh in this regard.