"Entropy Reduction" is the part of the plan reserved for cleaning up the TechnicalDebt incurred by past development efforts.

EntropyReduction is the time to:
	* discover and harvest reuse opportunities (i.e., JustTooLateReuse)
	* do ''post hoc'' code reviews to look for work that will need to be scheduled
	* clean up comments
	* upgrade to the new version of the compiler
	* reorganize files, source-code control hierarchies, makefiles, etc.
--DaveSmith

-----------------------------------------

This phrase has been a hobby-horse of ours for a long
time. We tend to focus more on how the code gets better rather than on the more custodial aspects of cleaning up the mess you made during a growth spurt. The switching between growth and clean up can be quite fine grained (a quick,
ooh, I've got a chance to make x better while I'm doing y), to very coarse grained (a project post-mortem).  (That is, the timescale is fractal too.) 

See, for instance: http://www.laputan.org/lifecycle/lifecycle.html#Consolidate, and
http://www.laputan.org/metamorphosis/metamorphosis.html#SoftwareTectonics, http://www.laputan.org/mud/mud.html#PiecemealGrowth,
and even http://www.laputan.org/frameworks/ruminations.html#Consolidate and http://www.laputan.org/frameworks/fractal.html.

The idea is that you improve the system opportunistically, when
hindsight hands you "LowHangingFruit" that is ripe for
the picking, rather than trying for design "holes-in-one" up-
front.  For this to work, design has to pervade the lifecycle, and
the organization, and individual artifacts will have lifecycles of their own
that play out within and beyond the applications that spawn them.

More could be said, at the risk of strip-mining the aforementioned URLs.

A big problem is getting managers to leave time for entropy reduction.  We need to create the expectation that good managers would no more push their ace
architect-builders onto the next project w/o leaving ER time than they would start their star pitchers with only three days rest.

--BrianFoote

----
I've found that repeating the mantra "we can do that, but we'll incur TechnicalDebt that we'll need to pay off later" can sensitize management.  When they later hear "time to schedule some EntropyReduction to pay off some of our TechnicalDebt," they won't resist quite as much. --DaveSmith

Another strategy is to reduce the cycles of EntropyReduction so much that they fall under management radar. This only works if you can do big refactorings a half hour at a time. I'm learning how, so I believe it's possible. --KentBeck

I'm also still learning how to do this.  One thing I've learnt is that it's really important to have a good ConfigurationManagement system so that you can back out of the refactoring changes if they turn out not to be such a good idea as you first thought.  The thing I'm wondering about now is the issue of BigBang refactoring: it seems risky and expensive to pull the whole thing apart to clean it up, but sometimes that's necessary.  Perhaps it's better to throw (some of) it away at that point and start from scratch. -- MartinPool

A good ConfigurationManagement system is always a good idea, but after repeating the pattern above many times, I finally got smarter and started making a little plan before touching the code.  I believe it's faster overall, and it avoids the problem where many false starts each produce a little something of value and then there are too many saved versions to hunt through to find all the pieces. --WaldenMathews