Technical Debt
Technical debt is the implied cost of taking shortcuts in software development that prioritize speed over quality, ultimately making future changes more difficult and expensive. Like financial debt, it accrues interest.
§ 1 Definition
Technical debt (or tech debt) is a metaphor coined by Ward Cunningham in 1992. It describes the long-term cost of choosing an easy, fast solution now instead of a more robust approach that would take longer. The "debt" is the future rework required to fix the shortcuts. The "interest" is the extra effort required to add features or fix bugs in the debt-laden codebase. Technical debt is not inherently bad; strategic debt (taking a shortcut deliberately to hit a deadline) can be a valid business decision. The danger is unconscious or reckless debt that accumulates without tracking, eventually grinding development velocity to a halt. Martin Fowler's technical debt quadrant classifies debt as prudent vs reckless and deliberate vs inadvertent.
§ 2 Types of Technical Debt
Martin Fowler's quadrant model classifies technical debt along two axes: * Prudent and Deliberate: You knowingly take a shortcut because you understand the tradeoff. "We ship this now and refactor next sprint." * Prudent and Inadvertent: You write the best code you can with current knowledge, but later learn a better approach. This is natural and unavoidable. * Reckless and Deliberate: You cut corners knowing it is wrong, without a plan to fix it. "We will never need to maintain this." This is the dangerous kind. * Reckless and Inadvertent: Poor code written without awareness of best practices. This stems from inexperience or lack of code review.
§ 3 Interest and Consequences
The "interest" on technical debt manifests in many ways: bugs that take longer to fix, features that take longer to add, onboarding friction for new developers, increased cognitive load from working around cruft, and cascading failures from fragile code. Over time, unmanaged debt can bring development to a crawl. Teams spend more time working around existing problems than building new value. The cost compounds because debt-laden code is harder to refactor, making each fix more expensive than the last. Measuring technical debt is difficult; proxies include cyclomatic complexity, test coverage, bug rates, and developer sentiment.
§ 4 Managing and Reducing Debt
Managing debt starts with acknowledging it. Track it visibly (a debt backlog or section in the product backlog). Allocate regular capacity to debt reduction, typically 10-20% of each sprint. Use the "boy scout rule": always leave the code cleaner than you found it. Refactor incrementally instead of planning big rewrites. Automated tests create a safety net for refactoring. Code reviews catch reckless debt before it merges. Most importantly: distinguish between strategic debt (a conscious tradeoff) and technical crud (just bad code with no offsetting benefit).
§ 5 Common questions
- Q. Is technical debt always bad?
- A. No. Deliberate, prudent debt (shipping fast with a plan to refactor) can be a sound business decision. The problem is reckless or invisible debt.
- Q. How do you measure technical debt?
- A. There is no perfect metric. Proxies include: time to add a new feature, bug fix velocity, test coverage, cyclomatic complexity, and the team's subjective assessment.
- Q. Should we rewrite the codebase to eliminate technical debt?
- A. Rarely. Rewrites are risky and expensive. Incremental refactoring, while slower, is safer and more sustainable. The "big rewrite" often introduces new debt and delays value delivery.
- Technical debt is the future cost of current shortcuts in software development.
- Not all debt is bad; strategic, deliberate debt can be a valid tradeoff.
- Unmanaged debt compounds, slowing development velocity over time.
- Manage debt by tracking it visibly, allocating regular maintenance time, and refactoring incrementally.
We manage technical debt deliberately as part of our process. Every sprint includes time for refactoring, so your codebase stays healthy and velocity stays high. Get in touch to discuss your project.
Get in touchTechnical debt is the implied cost of taking shortcuts in software development that prioritize speed over quality, ultimately making future changes more difficult and expensive. Like financial debt, it accrues interest.
Category: General (also: Software Engineering)
Author: Atomic Glue Technical Team
## Definition
Technical debt (or tech debt) is a metaphor coined by Ward Cunningham in 1992. It describes the long-term cost of choosing an easy, fast solution now instead of a more robust approach that would take longer. The "debt" is the future rework required to fix the shortcuts. The "interest" is the extra effort required to add features or fix bugs in the debt-laden codebase. Technical debt is not inherently bad; strategic debt (taking a shortcut deliberately to hit a deadline) can be a valid business decision. The danger is unconscious or reckless debt that accumulates without tracking, eventually grinding development velocity to a halt. Martin Fowler's technical debt quadrant classifies debt as prudent vs reckless and deliberate vs inadvertent.
## Types of Technical Debt
Martin Fowler's quadrant model classifies technical debt along two axes: * **Prudent and Deliberate:** You knowingly take a shortcut because you understand the tradeoff. "We ship this now and refactor next sprint." * **Prudent and Inadvertent:** You write the best code you can with current knowledge, but later learn a better approach. This is natural and unavoidable. * **Reckless and Deliberate:** You cut corners knowing it is wrong, without a plan to fix it. "We will never need to maintain this." This is the dangerous kind. * **Reckless and Inadvertent:** Poor code written without awareness of best practices. This stems from inexperience or lack of code review.
## Interest and Consequences
The "interest" on technical debt manifests in many ways: bugs that take longer to fix, features that take longer to add, onboarding friction for new developers, increased cognitive load from working around cruft, and cascading failures from fragile code. Over time, unmanaged debt can bring development to a crawl. Teams spend more time working around existing problems than building new value. The cost compounds because debt-laden code is harder to refactor, making each fix more expensive than the last. Measuring technical debt is difficult; proxies include cyclomatic complexity, test coverage, bug rates, and developer sentiment.
## Managing and Reducing Debt
Managing debt starts with acknowledging it. Track it visibly (a debt backlog or section in the product backlog). Allocate regular capacity to debt reduction, typically 10-20% of each sprint. Use the "boy scout rule": always leave the code cleaner than you found it. Refactor incrementally instead of planning big rewrites. Automated tests create a safety net for refactoring. Code reviews catch reckless debt before it merges. Most importantly: distinguish between strategic debt (a conscious tradeoff) and technical crud (just bad code with no offsetting benefit).
## Common questions
Q: Is technical debt always bad?
A: No. Deliberate, prudent debt (shipping fast with a plan to refactor) can be a sound business decision. The problem is reckless or invisible debt.
Q: How do you measure technical debt?
A: There is no perfect metric. Proxies include: time to add a new feature, bug fix velocity, test coverage, cyclomatic complexity, and the team's subjective assessment.
Q: Should we rewrite the codebase to eliminate technical debt?
A: Rarely. Rewrites are risky and expensive. Incremental refactoring, while slower, is safer and more sustainable. The "big rewrite" often introduces new debt and delays value delivery.
## Key takeaways
- Technical debt is the future cost of current shortcuts in software development.
- Not all debt is bad; strategic, deliberate debt can be a valid tradeoff.
- Unmanaged debt compounds, slowing development velocity over time.
- Manage debt by tracking it visibly, allocating regular maintenance time, and refactoring incrementally.
## Related entries
- [Agile Development](atomicglue.co/glossary/agile-development)
- [Quality Assurance (QA)](atomicglue.co/glossary/quality-assurance)
- [Scrum](atomicglue.co/glossary/scrum)
Last updated July 2025. Permalink: atomicglue.co/glossary/technical-debt