Debt is something that has always been associated with the financial world. However, it has also made its presence felt in the information technology realm.
The easiest way to understand technical debt is to view it from the financial paradigm. Let’s start with ‘What is Financial Debt?”
Definition: An amount owed to a person or organization for funds borrowed.
Debt Components: Principal + Interest
Debt Recovery: EMI (Part Principal + Part Interest)
What are the different Types of Debt?
Prudent Debt: If the Principal + Interest is lower than the yield of Investment, then it would be called a prudent debt. For e.g. Housing Loan, Education Loan.
Reckless Debt: It is exactly the opposite of a Prudent Debt. For e.g. debt accrued on credit card bills.
Keeping the above principles in mind, Technical Debt for an IT project can be defined in the exactly same style.
Definition: When CODE is looked at as a Financial Burden, then the code lacking good quality & design and having zero test coverage gets classified as Technical Debt. This is a type of debt that incurs INTEREST for the future.
Debt Components: Principal + Interest
Principal: The cost of refactoring the code-base to a Good Quality & Design.
Interest: The extra cost to be paid for specialist teams to work with the existing code base.
The general symptoms of your code carrying technical debt are
1. Reduced SCRUM velocity.
2. General Chatter like “Only X can fix it”
3. “CTRL +C” “CTRL + V” of code everywhere.
The reasons for carrying technical debt could be as varied as using old libraries which are no longer supported (legacy code) to sacrificing quality to be “First on the Market” . The latter is actually the right thing to do in some cases.
Just like Financial Debt, Technical Debt too can be classified as Prudent & Reckless.
Prudent Debt: Taking on this Debt is a conscious decision to adopt a design strategy that isn’t sustainable in the long term , but will yield short term benefits. This type of debt will yield value sooner, but it needs to be paid off as soon as possible.
Reckless Debt: Messy Code is Reckless Debt. Reckless debt results in crippling interest payments or long period of paying off principal.
Debt as a noun carries a very negative inference, but carrying technical debt need not always have a negative undertone. In fact, in today’s agile world it is part of the business strategy to carry some amount of technical debt in order to launch a product/service early in the market and capture a major chunk of the market. This strategy is very successful as long as there is conscious decision made to carry a prudent debt and an even more deliberate decision to repay the debt in the subsequent sprint cycles. However, there are cases where these decision are made inadvertently, plainly said, bad design & code. This kind of reckless and inadvertent technical debt will always lead to the failure or chronic pain to the business. The quadrants in the matrix below lists out the impact of deliberate/inadvertent approach to a prudent/reckless technical debt.
How to repay a Technical Debt?
Interestingly, unlike financial debt, technical debt need not be repaid in full. This difference between financial debt and technical debt is due to the fact that technical debt is used more as a metaphor than a metric. The table below lists out a few more differences.
Strategies for Repayment
The following three strategies of technical debt repayment should be based Cost, Risk & Urgency of the business need.
Debt Repayment: Refactor or replace the code/framework/platform that is considered to be a technical debt.
Debt Conversion: Replace the current solution with a “Good, but not Perfect” solution. This is a good option, if the perfect solution is prohibitively expensive to build. The new solution will have a lower interest rate.
Just Pay the Interest: Live with the code because refactoring is more expensive than working with the not-so-quite-right code.
The following practices can help reduce your technical debt during the construction phase of your software.
1. Create Technical Backlog, maintain a list of things to be done.
2. Include cost for technical debt in requirement estimation.
3. Create one buffer task per release for debt repayment.
4. Have one Clean-up Release from time-to-time which are just Technical releases.
In closing, an organisation will accumulate technical debt over time because of the nature of the IT systems as we know it today. However, by simply being aware of the nature of the technical debt your organisation carries and having an enterprise strategy to mitigate the same goes a long way in ensuring that the organisation has a sustainable model to deliver its promised services to its customers.
Sources: InfoQ – Managing Technical Debt
Martin Fowler – Technical Debt Quadrant