Technical Debt Explained for Business Owners
Technical debt is the future cost of shortcuts taken in software today. A quick fix, a copied block of code, a skipped test or an outdated library can save time now, but every later change to that part of the system costs more until the shortcut is repaid. A little debt is a reasonable business decision. Unmanaged debt shows up as features that take longer each time, bugs that return, and a system nobody dares to touch.
You don’t need to read code to manage it. You need to recognise the symptoms, ask for a written list of known debt, and budget time to pay it down.
The short answer
- What it is: shortcuts whose cost is paid later, with interest, every time that part of the system changes.
- Why it happens: deadlines, unclear requirements, changes of developer, and libraries that age.
- Symptoms: slower changes, recurring bugs, fear of updates, knowledge held by one person.
- What to do: keep a written debt list, ask for it to be costed, and set aside part of each release cycle to repay it.
- When to rebuild: rarely, and only when debt has made safe change impossible.
Where the term comes from
The metaphor comes from Ward Cunningham, a programmer, in a 1992 report on a financial software project. His words are worth quoting because they are often misremembered:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
Two things stand out. Cunningham did not say debt was bad; he said a little debt speeds you up. And he located the danger precisely: in not repaying it.
What it looks like from the owner’s chair
You will rarely hear the words “technical debt” from a struggling supplier. You will see the effects:
- Every change takes longer than the last one of similar size.
- Fixed bugs come back, or fixing one breaks something else.
- Updates are postponed because “it might break things”, so libraries and servers fall years behind.
- One developer is the only one who understands a part of the system.
- Estimates come with a nervous margin for parts of the system nobody wants to touch.
- Simple requests get complicated answers, such as “we’d have to change it in five places”.
None of these alone proves a problem. Several together almost always do.
Where debt comes from
- Deadlines. A shortcut taken to hit a launch date. Reasonable, if it is recorded and repaid.
- Unclear or changing requirements. Code written for one understanding of the business, then bent to fit another.
- Changes of developer. Each new person adds their own approach on top of the last.
- Age. Frameworks, libraries and servers that were current at launch become outdated and eventually unsupported, which is also a security problem.
- Skipped foundations. No automated tests, no documentation, no consistent structure.
A test you can apply without reading code
Abdulqader Wahiba, founder and CEO of ZAWAT, offers owners a simple test:
“Ask your supplier for the list of known debt in your system, and what each item would cost to fix. A team that has one is managing it. A team that says there isn’t any either doesn’t know, or isn’t telling you.” — Abdulqader Wahiba
Every real system carries some debt. The difference between a healthy system and a failing one is whether that debt is known, written down and being repaid.
How to manage it
Keep a written debt list
Each item should say what the shortcut is, which part of the system it affects, what it costs you now (slower changes, risk, recurring faults) and what it would take to fix. That turns an invisible problem into a list you can prioritise like any other.
Repay it in every cycle
Agree that part of each release cycle goes to repaying debt rather than new features. The share is a judgement for you and the supplier, but it should never be zero. Debt that is never scheduled is never repaid.
Keep dependencies current
Frameworks and libraries should be updated regularly, in small steps, rather than once every few years in a risky leap. This belongs in the maintenance and support agreement, not in a separate project.
Make the shortcut explicit when you take one
If a deadline genuinely matters, taking on debt can be the right choice. Do it deliberately: record it on the list when it is taken, with a date for repayment.
Protect knowledge
Documentation, automated tests and code that more than one person understands are what make debt repayable. Without them, every fix is risky, and the debt keeps growing.
Refactor or rebuild?
When debt is heavy, a full rewrite is tempting. It is usually the wrong answer. A rewrite takes longer than expected, recreates old features while the business waits, and often reintroduces old problems in new code. The safer path is to replace the system in slices while it keeps running, as replacing a legacy system without stopping the business explains.
A rebuild is justified when the platform itself is unsupported or insecure, or when debt has made safe change effectively impossible. Even then, it should be done piece by piece.
If you inherited a system
If you have taken over a system from a previous supplier, or the developer has left, start with an independent review: the state of the code, the dependencies, the documentation and the debt. Rescuing a stalled software project covers what to secure first.
Frequently asked questions
Is technical debt always bad? No. Taken deliberately, recorded and repaid, it can speed up a launch that matters. It becomes harmful when it is invisible and never repaid, because the “interest” grows with every change.
How do I know if my system has a lot of technical debt? Watch for changes that keep getting slower, bugs that return, postponed updates and parts of the system only one person understands. Then ask the supplier for a written list of known debt, with the cost of each item.
Who pays for technical debt? You do, either as slower and costlier changes, or as the cost of repaying it. A good supplier tells you when a shortcut is being taken and what it will cost later, so the decision is yours.
Should we rewrite the system from scratch? Rarely. Rewrites are slow and risky. Replacing the system in slices while it runs is usually safer, unless the underlying platform is unsupported or insecure.
How much time should go to repaying debt? There is no universal figure; it depends on how much debt you have and how fast the system changes. What matters is that some time is scheduled in every cycle, and that the debt list gets shorter over time.
Sources: Ward Cunningham — The WyCash Portfolio Management System (OOPSLA '92 experience report)
Worried about the state of a system you depend on? ZAWAT reviews, maintains and modernises custom software, and will tell you plainly whether to repair or replace. Book a call.