Technical debt is the amount of work that is needed to maintain evolving software to ensure its structure and code is efficient, scalable and extensible.

Imagine a house that evolves and is lived in, after a while parts of the house will need to be upgraded or repaired so it can carry on being lived in, being improved or extended. It is the same for evolving software. For instance a piece of hardcoded data or an old database is still in use and these parts have to be fixed so the rest of the software can work properly but also so other parts of the software can be improved and changed easily without relying on old parts.

The debt is there and has to be repaid somehow but it depends on the status of the software.

If the software is young the ideal is to repay technical debt on a regular basis, either by adding a story or two in each iteration or by doing a whole sprint of technical debt once in a while.

If the software is older and has a hefty technical debt, it is recommended to tackle most of the debt upfront so further development can be done with less hassle, time and hacks. If this is not possible in time or budget constraints then refer to the first option, however it will take longer and in the meantime other development tasks might take longer.

If one just leaves technical debt it will have to be paid somehow and generally it comes in the form of more tricky and lengthy development and more testing when building new features. The debt is repaid slowly with huge interest because the actual issues are not fixed but each piece of development will take longer until the issues are sorted.

Don’t ignore technical debt, get it regularly assessed, and tackle it regularly or in batches.

Tackling technical debt is an on-going investment, make your clients understand it (use the house or car analogy) and agree to regular debt payments. Your clients will be better off in the long run and you might even find that it will improve performance of your software and save your client money in hosting or hardware.