Technical debt, in perspective

"Technical debt", followed by a sharp intake of breath. It is like taking the car to a mechanic. But someone please find us a business that does not have some.

We are usually talking about inefficiencies. Inelegance. Systems that are not perfectly crafted or seamlessly integrated. It is hard to define precisely, but you know it when you see it. It is a bit of messy technology. Consultants love to circle it in red, partly because it is easy to identify and partly because it makes a report look thorough. We have done it ourselves.

Unless a company has never evolved, happened to design the perfect architecture first time, or has unlimited time to refactor between commercial deadlines, some level of technical debt is inevitable. Businesses change. Markets shift. Products get adapted. People come and go. Systems get bent to fit reality.

The more useful question is not whether debt exists. It is whether it creates drag. Do simple updates become unexpectedly complex? Are there parts of the system nobody wants to touch? Does leadership feel that things which should be easy take too long? Does every release feel like a small act of bravery?

That is when it stops being untidy and starts being structural. If the simple has become complicated, the technology may not stand up to an investment thesis in the cold light of day. Until then, it is just "history".

The job in diligence is to separate the two. To name the debt that is genuinely in the way, leave the rest alone, and avoid the temptation to flag everything that is merely imperfect.