That's a very insightful observation. Over my career, I would find myself doing the hard work to advocate for improving code and developer practices, and I would often encounter resistance from management. By becoming starting a consultancy and narrowing the work that we do to just that kind of improvement, we're able to ensure that only the organizations that are at least somewhat open to the idea are the ones who approach us for help. Fighting that battle internally is a tough job.
Another thing I really like about the work on This Old House is that they give a lot of care making sure that the new things are added blend in with the structures that were there to begin with.
One of the things that I like to anecdotally measure is how long a similarly complex change takes. Over time, if it takes longer, then you're likely suffering from tech debt issues. If you're able to turn things around so that it starts getting done faster, then it sounds like you're starting to turn things around.
On the missed deadlines issue, that reminds me of a blog we posted a while ago about why we stopped estimating ongoing development on these types of code bases[1].
I also like to use the metaphor of a car that's stuck in the mud (or snow). The wheels Are spinning really fast and the engine is working really hard, but the car isn't going anywhere. It's only when you start trying to dig it out that you start to see forward progress, and even then, the progress is slow at first.
There are many different ways to describe this problem, and it's very possible that using a call option as a metaphor is a better fit. Unfortunately, "technical debt" is the term that's currently in fashion, so you at least have to mention it when you're suggesting an alternative approach.
Incidentally, we're big fans of Martin Cronje's article[1] which suggests that "technical debt" is a broken metaphor, and he suggests using "depreciating assets" as an alternative.
We already use depreciation in software when we start writing off capital allocation over time. This new metaphor maybe more confusing. I would rather stick with technical debt and give more context.
You're right to say that a microservices architecture and Docker won't solve the problem. That's not an accurate view of what Corgibytes advocates for. Microservices and Docker are tactical tools that can help many teams, but they don't work everywhere.
What does work is assisting that team to slowly clean up the mess that they've built[1] by focusing on incremental improvements.
[1]: And we find that almost all messes were created for very understandable reasons.
