Technical debt
TEK-nih-kul det
The accumulated cost of shortcuts and deferred work in a codebase that slows future development.
Technical debt is what happens when you take shortcuts in code to ship faster now, knowing you will pay for it later. Just like financial debt, it accumulates interest. The longer you leave it, the more expensive it gets to fix.
Some technical debt is intentional. A startup might hardcode a value instead of building a configuration system because they need to ship this week. That is a reasonable trade-off if they pay it down soon. Other technical debt is accidental: a developer did not know a better approach existed, or requirements changed and the original design no longer fits.
The real danger is when teams stop tracking their debt. It compounds silently. New features take longer to build. Bugs appear in unexpected places. Onboarding slows because the codebase is harder to understand. Google estimates that developers spend 30-40% of their time dealing with technical debt. That is real money. Regular refactoring and thorough code reviews are the primary defenses.
Examples
A startup rushes to launch before a competitor.
The team skips writing tests, hardcodes the database connection string, and copies the same validation logic into three different files. They launch on time. Six months later, a database migration breaks production because there were no tests to catch the issue, and fixing the validation bug requires changes in three places instead of one.
A team inherits a legacy codebase.
The original developers left two years ago. The codebase has no documentation, inconsistent naming, and a single 4,000-line file that handles all business logic. The new team spends three weeks just understanding the code before they can add a simple feature. They propose spending 20% of each sprint on debt reduction.
An engineering manager quantifies technical debt for leadership.
The team tracks that feature development velocity dropped from 12 story points per sprint to 7 over the past year. They estimate 40% of each sprint is spent working around existing debt. The manager presents this as: 'We are paying $200,000 per quarter in developer time on workarounds. A $150,000 investment in refactoring would recover that capacity within two quarters.'
In practice
Read more on the blog
Frequently asked questions
Is all technical debt bad?
No. Intentional, well-tracked technical debt is a valid business strategy. Shipping a feature with known shortcuts is fine if you schedule time to pay it down. The problem is untracked debt that compounds silently. The key question is: does the team know the debt exists and have a plan to address it?
How do you convince leadership to invest in paying down technical debt?
Translate it into business terms. Track velocity trends, bug rates, and onboarding time. Show that feature delivery is slowing and calculate the cost in developer hours. Frame debt reduction as investment with measurable returns: faster feature development, fewer incidents, and shorter onboarding. Avoid saying 'we need to refactor.' Say 'we can ship features 30% faster if we invest two sprints in infrastructure.'
Related terms
Restructuring existing code without changing its external behavior to improve readability and maintainability.
The practice of having other developers examine code changes before they are merged.
The amount of work a team completes per sprint, measured in story points or similar units.
A fixed time period (usually 1-2 weeks) in which a team commits to completing specific work.
The prioritized list of all planned work that a team has not yet started.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.