Nice piece.
Tech debt -- we probably all have it. It takes on many forms (though one thing it usually is not is your predecessor's preference vs. yours … despite our proclivity to that point of view (you make a great point to not point that finger) ;-)).
It is easy to get past the fluffy definition of technology debt by anchoring it to a cost. Does Perl use have a cost? Yes... if you don't have and cannot get people that know it. Does a poorly performing bit of code represent technology debt? Yes... if performance delays you from doing something that you need to do (i.e., there is a business impact, not just inconvenience) ...
I hear the term monolith a lot. Is it tech debt? Must everything be microservices to be fresh? Absolutely not!!!! A few questions about monoliths help to determine whether such is a problem and is debt: (a) Is the codebase understandable? (b) Can be it be easily deployed and tested? (c) Is it easily enough extended? (d) Can integrations be easily enough built between it and something else? (e) Can it be monitored well and to the level needed? (f) Can so-called modules be easily enough replaced?
Truth be told, the above should hold for all the software that we write... which, itself, is a mostly true statement. What if you generate code? Assuming it works and performs as required, does it matter whether generated code is perl or python or C# or LISP? Not as long as the runtimes are current and supported ...
The more insidious "tech debt" is really "organizational debt" ... we build technology with architectures that become entangled with our organizational architectures, and then wonder why -- when we don't adjust both together -- change is hard.
Probably a good perspective on both tech and org debt is that "it" is whatever is out of synch with how we work or that keeps us from doing so, and the measure of impact is how much it costs us in lost opportunity to work differently, to get new business, to expand what we have into new markets.
Our architectures need to be fresh ... but "fresh" doesn't always mean the latest shiny things that show as fads and, before we know it, they become deeply embedded into our architectures without having given thought to the more strategic concerns noted in your piece and above. We can identify the true impacts of the tech and org architecture choices we make, and assess the risks implied, and see if our businesses can afford them. If they cannot, make changes ... do things differently ... in ways that the business can afford, and in ways that unlock the potential to do old things in new ways, and things that are entirely new ...
