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.
- Got Technical Debt?
- Introduction to the Technical Debt Concept – Agile Alliance – source of my Ward Cunningham quote above
- The Agile Alliance Debt Analysis Model
- The Human Cost of Tech Debt
- Toward a Galvanizing Definition of Technical Debt
- Technical Debt
- Technical Debt Game for non technical people
- A seamless way to keep track of technical debt in your source code
- Technical Debt, Rewrites, and Refactoring
- When Your Tech Debt Comes Due – From LinkedIn, literally their story
- Approaches to refactoring, technical debt and legacy code
- Working Effectively with Legacy Code – Michael Feathers
- Managing Software Debt: Building for Inevitable Change – Chris Sterling
- Beyond Legacy Code: Nine Practices to Extend the Life – David Bernstein
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.