If you are applying the Agile Scrum Framework at work, you must have heard the term, Technical Debt. So, what is the Technical Debt? Who invented this term? In this article, you will understand what it means and how to manage it.
The Definition
Ward Cunningham introduced the concept of technical debt in 1992. He defined it as follows:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
Cunningham used the ‘Technical Debt’ metaphor to emphasize the benefits and limitations of speedy development. The metaphor was well received by both business and technical people as it resonates with the financial debt. Like the financial debt, this debt accumulates interest with late repayment.
In 2004, Joshua Kerievsky describes ‘design debt’ in his article ‘Refactoring to Patterns” and the associated costs. Then again in 2014, Grady Booch compared evolving cities to evolving software and described how lack of refactoring can lead to the technical debt. He stated:
“The concept of the technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.”
Main Causes of the Technical Debt:
Review your product, system, code, practices, and processes for:
- Outdated design
- Low code coverage
- Lack of automated regression test suite
- Lack of continuous integration
- Lack of appropriate testing
- Tightly-coupled code
- Delayed code refactoring
- Aggressive timelines
How to manage the Technical Debt:
An organization should enforce good technical practices to all the developers, including but not limited to technical design review, code review, automated regression suite, high code coverage, adequate testing, and continuous integration. This will limit the accrual of this debt. The products that have accumulated the debt should focus on refactoring to reduce technical debt and improve maintainability. Below techniques will reduce your debt:
- Have a strong definition of done
- Create visibility for the tech debt
- Prioritize the tech debt
- Leverage an incremental approach
Learn more about the technical debt and other concepts of the Agile Scrum Framework with my book, The Basics of SCRUM: A Simple Handbook to the Most Popular Agile Scrum Framework
, available on Amazon.
More articles:
- Agile and Lean Methodologies - Same or Different?
- Expert Agile Tips and Techniques
- Scrum and Kanban: Same or Different? Which one is better?
- What are the 12 Agile Principles? Learn, Apply, and Be Agile!
- Sample Kanban Boards - Practical Examples
- What is a Sprint Burndown Chart? - Agile Scrum Framework
- Differences between Waterfall and Agile
- 5 Habits that Successful Leaders Have
- 7 Traits of High-Performing People
- 4 Habits that Impact Your Productivity
Recommended books:
