What Is Technical Debt?

Tuesday, 09 July 2013 17:12

This is a wonderful term made popular by Martin Fowler and others. In essence, technical debt is the effort you would need to undertake to clean up your software (by refactoring, for example) to make it cleaner, but for various reasons have never got round to doing. It's kind of a measure of laziness and procrastination in your software, and conscientious developers feel endlessly guilty about it. And like real (financial) debt, it increases over time!

That means, the pain of eliminating technical debt and still delivering a functioning system will only get worse if nothing is done about it, until the product is either scrapped or reimplemented altogether (that is, if the pain levels are high enough but the market is still willing to justify a replacement).

Technical debt isn't something we can ever eliminate entirely, and it has to be said that sometimes a quick and dirty software solution can be justifiable, if it's the only way for a business to ship something - and therefore generate revenue - which a perfectly-crafted solution may never do. Remember that a product that never ships is no use to anyone. But technical debt is definitely something we should strive to keep to a minimum and to reduce whenever possible.

So what can we do to reduce technical debt? Essentially, use best agile practices where they suit your organisation, but especially:

  • Test-Driven Development
  • Continuous Integration
  • Refactoring

I have written about TDD before, and I would never attempt a new project without this approach from the outset. I also firmly believe that it's essential to be able to deliver a product at any time at the touch of a button, which means that CI (Continuous Integration) is an absolute must-have. With the availability of cheap hardware and open source CI systems such as Hudson and Jenkins, it's unforgivable to omit this.

Refactoring, or the practice of restructuring or rewriting code without changing its (external) behaviour, can be triggered by developers themselves identifying problems, by QA and others finding that certain areas of code are producing the most bugs, or in some cases by using code metrics to identify dodgy practices in certain parts of the code.

If you're going to go the code metrics route, you need to make sure that your CI system runs code metrics regularly (e.g. nightly) and produces reports which are sent to developers in a human-readable format so that they will be forced to take notice, at least occasionally. It's no use producing the best metrics in the world if noone ever bothers to look at them.

Sending automated emails after a weekly code metrics run will always get developers' notice, especially if other stakeholders get copies as well. These reports are particularly useful if they include charts of how metrics are changing on a weekly or monthly basis, so people will see how code quality is changing. Hopefully for the better!