Technical Debt is an interesting phrase. We all have a sense of what it is instinctively, but we rarely want to think about it. If we think about it too hard, we feel somewhat oppressed by entropy. All systems tend to toward disorder and software systems are no different. The big question that we all face is what to do about it.
The traditional answer has been to 'refactor as you go' or just 'work better.' It's easy to see that a team can get completely side-tracked by setting aside large periods of time for refactoring. Worse, it's hard to articulate exactly what they will get for their efforts.
Over the past few years, I've come to the conclusion that we can do much better at recovery in large code bases but it can't be a sideline effort. Bearing this in mind, I've been working on a set of techniques for gauging the relative value of large refactorings and rewriting techniques and assessing their ROI. I've also been working on techniques for executing them in large codebases.
In January, I'll be offering a 2-day course in London called Reducing Technical Debt. It will be the first public run-through of this material.