Technical debt explained for business owners

Technical debt is the future cost of shortcuts taken in software. Like a loan, a shortcut saves time now and then charges interest: every change becomes slower, more expensive and riskier until the code in question is reworked. It is not necessarily a mistake. It is a management decision that can be measured, steered and repaid.

This guide explains the metaphor behind the term, the warning signs you can see from the top of the company, what debt really costs and how to pay it down without stopping the business.

Where the term comes from

The phrase was coined by Ward Cunningham, one of the pioneers of agile methods. In 1992, in an experience report presented at the OOPSLA conference about software for managing financial portfolios, The WyCash Portfolio Management System, he wrote that "shipping first time code is like going into debt", and that "a little debt speeds development so long as it is paid back promptly with a rewrite". The danger, he added, "occurs when the debt is not repaid": every minute spent on not-quite-right code counts as interest on that debt.

The image was chosen to speak to people who think in money, and it still works with business owners because it turns a technical argument into a management question: how much are we borrowing, at what rate, and when do we pay it back?

Financial terms, translated into software

The third line is the one that matters. Interest is paid every time someone touches the affected code. Debt sitting in a module nobody changes costs little. The same debt at the heart of your invoicing, which you adjust every month, costs you constantly.

Not all debt is a mistake

Software author Martin Fowler proposed a useful way to classify debt, his technical debt quadrant (2009). It asks two questions: was the debt taken on deliberately, and was it taken on prudently?

Prudent, deliberate debt is a sound business decision: making a trade show, testing a market, shipping an MVP before investing more. Prudent, inadvertent debt is unavoidable, because any team understands your business better as the project goes on. The other two boxes are the problem: they pile up without anyone having decided or priced them.

Warning signs you can see from the top

You do not need to read code to suspect heavy debt. The symptoms show up in how the project is managed:

• small changes get quoted higher and higher, with no change in what they contain;
• every fix breaks something else, and releases make the team nervous;
• security updates keep getting postponed because they "might break everything";
• only one person can work on a critical part, and their absence stops everything;
• the team suggests a full rewrite with every new request;
• estimates are no longer met, even though the team has not changed.

Any one of these can have another cause. Several at once almost always point to debt that nobody is managing anymore.

What technical debt costs

The available figures come from self-reported surveys: they give an order of magnitude, not a measurement of your own application.

• In 2018, Stripe's Developer Coefficient survey, run with Harris Poll among more than 1,000 developers and 1,000 C-level executives in the United States, the United Kingdom, France, Germany and Singapore, found that developers spend on average 17.3 hours a week (out of 41.1 hours worked) on maintenance: bad code, errors, debugging, refactoring and modifying.
• In 2020, a McKinsey survey of 50 CIOs at financial services and technology companies with revenues above $1 billion, Tech debt: Reclaiming tech equity, reported that 10 to 20% of the technology budget meant for new products is diverted to resolving issues related to tech debt.

For a smaller business, these averages matter less than your own symptom: if a change that used to take two days now takes ten, the difference is the interest on your debt, and you pay it on every request.

Paying it down without stopping the business

The right strategy depends on where the debt sits and how often you change the application.

1. Take stock. List the known debts, locate them and estimate what each one costs per change. An independent software audit does this from the outside.
2. Repay where you work. Clean up code when you are changing it anyway, rather than in a separate big-bang project: that is where the interest is paid, so that is where repayment pays off.
3. Reserve a steady share. A fixed fraction of each development cycle spent on clean-up, tests and updates prevents over-indebtedness. The right level is agreed with the team, based on the state of the code.
4. Make it safe before changing it. Automated tests on critical parts let the team rework code without breaking the rest.
5. Keep dependencies current. A library left without updates for years turns into debt, then into a security risk.

A full rewrite remains the exception. It makes sense when the interest exceeds the cost of rebuilding, for instance when the underlying technology is no longer maintained.

Questions to ask your team or vendor

• What are our three most expensive debts, and where are they?
• What share of development time goes on interest rather than new features?
• Which debts did we take on deliberately, and when do we plan to repay them?
• Are our dependencies and our core technologies still maintained? Our guide to choosing a tech stack for business software helps you check.

A team that can answer these questions precisely is managing its debt. A team that cannot is being managed by it, and so are you.

Where to start

Write down the last three changes requested on your application, what they cost and how long they took: that is your first debt indicator. If a rebuild turns out to be necessary, at LPR Studio the visual prototype of the new version is free and presented in a video call within 5 working days, so you can see the target before you decide. How we work is described in our approach.