Cruft Multiplies

Refactoring to keep the code clean should be done incrementally, not in spurts.

Consider defects. You have a perfect program, and I have a bunch of defects I'm going to inject into your program, which you then have to find and fix. Will you go faster if I put them in one at a time, or all at once?

Well, if you know there's only one defect (How on Earth do you know that? "TheSecondToLastBugHasJustBeenFixed?"...), when you find it, you're done. Then I put in another one, you find it, etc.

If I put even two of them in, they may interact in strange ways. They may even make the system look like it works, or drag you off in the wrong direction.

Refactoring should be done all the time for the same reason: the worse the system gets, the more the badness interacts and the more you have to do just to figure it out.

It's not like dust in your bedroom that just grows without getting fundamentally worse. It's like the dust attracts flies, which attract spiders, which attract birds ... and pretty soon there's a little old lady in your bedroom (http://crydee.sai.msu.su/public/lyrics/cs-uwp/m/misc.folk/old_lady_who_swollowed_a_fly).

(Leads to ExtremeFrustration)

c.f. TechnicalDebt

What is a cruft anyway?

Try the JargonFile -- http://info.astrian.net/jargon/terms/c/cruft.html

consider also PhilDick's notion of kipple (according to http://manor.york.ac.uk/new/kipple.html : It refers to the sinister type of rubbish which simply builds up without any human intervention. Eventually, one day, the entire world will have moved to a state of kipplization.)