Technical Debt

Short answer: Technical debt describes the weaknesses that build up in software, in connections between systems and in data setups. They make every later change slower, riskier or more expensive. Programmer Ward Cunningham introduced the term, comparing shipping imperfect first-version code to borrowing money. Shipping the first version is like taking out a loan. The extra effort spent working around code that is not quite right is the interest. Rewriting the code properly repays the debt. Later writers extended the idea to rushed or careless work and to shortcuts in general.

A company can take on debt deliberately, such as launching a quick version to meet a deadline. It can also take it on by accident, through rushed work, missing documentation or a design that no longer fits how the business operates. Debt also builds up when nothing changes at all. Software ages, supporting products stop receiving updates and the people who understood the system leave. In a growing company, technical debt often shows up as manual workarounds and fragile spreadsheets linking systems. It also shows up as connections that break after updates and changes that take much longer than their size suggests.

A company usually finds technical debt by asking its developers or software supplier where their time goes. Warning signs include repeated fixes to the same part of a system, problems caused by one connection, or features delayed because an area is hard to change. The developers or supplier list each item with two estimates: the effort to fix it and the ongoing cost of leaving it. Leaders then decide which items to fix, which to live with and which to remove by replacing the system altogether. Many companies agree a fixed share of their developers' or supplier's time for fixing debt. That way, the repair work does not have to compete with every new request.

A company builds a quick connection between its online store and its warehouse system in three weeks instead of six. That saves about 120 hours of developer time. The shortcut skips error handling, so staff must fix failed orders by hand, at about 10 hours a month. After 12 months, those fixes have cost 120 hours, which equals the original saving. The team estimates a proper rebuild at 140 hours. Every further month of delay adds another 10 hours of interest.

Technical debt helps leaders understand why technology work slows down over time. It also explains why teams ask for time that produces no visible new feature. The cost shows up as slower changes, fragile workflows and connections that break after routine updates. When each debt item has an estimated size and a monthly cost in hours, leaders can weigh a quick fix against the work it creates later. It also matters when choosing a system, because hidden debt affects the true cost of what the company buys.

Technical debt is hard to measure precisely, and people sometimes stretch the term to cover any code a team dislikes. Not all debt needs fixing. Debt in a system due for replacement soon may be cheaper to live with. Estimates of interest and repair effort are judgments. The team should test them against tracked effort instead of accepting them on trust.