The cooling fan from Australia: the real story behind technical debt

“Technical debt.” That sounds more like something for “the IT guys and girls.” A matter of refactoring, upgrading, migrating. Just “modernize everything” and you're done.

If only it were that simple.

Technical debt is a topic for the boardroom.

Ward Cunningham coined the term in 1992: technical debt. The idea was this: software ages. Just like machines. Except software doesn't wear out through friction, but through the world around it. New requirements. New threats. New integrations. New people (who no longer understand the old choices).

And yes, real technical debt also exists. I once worked for an organization with an IBM mainframe that was end-of-life and out-of-support. But the machine was still desperately needed. When a fan stopped working, the search didn't end at IBM, but at a shady internet auction... in Australia. Second-hand. The only question was: “Does it still work?” No one had any idea. The thing was ordered, and on top of the purchase price, we paid for transport and import duties. All in all, it was a price that could fill a good chunk of a modern server rack.

Sounds like a hardware problem? No. It was a software problem with a fan.

Look, that mainframe was necessary because one crucial system refused to run on newer mainframes. The replacement system was ‘almost ready’. Until it fell behind schedule. And then fell further behind. And further still. And when it finally went into production, it was rejected and had to go back to the drawing board. So the old system continued to run. With a fan from Australia.

That's why you rarely solve ‘technical debt’ with more modern technology.

Not with new hardware. Not with a new network. Not with ‘we're moving to the cloud’. Because the cloud doesn't rent out understanding. You can't keep running Windows 2003 there without pain either. You can move debt around. Package it. Hide it. But you can't buy it away.

Technical debt is usually not a technical shortcoming. It is an accumulation of choices: procrastination that became normal, priorities that were never really priorities, responsibility without mandate, projects that start but are never finished. And a roadmap... that actually mainly offers comfort.

So if you want to reduce debt, don't start with tooling. Start with knowledge, ownership, and decision-making. Otherwise, you'll end up in a vague auction at questionable costs. Only then the fan will be called a “migration program.”

Windows 2003 is not “legacy,” it is negligence.

Software degrades.

Not because a cog literally breaks off, but because everything around it keeps moving. Operating systems, browsers, protocols, APIs, compliance requirements, attack techniques, devices, user expectations. The world is getting faster. Your application stays the same. And that's exactly where the wear and tear starts.

If you read my blogs regularly, you know that I keep repeating this. Because I still encounter worn-out software too often. And above all: because you can prevent it.

I once spoke to someone who didn't even want to replace his car tires when the steel was already showing. “They'll last a while longer.” He told himself it was being economical. Maybe. But it was mainly recklessness. And I see that more and more in IT.

Example. This year, I came across a Windows 2003 server. “Yes, but the software doesn't run on 2008.” True. And I saw an old Wang machine that no one knew what it did anymore. “If we turn it off, everything stops... but we have no clue why exactly.” That's like driving on your rims, with a shower of sparks behind your car, while telling yourself you're “in control.”

Of course, it's usually less spectacular than that. But even with 1.5 mm of tread, you don't want to go into winter. Not only because it could land you fan mail from the CJIB, but because the first time you brake unexpectedly, you'll discover that “it was fine” is not the same as “it's safe.”

And with software, failure is only the most visible risk. Often not even the most expensive one.

Outdated software quietly eats away at your organization:

Sluggishness. Moore's Law may be flattening, but the leap between hardware generations is still enormous. Anything that remains stuck on old platforms takes a toll on productivity. Employees wait. Processes stall. And no one writes “waiting for system” on a timesheet. So it seems free. Until you do the math.
Usability. Old interfaces, strange limitations, clumsy workflows. Your team comes up with workarounds, Excel spreadsheets, step-by-step plans, and “that's just how we do it here.” These are all hidden FTEs. And modern working (at home, mobile, flexible) suddenly becomes an expensive Citrix/VDI construction, while a modern web app delivers this as standard.
Integration. Old software communicates using old protocols. So you put an integration platform in between. Expensive to build, expensive to manage, and above all: it adds complexity upon complexity. Every extra link is another place where things can go wrong.
Security. I still see measurements coming in with outdated encryption, simply because the transmitting system does not support more modern encryption. That's annoying enough for measurement data. But those same environments often also handle financial transactions. Then “it still works” is no longer an argument. It becomes risk acceptance—usually without anyone saying so out loud.

Software doesn't wear out suddenly. It wears out a little bit every day. This means that hidden costs also increase. And the longer you wait, the more expensive it becomes to regain control. That's the real spark: you only see it when it's already burning.

Why “AI fixes our legacy” is a dangerous lie

“Hugo, no problem, man, we'll solve it with AI.”

Of course. Because if you can frame technical debt as a technical problem again, you don't have to talk about priorities, ownership, and decision-making. It couldn't be more worrying. And I've already explained to many IT managers and CIOs that this not only shifts the problems, it only makes them worse.

Example: AWS announced specialized AI agents that detect and resolve technical debt for you. In practice: upgrades of Java, Python, and frameworks. Transforming code so that it compiles and runs on something newer. Handy. Sometimes even valuable.

But it's mainly like putting new rubber in your fuel system so that your old car can also run on E10.

You drive away again. Only you're still in the same car. With the same rust. The same rattles. And the same maintenance mentality.

I saw an ERP supplier that went through such an AI migration from an outdated low-code platform to .NET. The code was transferred 1:1. The result: a more modern platform, a longer support horizon... and exactly the same delays, locking problems, and functional errors. Everything that was bad came along for the ride. The migration was a move, not a renovation.

That is the core problem: the current generation of AI mainly performs textual transformations. This also applies to code. It can convert syntax, replace libraries, and rewrite patterns. But it does not understand your domain, your performance profile, or your data structure rot. And it certainly does not understand your organizational choices.

AI can help you identify technical debt more quickly and make some upgrades cheaper.

But it cannot save you from debt that arises from postponement as a strategy. And that is the cause of most technical debt.

As long as you continue to think that technical debt is “something for IT,” the use of AI is like a band-aid. Band-aids can be the solution... Except when you're driving on rims.

From “it still works” to “we are back in control”

Technical debt cannot be resolved with yet another tool, yet another migration, or yet another “clean-up” sprint.

It is resolved by making choices. And those choices require two things simultaneously:

technology (measurement, refactoring, modernization)
strategy (ownership, priority, rhythm, stop-go decisions)

At Sciante, we have been helping organizations stuck in legacy, delays, and “we don't dare touch this” for over 15 years. We solve everything. And we prefer to prevent new debt. But if the bill is already on the table, we also help you pay it off in a targeted manner. Of course, without shutting down your IT and without a multi-year plan that may end up running over time again.

Do you want to pay off or prevent technical debt?

Of course you do. Schedule a no-obligation appointment with me. In 30 minutes, we'll pinpoint where your debt really is, what it's costing you, and the three steps you need to take first to get back on track.