Nobody can tell you what the tech debt costs

Everybody promises that once this gets promoted properly they’ll rewrite it from scratch and it never happens. That’s usually described as a failure of will. It’s worth asking why you’d do it at all.

If you have a working prototype that’s handling the demand, has the features it needs and doesn’t require rebuilding except to satisfy the sensibilities of the people who wrote it, then spending time and money on that makes no sense. Whether it was originally labelled a prototype or a proof of concept is irrelevant. What matters is whether you can say what’s actually wrong with it and if you can’t enumerate the problem then there isn’t a case.

I work with teams who complain constantly about being mired in tech debt, who describe it as a large risk and say it slows them down. So look at what the company actually records. The incidents log doesn’t show many incidents and none that trace back to running risky code in production and the risk register has nothing on it about ageing code or dependencies past their end of life. And no team has ever managed to articulate how the debt slows them down, or by how much.

Given that, nobody should be surprised when leadership won’t fund fixing a problem that has no visible impact. That’s not managers failing to understand engineering. That’s a reasonable response to a request with no evidence attached.

Which doesn’t mean the debt isn’t real. It might well be and the people closest to the code usually have an accurate feel for where the danger is. The problem is that a feeling doesn’t survive contact with a ordering meeting and the fix is to produce the evidence rather than to repeat the claim more forcefully. Attach the incidents to the code. Put the end-of-life dependency on the risk register where somebody has to sign next to it and measure how long a change takes in the bad area against a comparable one elsewhere.

The opposite failure exists too and it does more visible damage and I’ve watched a team spend months refactoring an application they’d written themselves, before it ever launched. They built it, decided they could make it better and reworked most of it while the value it was meant to deliver sat waiting. Leadership was furious, understandably, and what’s left afterwards is very little trust.

That’s the real cost of both versions. One team can’t get funding for work that might really matter because they never built a case. The other burned the credibility that would have got them the funding, on work nobody asked for, to fix code that wasn’t in front of a user yet.

The conversation worth having is about deliberately taking on debt and deliberately paying it down, with numbers on both sides. That’s a harder conversation than either complaining or quietly refactoring and it’s the only one that gets you the time.

There’s a decent test you can run on yourself before asking for the time. Write down what you expect to be true in six months if nobody touches this, in terms somebody outside your team would recognise, and then check whether any of it has been true over the last six. If the answer is that everything carried on working and nothing broke, that’s worth knowing before you make the case rather than after somebody else points it out in the meeting.

And if you’re on the other side of the table, the useful response to a tech debt request isn’t yes or no. It’s asking what breaks if you wait a year, and being willing to fund it properly when somebody can actually answer that.