Technical debt is a metaphor that refers to the consequences of allowing low quality software coding to go unchanged. It’s one type of debt that Nama won’t be managing!

Ward Cunningham, one of the pioneers of extreme programming, coined the phrase to convey the potential risks of taking short-cuts when developing and testing code for an application. Ward’s first law states that lowering code quality lengthens development time.

Similar to financial debt, there can be good or bad technical debt;

• Good debt – in order to make a release date for an application, some features may have been rushed, but this debt have ‘low interest’ in that the impact of this rushed work is minimal to the user and/or involves features that are not regularly used. Importantly, there is a commitment to resolve it soon to prevent any ongoing regression bugs
• Bad debt – where previous low quality code has not been fixed, maintenance efforts are increased and overall development productivity is decreasing

Committing to reducing the ‘interest’

Continuing the financial theme and emphasising the importance of commiting to rectify any problem code sooner rather than later. It is understandable in the daily life of developing and releasing a software application that short-cuts may be taken and ‘interest’ will be paid dealing with the consequences, but no business wants to be paying interest forever, particularly if that ‘interest’ is at a high level.

This ‘interest’ can manifest itself in different forms, including increased maintenance work, increased number of user support calls and the additional time to resolve them.

Whatever the form, the negative impact of technical debt on your development team decreases their throughput. This can have a self perpetuating effect in that if features in follow-on releases are not being delivered on time, then pressure can be increased by management to up the tempo. However if the original low quality code is still present with no time being devoted to rectify it, due to the backlog of features, then the application quality will continue be in a downward spiral.

Good development practices are cost effective

David Laribee in MSDN makes a good case for prioritising resolving technical debt by using the cost of change curve. This curve shows that at an early stage of a project, the use of good design and development standards may cost more, this levels off over time and is considerably less than the ever increasing cost when bad coding is left unresolved.

To get out of this spiral, strong executive sponsorship is needed to say – enough with cutting corners and I think the development team will be fully behind this. Using scrum principles, the feature backlog can be groomed with the intention to;

• Identify and size the ‘debt’ (bugs, bad coding etc) and related ‘interest’ (additional effort, consequences etc) to build a business case
• Re-prioritise the backlog using the various business cases relative to the other features on the backlog
• Demonstrate the commitment to remove the technical debt by planning the ‘debt’ removal changes into the next and subsequent sprints
• Incorporate any lessons learned into the retrospectives of subsequent sprints

To leave you with a summary of what technical debt is – I think Martin Fowler put it eloquently when he said that “Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it’s very handy for communicating to non-technical people.

Good luck with the code clean-ups – they are a win-win proposition for developer and customer.