First of all, this isn’t a lesson in anything to do with money. We can all read about countries going broke, and many of us are facing some challenges with our own budgets, but what I want to talk about here relates to an agile term: the so called ‘technical debt’. As you will see, there are lots of similarities between technical debt on an agile project and real-life debt.

Is debt bad? That’s an interesting question. Could you live your life without going into any form of debt – how would you get a house, a new car? But, what happens if you over extend yourself. Your own personal debt mountain increases, interest is charged on interest; we can all imaging a vicious spiral that leads to real problems.

Now, let’s turn to technical debt. First of all, what is technical debt? I would describe at as anything that you need to do on your project that requires some work to be performed but which does not directly make the application ‘better’ for a user. Of course, this mostly means fixing bugs, defects and the like, but I like to treat the re-factoring that we often need to do as part of my project’s technical debt.

Some people say that you shouldn’t have any technical debt – they say fixing technical debt is more important than adding new functionality, so as soon as you find something wrong you should fix it straight away. This is obviously an easy way to keeping technical debt under control, but is it the most efficient way? We could compare this with real life – it would be easy to have no debt problems if you set a rule never to borrow a penny but would you really want this (remember your house)? If you tried to fix every single, unimportant ‘bug’ before delivering new functionality (what I call ‘move this button 1 pixel to the right’ syndrome), you’d never get anywhere.

Other people ignore technical debt. They have really bad projects that run awry and never get back under control (like financial debts getting out of control). Not the way to go!

The reality with technical debt is that it can be treated the same as real-life debt. It’s natural to have some at some stages in your project. Just make sure you actively monitor and manage it and deal with it before it becomes a problem.

How do I spot technical debt that has run out of control? The most common way is when I see an iteration that is purely a ‘stabilisation’ or ‘bug-fixing’ release. That’s way bad for the users and is likely to break many of the promise that we would have made about going agile.

What would I suggest? Always make sure that you monitor your technical debt, and reserve some time in each iteration to keep it under control. This way, you can spend the vast majority of time moving forwards without running the risk of the project collapsing (Greece and the Euro, anyone?)