Definition: Technical debt is the accumulated cost of suboptimal technical decisions made to accelerate short-term development. Like financial debt, it generates "interest": every future change requires more effort than necessary.
— Source: NERVICO, Software Development Consultancy
What is Technical Debt
The term "technical debt" was coined by Ward Cunningham in 1992. The metaphor compares technical decisions to financial ones: taking shortcuts today generates a "loan" that must be repaid later with interest.
It's important to distinguish: technical debt is not the same as bad code. Technical debt can be a deliberate and rational decision when circumstances justify it. The problem arises when it's not managed or you're not aware of it.
Types of Technical Debt
1. Deliberate Debt
Conscious decisions made to meet deadlines or validate hypotheses quickly. For example: launching an MVP without complete tests to validate the market before investing more.
2. Inadvertent Debt
Result of lack of knowledge or experience. The team didn't know they were making suboptimal decisions. Discovered when the system grows and problems emerge.
3. Bit Rot (Degradation)
Debt that accumulates from lack of maintenance. Outdated dependencies, code that no longer follows current best practices, obsolete documentation.
How It Accumulates
- Deadline pressure: Delivering fast at the cost of quality.
- Lack of knowledge: Decisions made without sufficient experience.
- Changing requirements: Code designed for X now has to do Y.
- Unplanned growth: What worked with 100 users doesn't scale to 10,000.
- Team turnover: Loss of context and implicit knowledge.
How to Identify It
Qualitative Indicators
- "I'm scared to touch that code"
- "Nobody knows exactly how that part works"
- "Every small change breaks something unexpected"
- "New developers take months to become productive"
Technical Metrics
- Average time to implement changes (increases with debt)
- Frequency of bugs in production
- Test coverage and quality
- Code cyclomatic complexity
- Onboarding time for new developers
Consequences of Ignoring It
- Decreasing velocity: Each new feature takes longer to develop.
- More bugs: Fragile code creates production problems.
- Difficulty hiring: Good developers flee from bad code.
- Opportunity cost: Time fixing problems is time not innovating.
- Security risk: Outdated dependencies may have vulnerabilities.
Strategies for Managing It
1. The 20% Technical Time
Reserve approximately 20% of development time to reduce technical debt. It's not a luxury, it's necessary maintenance.
2. Incremental Refactoring
Improve code gradually as part of normal work. "Leave the code better than you found it" (Boy Scout Rule).
3. Document the Debt
Maintain an explicit record of known debt, its estimated impact and the cost of resolving it. Enables informed decisions about prioritisation.
4. Pay Before Scaling
Before investing in growth (more users, more features), ensure the technical foundation can support it. Scaling on debt multiplies problems.
When Technical Debt is Acceptable
Technical debt is not inherently bad. It's acceptable when:
- You need to validate a business hypothesis quickly (MVP)
- It's a conscious decision with a defined payment plan
- The cost of doing it "right" exceeds the expected benefit
- The code has a known expiry date (prototype, migration)
The key: be aware of the debt, document it, and have a plan.