Technical Debt

Technical Debt is a deeply misunderstood term. It was originally coined at the beginning of Agile time by Ward Cunningham - from 1992:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid.

In the Cunningham definition, Technical Debt is okay when it is paid back promptly. Since his original definition, it has been misused to mean any mess left behind when team members rush through their code base, often because they feel pressure to get more work done faster.

For the non-technical people, the simplest way to imagine the problem is to pretend your developers are in a large gym. Time how long it takes for them to run across the gym and back. (Repeat enough times that the number is stable). Now move a few chairs into the middle of the gym, at random. Ask them to run across the gym again. They’re slower. Repeat. Eventually there are so many chairs they can no longer walk around them, instead they have to crawl to get across the room. The chairs are their technical debt and the additional time taken is the interest your team is paying for that debt.