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.
Scrum by Example – Stop Digging New Holes
Technical Debt a Perspective for Managers
Scrum Anti-Patterns: The Hardening Sprint – Hint: they contribute to the problem
Resource Links:
- The Agile Alliance Debt Analysis Model
- Approaches to refactoring, technical debt and legacy code
- Code Red: the Business Impact of Code Quality
- Got Technical Debt?
- The Human Cost of Tech Debt
- In-Depth: What Scientific Research Has To Say About Technical Debt And Code Smells
- Introduction to the Technical Debt Concept – Agile Alliance – source of my Ward Cunningham quote above
- On Technical Debt And Code Smells
- A seamless way to keep track of technical debt in your source code
- Toward a Galvanizing Definition of Technical Debt
- Technical Debt
- Technical Debt Game for non technical people
- Technical Debt is Quantifiable as Financial Debt: an Impossible Thing for Developers
- Technical Debt Isn’t Technical: What Companies Can Do to Reduce Technical Debt
- Technical Debt, Rewrites, and Refactoring
- Technical vs Architectural Debt
- When Your Tech Debt Comes Due – From LinkedIn, literally their story
Books:
- 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
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*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.« Back to Glossary Index