Technical debt – ten years of an IT landscape as a simulation game

This article was created with the AI assistant Claude and published by Peter Hoenig.

"Technical debt" is one of the few technical terms from IT that business people understand immediately – and one of the few that nevertheless almost never appears in a decision. The reason is that the debt is not on any invoice. It grows quietly and only becomes expensive when it hurts. All of that can be played: Technical debt, ten years of an IT landscape in your browser, free of charge and with nothing transmitted.

What technical debt actually is

The term goes back to Ward Cunningham and means: if you build something quickly and take shortcuts, you borrow time. There is nothing wrong with that – sometimes it is exactly right. But the loan has to be repaid, and until then it costs interest. In practice that interest is called: every change takes longer. Every interface is a special case. Every newcomer needs three months before they dare touch anything.

In the game this is not a metaphor but a number. The higher the debt, the lower the speed of change – and the lower the speed of change, the less every investment achieves. That is the point at which most landscapes tip over: you do not work less, you simply get less for it.

Why the obvious strategy fails

The obvious strategy is to build. The business units want features, sales wants features, and building new shows an effect immediately. In the game the functional scope does indeed rise straight away – together with the debt. After three or four years the debt slows things down so much that the same lever only achieves half as much. After six years the outages arrive, because things built on debt break more often. In the end the estate consumes all the capacity, and nothing is left for anything new.

But the opposite does not work either. Anyone who only modernises and standardises ends up with an immaculate landscape that delivers nothing to anyone. Then the business units build their own solutions, and the game ends early with the note shadow IT. Everyone who does architecture management in practice knows that one too.

The lesson

Standardisation is the lever that takes effect latest and lasts longest: it lowers the interest rate. In the game – as in a household budget – that makes it the least popular investment, because for two years it has nothing to show. Those who see it through anyway have room in year eight that nobody else has.

Who is this for?

For IT managers who have to explain to their management why "just quickly" becomes expensive. For management teams who want to know what the IT budget actually goes on. And for workshops in architecture management: ten years are played in twenty minutes, and afterwards people talk differently about priorities.

In short

Free as free software, independently implemented: Open Technical debt. How networked thinking works I explain with no prior knowledge in Networked thinking – why simple cause and effect often leads you astray. If you want to put your IT landscape in order before compound interest makes the decision for you, do get in touch for a free initial consultation.

"Technical debt" is a simplified learning and thought model, not a forecasting tool and not an assessment of real IT landscapes.