Entropy Reduction
Entropy Reduction"Entropy Reduction" is the part of the plan reserved for cleaning up the TechnicalDebt incurred by past development efforts.
EntropyReduction is the time to:
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.
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
EditText of this page
(last edited November 27, 2014)
or FindPage with title or text search