Skip to main content

Tech Debt Glossary

125+ technical debt terms defined in plain language. From foundational concepts to AI-era terminology, every term a developer or leader needs to know.

Jump to Letter
A B C D E F G H I J K L M N O P R S T U V Y Z

A

Abstract Leak
When an abstraction exposes implementation details it was designed to hide. Callers become dependent on internal behavior, making the underlying code nearly impossible to change without breaking consumers.
Accidental Complexity
Complexity introduced by poor tooling, bad design choices, or outdated patterns rather than by the problem itself. Contrast with Essential Complexity, which is inherent to the domain. Most tech debt is accidental complexity.
Accessibility Debt
Technical debt in user interfaces that fails to meet WCAG accessibility standards, including missing alt text, keyboard navigation gaps, color contrast failures, and screen reader incompatibility. Carries legal risk under ADA and similar laws. See UX & Design Debt.
Acquisition Debt
Technical debt inherited through mergers and acquisitions. Includes duplicate platforms, authentication integration challenges, data model conflicts, and cultural friction between engineering teams. See M&A Technical Debt.
Agentic Coding Debt
Debt created when AI coding agents operate with too much autonomy and too little oversight. The agent makes architectural decisions, introduces patterns, or adds dependencies that the team never reviewed or approved. See our Agentic Coding guide.
AI Slop
Low-quality AI-generated code or content accepted into a codebase without adequate review. Characterized by verbose boilerplate, hallucinated dependencies, and patterns that diverge from established conventions. See our AI Slop deep dive.
Alert Fatigue
A form of observability debt where monitoring systems generate so many alerts that teams stop paying attention. Critical alerts get lost in the noise, increasing incident response time. See Observability Debt.
Algorithmic Noise
AI-generated output that technically compiles but adds no real value. It mimics patterns from training data without understanding the specific context, distracting from genuine human insight and cluttering the codebase.
API Debt
Inconsistent endpoint naming, missing versioning, undocumented breaking changes, and mixed response formats. API debt compounds when multiple consumers depend on inconsistent contracts. See Types of Tech Debt.
Architectural Decision Record (ADR)
A short document capturing an architectural decision, its context, and consequences. ADRs prevent technical debt by making the rationale behind decisions explicit and reviewable. See Architectural Decision Records.
Architecture Debt
The most expensive category of tech debt. Wrong design patterns, tight coupling between modules, and structural decisions that constrain every feature built on top. See Types of Tech Debt and Architecture Patterns.
Automated Filler
AI-generated content or code created primarily to occupy space rather than serve a genuine purpose. In code, this manifests as excessive comments restating the obvious or boilerplate that adds no functionality.

B

Big Bang Rewrite
Replacing an entire system from scratch in one release. Notoriously risky - most fail because the old system keeps evolving during the rewrite, creating an ever-moving target. The Strangler Fig Pattern is the safer alternative.
Boilerplate Bloat
Verbose, generic AI-generated code that is technically correct but unnecessarily long. AI tools tend to produce complete implementations rather than concise solutions, inflating codebase size without adding proportional value.
Boy Scout Rule
"Leave the code a little better than you found it." A continuous improvement philosophy where developers make small cleanups in every file they touch, compounding into significant codebase health gains over time. See our Boy Scout Rule Playbook.
Branch by Abstraction
A technique for making large-scale changes incrementally by introducing an abstraction layer, building the new implementation behind it, then switching over. Avoids long-lived feature branches and big-bang merges.
Broken Windows Theory
Applied to software: once a codebase has visible neglect (poor formatting, dead code, failing tests), developers are less likely to maintain quality in that area. One "broken window" invites more. Keeping code clean prevents decay from spreading.
Bus Factor
The number of team members who would need to be hit by a bus (or win the lottery) before the project stalls. A bus factor of 1 means a single departure could cripple the team. Related to Tribal Knowledge debt.

C

Change Failure Rate
The percentage of deployments that cause a failure in production. One of the four DORA Metrics. High change failure rates often indicate testing debt, process debt, or both. Elite teams achieve under 5%.
CISQ
The Consortium for Information and Software Quality. Publishes annual reports on the cost of poor software quality, including technical debt. Their research estimates global tech debt costs exceed $2.41 trillion annually.
Clean Code
Code that is easy to read, easy to understand, and easy to change. Popularized by Robert C. Martin's book of the same name. Clean code minimizes accidental complexity and makes intent obvious to the next developer.
Cloud Cost Debt
Accumulated waste and inefficiency in cloud infrastructure spending, including over-provisioned resources, zombie instances, vendor lock-in, and missing FinOps practices. See Cloud Cost Debt.
Code Churn
The frequency at which code is rewritten or significantly modified shortly after being written. High churn in specific files often signals unclear requirements, poor design, or debt that forces repeated rework.
Code Coverage
The percentage of code executed by automated tests. While 100% coverage does not guarantee quality, very low coverage (under 40%) is a strong indicator of testing debt. Focus on critical path coverage over raw percentages.
Code Debt
The most visible type of tech debt. Duplicated logic, poor naming, overly long functions, inconsistent formatting, and dead code. Every developer has seen it. See Types of Tech Debt.
Code Smell
A surface-level indicator that something deeper might be wrong. Examples include long methods, large classes, duplicate code, and feature envy. Not a bug, but a signal that refactoring may be needed.
Compliance Debt
The gap between regulatory requirements and actual compliance posture. Includes audit readiness gaps, data privacy violations, access control issues, and outdated security policies. See Compliance & Regulatory Debt.
Compound Interest Effect
The phenomenon where tech debt grows exponentially if not addressed. Like financial compound interest, small amounts of neglected debt become massive over time because new code is built on top of flawed foundations. See our Compound Interest Effect guide.
Continuous Refactoring
The practice of making small improvements to code quality as part of everyday development work rather than in dedicated sprints. Prevents debt from accumulating in the first place. See Techniques.
Copilot Clutter
Unnecessary code generated by AI coding assistants like GitHub Copilot. Includes unneeded null checks, redundant type conversions, and helper functions that duplicate existing utilities. See Copilot Patterns.
Coupling
The degree to which components depend on each other. Tight coupling means changes in one component force changes in others. Loose coupling is a design goal that reduces the blast radius of changes and makes refactoring safer.
Cruft
Accumulated junk in a codebase: dead code, obsolete comments, unused configuration, leftover debugging statements, and files nobody remembers the purpose of. Cruft increases cognitive load without adding functionality.
CSS Architecture Debt
Accumulation of specificity hacks, !important overrides, dead CSS rules, and inconsistent naming patterns that make stylesheets unmaintainable and bloat page load times. See UX & Design Debt.
Cyclomatic Complexity
A quantitative measure of the number of independent execution paths through a function. Higher numbers mean more branches, more test cases needed, and harder-to-understand code. Functions with cyclomatic complexity above 10 are considered high risk. See Measuring Tech Debt.

D

Dark Debt
Tech debt that is hidden or unknown to the team. It lurks in rarely touched code, undocumented systems, or dependencies the team does not monitor. Dark debt is only discovered when something breaks, often at the worst possible time.
Dashboard Sprawl
A form of observability debt where organizations accumulate hundreds of monitoring dashboards with no ownership, review process, or clear purpose. Leads to conflicting data and wasted resources. See Observability Debt.
Data Governance Debt
Missing or inadequate data lineage tracking, quality checks, ownership definitions, and schema management across data sources. When data breaks, nobody knows what downstream systems are affected. See ML & Data Debt.
Dead Code
Code that exists in the codebase but is never executed. Dead code confuses developers, inflates bundle sizes, and makes refactoring harder because nobody is sure if removing it will break something. Tools like tree-shaking and linters can identify it.
Debt Ceiling
The point at which accumulated tech debt makes meaningful progress nearly impossible. Feature delivery slows to a crawl, incidents spike, and the team spends more time fighting the codebase than building on it. Reaching the debt ceiling often forces a major intervention like a rewrite or dedicated debt sprints.
Debt Sprint
A sprint (typically 1-2 weeks) dedicated primarily to reducing technical debt rather than building new features. Requires clear goals, measurable outcomes, and stakeholder alignment. See our Debt Sprints Playbook.
Deliberate Debt
Tech debt taken on knowingly and strategically. "We know this is not ideal, but shipping by Friday is worth more than a perfect architecture." Deliberate debt is the only kind that is truly analogous to financial borrowing, because there is a conscious decision and a plan to repay. See Fowler's Quadrant.
Dependency Debt
Outdated libraries, abandoned packages, pinned versions from years ago, and transitive dependencies with known CVEs. Dependency debt is a ticking time bomb that is fine until it is catastrophic. See Types of Tech Debt.
Deployment Frequency
How often code is deployed to production. One of the four DORA Metrics. Elite teams deploy on demand (multiple times per day), while low performers deploy less than once per month. Low deployment frequency often indicates process or infrastructure debt.
Derivative Generation
AI-generated code that closely mimics existing patterns from training data without adapting to the specific context. The output is technically functional but adds no original value and may introduce inconsistencies with the project's established conventions.
Design Debt
Poor abstractions, leaky interfaces, and wrong responsibilities. When classes or modules know too much about each other's internals, every change ripples outward. Design debt lives between architecture (macro) and code (micro). See Types of Tech Debt.
Design System Debt
When UI components drift from design specifications, one-off overrides accumulate, and there is no single source of truth between design tools and production code. See UX & Design Debt.
Developer Experience (DX) Debt
Friction in the internal developer platform: slow CI pipelines, manual deployment steps, poor error messages, missing documentation, and tools requiring tribal knowledge. See Platform Engineering Debt.
DevOps Debt
Gaps in the automation, tooling, and processes that connect development to operations. Missing CI/CD pipelines, manual deployment steps, no monitoring, and snowflake environments. DevOps debt slows every release and increases incident risk.
Documentation Debt
Missing READMEs, outdated API docs, no architecture decision records, and tribal knowledge trapped in one person's head. Invisible until someone leaves the team or a new hire spends three days on what should take 30 minutes. See AI Documentation Debt.
DORA Metrics
Four key measures of software delivery performance defined by the DevOps Research and Assessment team: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. High tech debt correlates with worse scores across all four. See Measuring Tech Debt.
DRY Principle
"Don't Repeat Yourself." Every piece of knowledge should have a single, unambiguous representation in the codebase. Violating DRY leads to code debt where the same logic exists in multiple places and must be updated in all of them when requirements change.

E

Encapsulation Debt
When internal implementation details are exposed to other modules or layers. Breaking encapsulation creates invisible dependencies that make changes risky and unpredictable. Related to Abstract Leak.
End of Life (EOL)
When a framework, library, language version, or operating system is no longer supported by its maintainers. Running EOL software means no security patches, no bug fixes, and growing incompatibility. EOL debt is a subset of dependency debt. See Security and Supply Chain.
Essential Complexity
Complexity that is inherent to the problem being solved, as opposed to Accidental Complexity introduced by poor design choices. Essential complexity cannot be eliminated - only managed through better abstractions and clearer domain models.
Entropy (Software)
The natural tendency of software to become more disordered over time as changes are made. Without deliberate effort to maintain structure, codebases degrade. The second law of thermodynamics, applied to code.

F

Feature Flag
A toggle that enables or disables a feature without deploying new code. Used for safe refactoring by running old and new code paths simultaneously, validating behavior, and rolling back instantly if needed. See our Feature Flags Playbook.
Feature Store Debt
Duplicate ML features computed differently across teams, training-serving skew, missing feature versioning, and stale features that are computed but never used. See ML & Data Debt.
FinOps
Financial Operations for cloud computing. The practice of bringing financial accountability to cloud spending through cost allocation, optimization reviews, and making teams accountable for their resource usage. See Cloud Cost Debt.
Fowler's Quadrant
Martin Fowler's 2x2 classification of tech debt along two axes: Deliberate vs Inadvertent, and Reckless vs Prudent. Produces four types: Reckless Deliberate, Prudent Deliberate, Reckless Inadvertent, and Prudent Inadvertent. See our Tech Debt Quadrant guide.
Fragile Code
AI-generated or poorly structured code that works in its original context but breaks easily when conditions change. It passes the initial tests but fails at edge cases, concurrent usage, or unexpected inputs.

G

God Class
A class that knows too much or does too much. It centralizes logic that should be distributed across multiple, focused classes. God classes are hard to test, hard to change, and violate the Single Responsibility Principle.
Golden Hammer
An anti-pattern where a familiar tool or pattern is applied to every problem, regardless of fit. "When all you have is a hammer, everything looks like a nail." Leads to design debt when the wrong solution is forced onto the wrong problem.
Golden Path
The recommended, supported way to build, test, and deploy software in an organization. Golden path decay occurs when the recommended approach falls behind actual practices. See Platform Engineering Debt.
Greenfield
A project built from scratch with no existing codebase or constraints. Greenfield projects start with zero tech debt, but the decisions made early determine how quickly debt accumulates. Contrast with Legacy Code.

H

Hallucinatory Output
AI-generated code that references APIs, libraries, or functions that do not exist. The AI confidently produces code that imports non-existent packages or calls methods with wrong signatures, creating runtime failures and confusion.
Hotfix
An emergency patch applied directly to production to fix a critical issue. Hotfixes bypass normal code review and testing processes, often creating new tech debt in the process. They are sometimes necessary but should always be followed by a proper fix.

I

Impedance Mismatch
A disconnect between two layers, systems, or paradigms that creates friction. The classic example is the object-relational impedance mismatch between OOP code and relational databases, which often leads to design debt in data access layers.
Inadvertent Debt
Tech debt created without awareness or intention. The team did not know a better approach existed, or requirements changed in ways that made the original design suboptimal. "We did not know what we did not know." See Fowler's Quadrant.
Infrastructure Debt
Manual deployments, snowflake servers, outdated operating systems, and "works on my machine" environments. Infrastructure debt makes every release risky and every environment unique. See Types of Tech Debt.
Integration Debt
Tight or brittle integrations between systems, services, or third-party APIs. Characterized by hardcoded URLs, missing error handling, no retry logic, and synchronous calls where async would be safer. Integration debt causes cascading failures.
Interest (Technical)
The ongoing cost of living with tech debt. Interest is paid in slower feature delivery, more bugs, harder onboarding, and developer frustration. The longer debt goes unaddressed, the more interest compounds. See Compound Interest Effect.

J

J-Curve Effect
The temporary productivity dip that occurs when a team begins paying down tech debt. Things get slightly worse before they get much better because refactoring takes time before it yields benefits. Expect the dip and plan for it.

K

KISS Principle
"Keep It Simple, Stupid." A design principle that favors simplicity over cleverness. Overly complex solutions create accidental complexity and make future maintenance harder. KISS is the antidote to over-engineering.

L

Lava Flow
Dead or legacy code that nobody dares remove because no one is sure what it does or what depends on it. Like cooled lava, it hardens in place and becomes part of the landscape. Often the result of missing documentation and tests.
Lead Time
The time from code commit to code running in production. One of the four DORA Metrics. Long lead times often indicate process debt, infrastructure debt, or excessive manual steps in the deployment pipeline.
Lean Debt
Waste in the development process that does not directly produce value: unnecessary meetings, redundant approval steps, manual processes that could be automated, and waiting time between handoffs. Lean debt slows delivery without adding quality.
Legacy Code
Code inherited from previous developers, teams, or eras that is difficult to change safely. Michael Feathers defines it as "code without tests." Legacy code is not necessarily bad code - it is code that has outlived the context in which it was written. See Migration Guides.
Lint
A static analysis tool (or the process of running one) that detects potential errors, style violations, and suspicious patterns in code without executing it. Linting catches many code smells early and prevents common forms of code debt from entering the codebase.

M

Magic Number
An unexplained numeric literal in code. Instead of if (retries > 3), use if (retries > MAX_RETRIES). Magic numbers make code harder to understand and change because the intent behind the value is lost.
Maintenance Burden
The ongoing effort required to keep a system running without adding new functionality. Industry data shows the average team spends 33% of developer time on maintenance. High tech debt can push this above 60%. See Executive's Guide.
Metrics Dashboard
A visual display of key engineering and debt metrics. Effective dashboards track DORA metrics, code coverage trends, dependency freshness, debt backlog size, and developer satisfaction scores. See Measuring Tech Debt.
Migration Debt
Debt accumulated from incomplete or stalled migration efforts. The classic scenario: a team starts migrating from Framework A to Framework B, gets 60% done, then stops. Now the codebase runs on both, doubling complexity. See Migration Guides.
Model Drift
When a machine learning model's accuracy degrades over time because the statistical properties of production data diverge from training data. Requires monitoring and periodic retraining. See ML & Data Debt.
Modular Monolith
An architecture pattern that maintains a single deployable unit while enforcing strict module boundaries internally. Offers the simplicity of a monolith with the maintainability of well-defined service boundaries. See Architecture Patterns.
Monolith
An application built as a single, tightly coupled unit. Monoliths are not inherently bad - they are simpler to develop and deploy than distributed systems. They become problematic when they grow so large that teams cannot make changes independently.
Mutation Testing
A technique that evaluates test quality by introducing small changes (mutations) to the code and checking whether tests catch them. Unlike code coverage, mutation testing reveals whether tests actually verify correct behavior rather than just executing code paths.

N

Nibble Debt
Very small instances of tech debt that individually seem trivial but collectively add up to a significant burden. Inconsistent naming, missing comments, slightly wrong indentation, and minor code smells. Death by a thousand paper cuts.

O

Observability Debt
The gap between what you need to know about your systems and what you can actually see. Includes alert fatigue, missing traces, metric naming chaos, and dashboard sprawl. See Observability Debt.
OOPSLA 1992
The ACM conference where Ward Cunningham presented his experience report introducing the technical debt metaphor. His paper, "The WyCash Portfolio Management System," described how shipping code you know is not right is like going into debt. See History of Tech Debt.
Over-Engineering
Building for requirements that do not exist yet. Adding abstraction layers, configuration options, and extensibility points "just in case." Over-engineering creates design debt because the extra complexity adds maintenance cost without delivering current value. Related to YAGNI.
Over-provisioning
Running cloud resources with significantly more capacity than needed. A common source of cloud cost debt born from fear of outages but sustained by inertia. See Cloud Cost Debt.

P

Platform Engineering Debt
Debt in internal developer platforms, tools, and abstractions that engineering teams rely on daily. Has a multiplier effect because every team inherits the platform's debt. See Platform Engineering Debt.
Premature Abstraction
Creating abstract interfaces, base classes, or generic solutions before understanding the problem domain well enough. The abstraction ends up not matching reality and becomes a constraint rather than a benefit. Wait for the pattern to emerge from at least three concrete examples.
Premature Optimization
"The root of all evil," according to Donald Knuth. Optimizing code for performance before knowing where the bottlenecks are. This creates harder-to-read code, accidental complexity, and maintenance burden for gains that often do not matter.
Principal (Technical)
The original amount of tech debt taken on, analogous to the principal on a loan. The shortcut or compromise that was the original trade-off. Over time, the interest on that principal can far exceed the original cost of doing it right. See What is Tech Debt?.
Process Debt
No code review process, no CI/CD pipeline, manual testing only, no branching strategy, and deployments that require a specific person. Process debt multiplies the cost of every other type of debt. See Types of Tech Debt.
Prompt Engineering Debt
Technical debt in LLM prompts: prompt rot from model version changes, sprawling unmanaged prompts, cost creep, hallucination-prone instructions, and security vulnerabilities. See Prompt Engineering Debt.
Prompt Rot
When prompts that worked reliably with one LLM version degrade or fail with newer versions. Prevented by version pinning and regression testing. See Prompt Engineering Debt.
Prudent Debt
Tech debt taken on thoughtfully with awareness of the consequences and a plan for repayment. "We know this will need refactoring, but shipping now and cleaning up next sprint is the right trade-off." The healthiest form of debt. See Fowler's Quadrant.

R

Reckless Debt
Tech debt taken on carelessly, without considering the consequences. "We do not have time for design" or "Just ship it, we will figure it out later." Reckless debt is the most damaging kind because there is usually no plan for repayment. See Fowler's Quadrant.
Refactoring
Improving the internal structure of code without changing its external behavior. The primary method for paying down tech debt. Good refactoring is incremental, tested, and targeted. See Techniques and Playbooks.
Regulatory Change Debt
New regulations or updates to existing ones that have been noted but not implemented. Each unaddressed change is a ticking compliance violation. See Compliance & Regulatory Debt.
Resume-Driven Development
Choosing technologies, patterns, or architectures based on what looks good on a resume rather than what is right for the project. Results in unnecessary complexity, over-engineering, and dependency on technologies the team does not fully understand.
Reverse Conway's Law
Intentionally structuring teams to match the desired system architecture. If you want independently deployable services, organize teams around those service boundaries. Architecture debt often reflects organizational structure mismatches.
Right-sizing
The practice of matching cloud resource allocations to actual utilization, reducing over-provisioning and cloud cost debt. See Cloud Cost Debt.
Rubber Ducking Debt
When code is so convoluted that developers need extensive rubber-duck debugging sessions (or pair programming) just to understand it. A sign that the code is overly complex and needs refactoring to make intent clear.

S

Schema Debt
Database schema problems: missing indexes, denormalization that went too far, columns with misleading names, no migration system, and tables with hundreds of columns. Schema debt is dangerous because refactoring production databases carries high risk.
Security Debt
Unpatched vulnerabilities, hardcoded credentials, weak authentication, and missing input validation. Unique among debt types because the cost of ignoring it is not slower features - it is a breach. See Types of Tech Debt and Security and Supply Chain.
Shotgun Surgery
A code smell where a single logical change requires modifications across many classes or files. Indicates poor separation of concerns and high coupling. Named because changes scatter like shotgun pellets across the codebase.
Single Responsibility Principle
The first of the SOLID Principles: a class or module should have one, and only one, reason to change. Violations lead to God Classes, tight coupling, and code that is hard to test. The most commonly violated SOLID principle.
SLO (Service Level Objective)
A target value for a service reliability metric. SLO design debt occurs when services lack meaningful objectives, making it impossible to balance feature velocity against reliability. See Observability Debt.
SOLID Principles
Five object-oriented design principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) that help prevent design debt. Following them produces code that is easier to maintain, test, and extend.
Spaghetti Code
Code with a tangled, unstructured control flow that is difficult to follow. Characterized by deeply nested conditionals, goto statements (or their modern equivalents), and logic that jumps unpredictably between functions or files.
Spike
A time-boxed investigation to answer a technical question or reduce uncertainty before committing to a full implementation. Spikes are throwaway by design - the code produced should not go to production, but the knowledge gained informs the real implementation.
Strangler Fig Pattern
An incremental migration strategy where new functionality is built around the old system, gradually replacing it piece by piece until the original can be decommissioned. Named after the strangler fig tree that grows around its host. See our Strangler Fig Playbook.
Synthetic Garbage
Low-quality AI-generated output that is straightforwardly bad: nonsensical variable names, logic errors, or code that does not solve the actual problem. Easier to spot than subtle AI debt but still wastes review time.

T

Technical Bankruptcy
When accumulated tech debt becomes so severe that the system must be abandoned and rewritten from scratch. The software equivalent of financial bankruptcy. Represents a failure of debt management, not a strategy. Prevention is always cheaper.
Technical Leverage
The positive side of the debt metaphor: strategic shortcuts that deliver outsized returns. Taking on deliberate, prudent debt to capture a market window is technical leverage when there is a clear repayment plan. The key is intentionality.
Test Debt
Missing tests, flaky tests, tests that only cover happy paths, and test suites so slow nobody runs them. Test debt creates a vicious cycle: without tests, developers fear changes; fearing changes, they skip refactoring; without refactoring, debt grows. See AI Testing Gaps.
Test Pyramid
A testing strategy model with many unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top. Inverting the pyramid (too many E2E tests, too few unit tests) leads to slow, flaky, expensive test suites.
Time to Recovery (MTTR)
How quickly a team can restore service after a production incident. One of the four DORA Metrics. High tech debt correlates with longer recovery times because understanding and fixing problems in messy code takes longer.
Toil
Manual, repetitive work that could be automated but has not been. Coined by Google's SRE team. Toil is a form of process debt that consumes engineering time without producing lasting value. Every hour spent on toil is an hour not spent on improvement.
Training-Serving Skew
When ML features are computed differently during training versus production inference, causing the model to receive different inputs than what it was trained on. See ML & Data Debt.
Tribal Knowledge
Critical information about a system that exists only in people's heads, not in documentation or code. When those people leave, the knowledge goes with them. Tribal knowledge is the most fragile form of documentation debt.
Twenty Percent Rule
The guideline that teams should allocate roughly 20% of their capacity to paying down tech debt. At less than 10%, debt grows faster than you can address it. At more than 30%, stakeholders lose patience because feature delivery slows too much.

U

Under-Engineering
Building the simplest possible solution without considering future needs or scalability. The opposite of over-engineering. While starting simple is wise, under-engineering becomes debt when shortcuts make the system unable to handle predictable growth or changes.
UX Debt
Technical debt in user-facing code and design systems, including visual inconsistency, accessibility failures, CSS architecture rot, responsive breakage, and frontend performance issues. See UX & Design Debt.

V

Version Pinning
Locking dependencies to specific versions rather than allowing automatic updates. Pinning provides stability but creates dependency debt if versions are never updated. The right approach is pinning plus regular, tested dependency updates.
Velocity Tax
The invisible slowdown caused by tech debt. Teams that could deliver a feature in 3 days on a clean codebase take 3 weeks on a debt-heavy one. The "tax" is the difference between what the team could deliver and what it actually delivers.
Vendor Lock-in
Dependence on proprietary cloud services that cannot be migrated without significant rewriting. The deeper the integration, the higher the switching cost and the stronger the lock-in debt. See Cloud Cost Debt.

Y

YAGNI
"You Aren't Gonna Need It." A principle from Extreme Programming that says you should not build functionality until it is actually needed. YAGNI fights over-engineering and premature abstraction. If you build it and nobody uses it, you created tech debt for nothing.

Z

Zero Bug Policy
A development practice where every bug is either fixed immediately, downgraded to a feature request, or closed as "won't fix." No bugs sit in the backlog growing stale. Prevents testing debt from accumulating through a growing pile of known issues.
Zombie Resources
Cloud resources that are running and incurring costs but serving no purpose: unused instances, detached volumes, idle load balancers, and forgotten test environments. See Cloud Cost Debt.

Frequently Asked Questions

Ward Cunningham introduced the technical debt metaphor in 1992 at the OOPSLA conference. He compared the trade-off of shipping imperfect code to borrowing money - you can move faster now, but you pay interest until you clean it up. His original intent was to explain the concept to non-technical stakeholders using a financial analogy they would understand.

Deliberate debt is taken on knowingly - the team makes a conscious trade-off to ship faster with a plan to refactor later. Accidental debt results from lack of knowledge or experience. You did not know a better approach existed, or requirements changed in ways that made your original design suboptimal. Martin Fowler's Tech Debt Quadrant maps these on two axes: Deliberate vs Inadvertent, and Reckless vs Prudent.

Most modern taxonomies identify 10 to 12 major categories: code debt, architecture debt, design debt, testing debt, documentation debt, infrastructure debt, dependency debt, database/schema debt, API debt, security debt, process debt, and AI-generated debt. Some frameworks combine or split categories differently, but these 12 cover the full spectrum of what engineering teams encounter.

DORA metrics are four key measures of software delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. They were developed by the DevOps Research and Assessment team. High tech debt typically correlates with worse scores across all four metrics - slower deployments, longer lead times, more failures, and longer recovery. Tracking DORA metrics is one of the best ways to quantify the impact of debt.

Refactoring improves the internal structure of code without changing its external behavior. It is done incrementally while the system stays running and serving users. A rewrite replaces the entire system with new code built from scratch. Rewrites are riskier, more expensive, and more likely to fail because the old system keeps evolving during the rewrite. Most experts recommend refactoring over rewriting whenever possible.

Yes. Terms like AI Slop, Copilot Clutter, Boilerplate Bloat, Hallucinatory Output, and Agentic Coding Debt emerged in 2024-2025 as teams began grappling with the consequences of accepting AI-generated code without adequate review. These terms describe genuinely new phenomena - debt that accumulates at machine speed from code no human authored - and they are rapidly becoming part of the standard engineering vocabulary.

Put These Terms to Work

Now that you speak the language, explore the concepts in depth. Understand the fundamentals, categorize your debt, or calculate what it is costing you.

What Is Tech Debt? Types of Tech Debt Calculate Your Debt