Every shortcut a tech company takes is a loan. That’s the whole idea behind “technical debt”, a phrase programmer Ward Cunningham coined more than 30 years ago and the smartest bit of financial language software ever borrowed.
In my last column, I argued that we sell products before we build them. This is what happens to those shortcuts after the deal closes: they don’t go away. They sit in the system, charging interest, until you can’t make the repayments.
This is the second of three columns on the short-termism trap: how one habit – picking the quick win over the durable one – works its way through a tech business until it reaches the one place you can’t afford to lose ground: your customers.
Technical debt is the cost of choosing the quick fix over the right one: the code written to hit a demo date, the architecture nobody revisited once it “worked”, the system never upgraded because the people who understood it left, the integration bolted on instead of designed in, the culture of “let’s just do something quick”.
Each shortcut buys you time today. Each one taxes every job that touches it tomorrow. And the tax is real even when you can’t see it – which is most of the time, because it never shows up as a line item. It shows up as everything slowly getting harder. It’s the only debt you can carry for years without recording it. Right up until it records everything else.
It feeds itself. A messy system is hard to change, so the next change gets done quick and dirty, too – because doing it properly means untangling the last mess first. Complexity breeds complexity, and every new feature needs another hack piled on the last.
The engineers who could fix it are too busy keeping it alive. A team can burn most of its time just stopping a fragile system from falling over, with almost nothing left for the work that grows the business. That’s the compounding. The debt doesn’t only grow. It eats your ability to pay it back.
How to spot it
You can read a company’s technical debt in its symptoms long before anyone says the words. Costs that should drop with scale go up instead. Simple features take absurdly long. Releases become things people dread, not routines they trust. Good engineers leave – nobody enjoys spending their days cleaning up shortcuts they didn’t take – and they walk out with the only memory of why the system is the way it is. Which makes the debt worse.
South Africa has a rich collection:
- Our banks run some of the most advanced digital services anywhere on top of core systems written in Cobol decades ago – proof you can service debt for a very long time, at enormous and permanent cost.
- Our public sector IT is a museum of the same disease: systems that can’t talk to each other, budgets that fund the build but never the upkeep, and the same lesson every time – the cheapest bid carried the most expensive debt.
- Telecoms billing is some of the most debt-laden software on Earth, because we kept bolting on new ways to bill for things the network was never built to sell.
A leadership problem, not an engineering one
Technical debt is a leadership problem wearing an engineering costume. It builds up because the incentives that create it sit above the engineers, who solve the problem in front of them. Debt is invisible on the financials, so it’s easy to defer. The executive who defers it usually gets promoted before the bill arrives. The one who insists on paying it down has to defend a quiet quarter with nothing shiny to show for it.
As a result, taking on debt gets rewarded. Paying it down gets you blamed for going too slowly. That asymmetry – not a shortage of good engineers – is why there’s so much of it about.
To be fair, some debt is smart. Taking a deliberate shortcut to test whether anyone even wants the thing is good business – building it perfectly first would be waste. Not all debt should be paid off, just like not all financial debt should. The trick is knowing which is which.
The problem isn’t debt. It’s unmanaged debt – taken without a decision, tracked by nobody and serviced by accident. Smart debt is a choice you can see on a list, with a plan to pay it back. Most technical debt is neither. It’s the residue of a hundred small panics nobody wrote down.
The fix isn’t a heroic rewrite. Those usually just refinance the debt on worse terms. Rather, it’s the dull discipline of treating quality as a standing commitment, not a phase:
- Put real capacity into refactoring and upgrades every cycle;
- Make the cost of the debt visible to the people holding the budget; and
- Refuse the shortcut at the point of sale, where – as I argued last time – most of it is born.
Defending the long term against the quarter is leadership’s job, because nobody else in the building is paid to.
Sometimes the discipline is just walking away. When it’s clear a customer only wants a quick fix – and will blame you for the mess those hacks leave behind – the right answer is a polite “no thanks”. Business is a partnership. If one side is only looking to get one over on the other, there’s no deal worth taking.
And here’s the sting. The final bill for technical debt is rarely paid by the company alone. It’s paid by the customer – a product that’s slow to improve, quick to break and expensive to trust. Customers don’t send reminders the way creditors do. They just, quietly, start to leave. Which is where this series goes next.
- The author, Jannie van Zyl, has spent more than three decades in technology – founding several companies and holding senior positions in some of the industry’s largest. He’s a leading voice on innovation and the future, and writes here under his own name
- Read more pieces by Van Zyl on TechCentral
- Subscribe to TechCentral’s daily newsletter
- Get breaking news alerts on WhatsApp
