''(This pattern is similar the one described in "TechnicalDebt" -- it differs in its aggressiveness towards technical debt.)''

TechnicalDebt slows down project development.  TechnicalDebt slowly builds up and isn't the programmers' primary concern.  As a result, it doesn't go away without active intervention.  Therefore, agressively seek out and eliminate TechnicalDebt.

DesignDebt is a special case of TechnicalDebt.  EliminateDesignDebt as well.

'''Possible Techniques:'''
	* Explicitely set aside a regular time to eliminate TechnicalDebt.  One example might be half a day, once a week.  If the time isn't enough (especially in the beginning), be more aggressive.
	* ''(From TechnicalDebt)'' Make the debt visible. Keep an explicit TechnicalDebtList?. Group deferred tasks into workable units, note the consequences of leaving each unit unattended. Keep the list visible. Make sure that Marketing knows that the list exists, and repeat the mantra "If we don't schedule time to pay off TechnicalDebt, you might not get all of the new features that you want." Allow time on the schedule for EntropyReduction, and keep the debt manageable. --DaveSmith

----

I'm proposing this as a ProtoPattern.  My main question: Is there a point of diminishing returns?  Do the costs of completely eliminating technical debt outweigh the advantages?  My guess is 'no,' but I've never been on a project where there was no TechnicalDebt.

There's also an interesting parallel in ExtremeProgramming, which uses EliminateDesignDebt.  Rather than schedule time for eliminating DesignDebt, XP says you should refactor '''all the time,''' as the opportunity presents itself.  ''(But I've found that DesignDebt still accumulates.  --JimLittle)''  Would the XP approach work for other forms of TechnicalDebt?

----

JohnBrewer of JeraDesign was the originator of the 'half-day, once a week' idea.  He used it as completely free time, and I introduced it (as free time, not technical debt time) with excellent results on two teams.  I found that many of the things done in "free time" resulted in important improvements to the project, usually within a few weeks.  Perhaps the time scheduled for eliminating technical debt could be "free time," or maybe kept and used for free time once the effort required to pay back the debt had decreased.  --JimLittle

I HaveThisPattern too, or at least had it for a while. We designated Friday afternoon's as "clean up" time. But we did't reenforce the practice, and it didn't stick. It did get a few people to be a bit better at cleaning up as they went. --DaveSmith

As an aside, I found that Thursday morning worked better than Thursday afternoon (the only two timeslots I tried), because otherwise "free time" got eaten into by "work time."  If the time was "after lunch," lunch sometimes got delayed until after 2pm!  I noticed the same phenomenon when I introduced the free time concept to my first team -- they didn't want to do it at all!  Programmers have an amazing work ethic.  Or maybe it's just TooDarnFun.  --JimLittle

----
TechnicalDebt is often distributed to different areas or departments. In the case of a Framework, the debt often lies with the client or system using it, because they code against it.
A simple change in the Framework could snowball its way through the client code. If the debt is sky high, your framework may never recover. EliminateDesignDebt applies to Frameworks well. --JonathanCrossland



----
CategoryProtoPattern | CategoryProcessPrinciple