Technical Debt
The implied cost of future rework caused by choosing an easy solution now instead of a better approach that would take longer.
Detailed Explanation
Technical debt is like financial debt—you take on "debt" by choosing a shortcut (skipping tests, hardcoding values, quick hacks) to deliver faster. Like financial debt, it accumulates "interest"—the longer it goes unaddressed, the more expensive it becomes to fix.
Technical debt can be deliberate (conscious trade-off for speed) or accidental (poor design, lack of knowledge). It manifests as: duplicated code, outdated dependencies, missing tests, poor documentation, architectural shortcuts, and quick hacks. Managing technical debt requires balancing feature delivery with code quality through regular refactoring.
Why It Matters
Unmanaged technical debt slows development, increases bugs, and eventually makes changes prohibitively expensive. Understanding and managing technical debt is essential for long-term product health.
Real-World Example
A startup hardcodes configuration values to launch faster. Two years later, every new deployment requires manual code changes. The "interest" on this technical debt is now hours of manual work per deployment.
When to Use
Recognize technical debt in every codebase. Track it, prioritize it, and address it regularly. Never let it accumulate unchecked.
Advantages
- Enables faster initial delivery
- Recognizing it helps prioritize improvements
- Can be managed through regular refactoring
- Documentation helps teams understand trade-offs
- Tracking tools make it visible
Disadvantages
- Slows development over time
- Increases bug frequency
- Makes onboarding new developers harder
- Can lead to system failures if unmanaged
- Refactoring is hard to prioritize against features
Related Terms
Frequently Asked Questions
Is technical debt always bad?
No. Deliberate technical debt can be a valid trade-off for speed. The problem is when it is untracked, unmanaged, or accumulates without being addressed. Acknowledge debt, track it, and pay it down regularly.
How do I track technical debt?
Add technical debt items to your backlog with estimates. Use labels or tags in your issue tracker. Include technical debt in sprint planning (allocate 20% of capacity). Make it visible to stakeholders.
How much technical debt is acceptable?
There is no universal answer. Balance feature delivery with code quality. A healthy codebase addresses debt regularly (20% of sprint capacity). If developers spend more time fighting debt than shipping features, debt is too high.
How do I reduce technical debt?
Allocate regular time for refactoring, enforce code review standards, write tests, keep dependencies updated, document architectural decisions, and refactor opportunistically (improve code as you touch it).
What is the difference between technical debt and poor code quality?
Technical debt is a deliberate or accidental trade-off (quick hack to meet deadline). Poor code quality is always bad (no tests, no structure, no documentation). Technical debt can be managed; poor quality is just bad practice.