Technical Debt
Technical Debt
What is technical debt?
- Rushed, sloppy code piles up like 'debt'
- Left alone, it accrues interest (slower delivery)
- Repay through refactoring
When the term technical debt enters a team, the first thing to change is the language of the conversation. What used to be individual developers’ impressions, such as 'the code is messy' or 'nobody wants to touch that file', becomes a financial item with principal and interest and gets onto the management agenda. Only then does a negotiation become possible, such as 'to ship 12 features this quarter, what percentage of sprint capacity do we set aside for repayment?' Speaking in estimates instead of feelings is the practical value of this concept.
Different kinds of debt are repaid in different ways. Debt is commonly sorted into four types along two axes, deliberate vs. inadvertent and prudent vs. reckless, and the most dangerous in practice is 'reckless and inadvertent' debt, because you don't even know you've borrowed. By area, it splits into code debt, architecture debt, test debt, data and schema debt, and infrastructure and documentation debt. Code debt can be cleared with a few weeks of refactoring, but architecture debt needs quarterly planning. The boundaries matter too: something that behaves wrongly right now is a bug, while something that works well but is expensive to change is debt. Not every old system is debt either — stable legacy code that nobody needs to touch accrues no interest.
The most common mistake is deciding to 'pay it all off at once' and launching a full rewrite. If you declare a six-month feature freeze and the new system isn't finished, you end up running it in parallel with the old one, and instead of paying anything off, you now carry two sets of debt. There is a misconception on the other side, too. If the debt list lives only on a wiki page and never becomes tickets in the backlog, nobody will ever read it. If management dismisses it as 'the dev team's internal matter', no repayment budget is allocated, and in the end you pay it back at several times the price, after a major outage hits. Debt is a balance, not an event, so repaying a fixed percentage in every sprint is the realistic approach.
Jaryong KooMarketing PhD and authority in AI, data analytics, and personal branding
John KimAuthor of B2B Marketing Design and CEO of Nanum ConsultingWard Cunningham proposed the concept in 1992, comparing code shortcuts to 'debt'. It has since become a key term in discussions of software maintenance.
Consider a hypothetical case: Company A, a logistics SaaS company with 140 employees. After three years of pushing features with 18 developers, its two-week release cycle slipped by an average of 12 days and production incidents rose to 11 a month. A newly hired developer took three weeks just to fix how an amount is displayed in the payment module.
- At a sprint retrospective, the CTO said, "We're not late because there are too many features. Every change we make is just expensive," and had the team classify the causes of the 87 delayed tickets from the past six months. More than half were concentrated in one place: the payment and settlement module.
- The development team lead pulled the debt out of the wiki and logged it as 47 tickets in the Jira backlog. Once each ticket listed its estimated repayment effort and the hours wasted each month if left alone, the order for paying them off was set by the numbers.
- At an executive meeting, the product owner proposed setting aside a fixed 20% of sprint capacity for repayment. When the sales director asked, "Won't that delay features?", the CTO answered, "We're already 12 days late."
- They dropped the full rewrite, split off just the payment module, and focused on it for six weeks. After raising test coverage from 18% to 62%, they restructured its internals. They handled the remaining areas by cleaning up each file whenever feature work touched it.
- Seven months later, average release delays had fallen from 12 days to 3, and monthly incidents from 11 to 4. The time it took a new hire to make a first deployment also dropped from 3 weeks to 5 days.