Technical Debt

The term Technical Debt was coined by Ward Cunningham of XP fame. Technical debt is a burden and I am sure many will have experienced the following (which is not comprehensive):

• ‘We’ll do it in the next release’ – that never comes.
• The project got delivered – along with a maintenance team.
• We did it for good business reasons.
• “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
• “To get anything released to production is a nightmare - we have to regression test the whole system”.

The third argument is especially common when you are a young company and you have very little to lose by getting stuff into production - so you just go for it. But when you have thousands of customers the stakes are then much higher. It is no surprise that you hit a brick wall and end up in release hell.

An excellent article on Technical Debt by Kane Mar :

And another excellent article by Steve McConnell:

…

One approach to reducing technical debt is to have a technical debt sprint at the end of several business focused sprints. The argument that is put forward to the product owner who has responsibility for prioritizing each release is that reducing technical debt will increase your velocity on subsequent sprints more than the cost of refactoring during a TD Sprint.