Glossary
Technical debt
Technical debt is the future cost of shortcuts taken in software today: quick fixes, skipped tests or outdated code that make every later change slower, riskier and more expensive until someone cleans them up.
An example of technical debt
To hit a launch date, a developer copies the same pricing logic into three places instead of building it once. It works. Months later the prices change, someone updates two of the three copies, and customers see wrong totals. The shortcut saved a day; the “interest” is every bug and slow change that follows.
Warning signs of technical debt
- Small changes take weeks and often break something else.
- Only one developer understands how a key part works.
- Libraries and frameworks are years out of date and cannot be updated safely.
- Bugs come back after they were fixed.
Is technical debt always bad?
No. Like a business loan, some debt is a sensible choice, for example a quick MVP to test an idea. The real problem is debt nobody tracks. Keep a list of known shortcuts, set aside regular time to fix the worst ones, and pay them down before building big new features on top.
Frequently asked questions
How do I know if my software has technical debt?
Ask your developers which parts they are afraid to change, and notice how long simple requests take. An independent code review can also list the riskiest areas and what fixing them would involve.
Should I rewrite the software to get rid of technical debt?
Rarely as a first step. A full rewrite is costly and risky, and fixing the worst areas one at a time usually delivers value sooner. A rewrite or migration makes sense when the platform itself is no longer supported or cannot do what the business needs.