25 Jan 2008

Technical Debt is the acid that rots your software - so keep an eye on it.

One of the fundamental principals in Agile processes such as Extreme Programming is that with the right combination of technology and practices software's "cost of change" can be held constant. This is what allows us to practice iterative development.

Many organisations starting out with Agile approaches tend to forget this.

After a great starting run, the combination of duplication and complexity restrict progress to the point that making any changes at all becomes slow and painful. They are now carrying too much Technical Debt.

Technical Debt refers to those deferred actions and decisions that compromise the design of the system. The more technical debt, the harder it will be to make changes to the system in the future.

While technical debt itself is not necessary a bad thing, it is easy to let things spiral out of control. Once out of control, nobody likes facing up to the hard decisions that need to me made.

If you don't track your technical tebt you have no visibility of the current short comings in your system. Without that visibility it is hard to notice those short comings climbing up. Making technical debt and its ongoing costs visible helps all stakeholders understand the need to keep it under control.

It is really easy to track Technical Debt (a list works just fine). Keep it under control and you keep your software easy to change.