Technical Debt
Technical debt is the future cost of rework that builds up when software teams choose quick or limited solutions now instead of approaches that would be easier to maintain and change later.
The term is a metaphor introduced by programmer Ward Cunningham. Like financial debt, technical debt carries interest. Each shortcut makes later changes slower, riskier, and more expensive until the debt is paid down through refactoring, upgrades, or replacement. Left alone for years, it is one of the main reasons systems become legacy systems.
Technical debt is not always a mistake. Teams sometimes take it on deliberately to meet a deadline or test an idea, with a plan to pay it back. Problems start when the debt is invisible or ignored. It's also a misconception that technical debt only means messy code. It can include outdated dependencies, missing tests, weak documentation, and architecture that no longer fits the business. Many teams track it openly, for example in a backlog, and set aside regular time to pay it down before it limits what they can build.
Examples
Code copied across several places instead of shared in one component.
Libraries or frameworks that are no longer supported by their maintainers.
Missing automated tests, which makes every change risky.
Hard-coded business rules that should be configurable.
Architecture designed for a much smaller system than the one in use today.