Technical debt, code debt or design debt is what happens when the Agile development team takes design shortcuts to speed up their product delivery.
These shortcuts might lead to a need to refactor the code in future. This refactoring project can be expensive, time consuming and frustrating for both the development team and their customers.
Technical debt can be compared to loaning money from a bank, if you borrow money from the bank it will keep accruing interest until you pay back that loan.
So, if you use substandard code to expediate your product’s time to market, your code will keep on accruing interest in the form of issues until you redesign that code to bring it up to standard.
Agile principles are based on product development built in a timely fashion but with optimal quality.
So, if you are trading quality for time, you would be bound to encounter problems in the future.
While you might gain time and push your product to the market before your competitors, what you might initially gain in market share, you would probably lose in customer loyalty when your customers realize that a competitors product is better and more reliable.
Why do Technical Debts happen?
While technical debt might be caused by poor development codes, but sometimes the development team have no option than to accrue technical debt due to project constraints such as budgeting constraints, regulatory concerns, knowledge limitations and time limitations.
Some people split technical debts into 2 types which are: intentional and unintentional technical debts.
Intentional technical debt is technical debt that can be used as a strategic tool.
For example, if the development team is working on an innovative product, they might have some knowledge gaps.
In this situation they might decide to deploy the product in a beta status to get the customers feedback and gradually improve on the product based on their responses.
While an unintentional technical debt is defined as the result of doing a bad job.
While other people state that technical debts can have as many as 13 different types and they are:
- Architecture Debt
- Build Debt
- Code Debt
- Defect Debt
- Design Debt
- Documentation Debt
- Infrastructure Debt
- People Debt
- Process Debt
- Requirement Debt
- Service Debt
- Test Automation Debt
- Test Debt
How bad is Technical Debt?
While technical debt is not ideal, sometimes it is unavoidable due to numerous factors.
So, while the Agile team might not want to use “bad code” to design a product, it might be their only option given numerous factors such as competitors pressure and customers demand.
So, they would rather deploy a suboptimal product than lose their market share.
But they can alleviate the cost of their technical debt by continuously rolling out product updates to fix the issues related to the “bad code”.