Red means a test has failed. A good practice is to write a test first, see it red, then make it green by the most direct path. When this leads to foolish duplication, resolve to change whatever is necessary to make for the cleanest expression possible for the solution up to now.
This relentless refactoring leads to eventual stability when either all forces have been resolved or familiarity with the quirks of near resolution offers acceptable productivity. In this later case, our sense of cleanliness has been distorted by familiarity.
Explain the debt metaphor as justification for refactoring.
Distinguish technical debt as a strategy rather than the outcome of careless ignorance.
Observe that even clean code will resist the addition of new functionality. This is especially true when familiarity with previous function has wained.
Explain how one might make a place for new function before setting out to create that function.
Explain the danger of refactoring for function not yet written. The existing cases present a drag upon the creative mind.
Explain how the radical modularity of objects permit the coexistence of alternative architectures within a single running program.
Explain how an alternate architecture can effect the slow migration of features from the weaker to the stronger. A reverse of the usual bit-rot.
Justify this architectural competition on both economic and ecological grounds.
Distinguish this use of refactoring from that usually assumed by the proponents of relentless refactoring.