Technical Debt
A metaphor introduced by Ward Cunningham in 1992 describing the technical compromises development teams make to accelerate short-term delivery, which accumulate into additional maintenance and modification costs over time.
Core Facts
The concept of technical debt was proposed by Ward Cunningham in 1992, referring to the long-term maintenance costs that accumulate when suboptimal solutions are chosen for the sake of short-term delivery speed.
The concept of Technical Debt was first proposed by Ward Cunningham in 1992.
技术债务（Technical Debt）概念由Ward Cunningham在1992年提出，用于描述为了短期交付而采用的次优方案所积累的隐性成本
Timeline (last 90 days)
This pattern does not provide unlimited backward compatibility; one needs to decide the time window for accepting old versions and when to remove the adaptation logic, which is technical debt that must be actively managed.
An organization's technical debt exists not only in the code, but also at the repository and permission levels.
Common means of measuring technical debt include code complexity metrics (such as cyclomatic complexity), duplicate code rate, the degree of version lag in dependency libraries, test coverage, and the more business-oriented delivery lead time and change failure rate.
The industry usually divides technical debt into four categories: deliberate and prudent, deliberate and reckless, inadvertent and prudent, and inadvertent and reckless.
Unreviewed solutions become the norm, the subtle bugs and vulnerabilities introduced spread in production environments, AI-generated security protocols may hide flaws, technical debt accumulates, and the quality feedback loop breaks.
Lines of code (LOC) itself is not a reliable proxy metric for technical debt, and a concise implementation may also hide deep coupling.
"Cognitive debt" is an approximate term in software engineering research for the phenomenon of "code growing faster than understanding," distinguished from technical debt: technical debt concerns code quality and maintenance costs, while cognitive debt concerns whether the team's mental model of the system is complete.
Accumulated technical debt can push a system toward what engineers call a "Big Ball of Mud" state—a system with no clear architecture where touching one part affects everything else.
Cunningham used financial borrowing as an analogy for technical debt: choosing an imperfect short-term solution means you must later repay the principal (refactoring the code) and pay interest (additional maintenance costs).
Common forms of technical debt include lack of test coverage, overly complex module coupling, outdated third-party dependencies, and "magic code" that only the original author can understand.
7 more timeline events
All Facts (20)
The concept of technical debt was proposed by Ward Cunningham in 1992, referring to the long-term maintenance costs that accumulate when suboptimal solutions are chosen for the sake of short-term delivery speed.
85%VerifiedThe concept of Technical Debt was first proposed by Ward Cunningham in 1992.
80%Verified技术债务（Technical Debt）概念由Ward Cunningham在1992年提出，用于描述为了短期交付而采用的次优方案所积累的隐性成本
80%VerifiedTechnical debt refers to the compromises made in code quality and architectural design in pursuit of short-term delivery speed, which will be repaid in the future at a higher cost of maintenance and refactoring.
75%VerifiedWhen the cost of producing code approaches zero, AI-generated code that 'looks plausible but contains subtle defects' is often harder to detect than obvious errors in human-written code.
65%VerifiedThe metaphor of 'technical debt' was proposed by Ward Cunningham, comparing the practice of sacrificing code quality for short-term delivery speed to taking out a loan.
65%UnverifiedSonarQube等工具已将技术债务量化为修复所需工时
90%Unverified嵌入式产品一旦出货，OTA升级能力有限，线上修复的窗口极为狭窄，技术债务的代价远高于互联网软件
85%Unverified硬编码模型名称在代码中会导致切换模型时需要全量代码扫描、回归测试和重新部署
85%Unverified在Vibe Coding模式下，技术债务以指数而非线性速度增长，因为开发者不读代码、AI不会主动重构
75%UnverifiedAI Agent时代的技术债出现新形态：用低代码或自然语言快速搭建的自动化流程往往缺乏清晰的错误处理、权限边界和可观测性设计
75%UnverifiedThis pattern does not provide unlimited backward compatibility; one needs to decide the time window for accepting old versions and when to remove the adaptation logic, which is technical debt that must be actively managed.
50%UnverifiedAn organization's technical debt exists not only in the code, but also at the repository and permission levels.
50%UnverifiedCommon means of measuring technical debt include code complexity metrics (such as cyclomatic complexity), duplicate code rate, the degree of version lag in dependency libraries, test coverage, and the more business-oriented delivery lead time and change failure rate.
50%UnverifiedThe industry usually divides technical debt into four categories: deliberate and prudent, deliberate and reckless, inadvertent and prudent, and inadvertent and reckless.
50%UnverifiedUnreviewed solutions become the norm, the subtle bugs and vulnerabilities introduced spread in production environments, AI-generated security protocols may hide flaws, technical debt accumulates, and the quality feedback loop breaks.
50%UnverifiedLines of code (LOC) itself is not a reliable proxy metric for technical debt, and a concise implementation may also hide deep coupling.
50%Unverified"Cognitive debt" is an approximate term in software engineering research for the phenomenon of "code growing faster than understanding," distinguished from technical debt: technical debt concerns code quality and maintenance costs, while cognitive debt concerns whether the team's mental model of the system is complete.
50%UnverifiedDeliberately "borrowing" technical debt during early-stage product development to rapidly validate the market is a reasonable trade-off; the problem lies in unconscious accumulation or long-term failure to repay the debt.
50%UnverifiedCunningham used financial borrowing as an analogy for technical debt: choosing an imperfect short-term solution means you must later repay the principal (refactoring the code) and pay interest (additional maintenance costs).
50%