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)
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.
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.
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.
Deliberately "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.
IT systems of government agencies have long been plagued by technical debt, including outdated architectures, inadequately maintained codebases, and limited resources for security audits.
Performance debt is harder to repay than feature debt; rewriting a slow interface may require refactoring the entire call chain.
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.
为了短期速度而牺牲代码质量会在未来的维护、扩展和修复中付出更大代价，构成技术债务的权衡
2 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%UnverifiedSonarQube等工具已将技术债务量化为修复所需工时
90%Unverified嵌入式产品一旦出货，OTA升级能力有限，线上修复的窗口极为狭窄，技术债务的代价远高于互联网软件
85%Unverified硬编码模型名称在代码中会导致切换模型时需要全量代码扫描、回归测试和重新部署
85%Unverified在Vibe Coding模式下，技术债务以指数而非线性速度增长，因为开发者不读代码、AI不会主动重构
75%UnverifiedAI Agent时代的技术债出现新形态：用低代码或自然语言快速搭建的自动化流程往往缺乏清晰的错误处理、权限边界和可观测性设计
75%UnverifiedThe 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.
60%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%UnverifiedCommon 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.
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%UnverifiedAccumulated 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.
50%UnverifiedIT systems of government agencies have long been plagued by technical debt, including outdated architectures, inadequately maintained codebases, and limited resources for security audits.
50%UnverifiedPerformance debt is harder to repay than feature debt; rewriting a slow interface may require refactoring the entire call chain.
50%Unverified为了短期速度而牺牲代码质量会在未来的维护、扩展和修复中付出更大代价，构成技术债务的权衡
50%