Technical debt is the differential between the solution you have in hand, and the idealized hindsight-refined vision of what it could be: If there’s a solution solving problems, there are people telling any who’ll listen about all of the mistakes made in its implementation.
This debt is lamented on programming boards everywhere as the folly of those who came before. Not only as the cheap critique of others, but we often criticize our own implementations when we had to take shortcuts due to time constraints, help was unavailable, we didn’t entirely understand the platform or the requirements, tooling was limited, etc.
Pragmatic developers — or the ones with the actual task of actually creating solutions — view it as a “how the sausage is made” kind of reality, while others view it as a mistake that shouldn’t have happened, and with proper care and control we could learn and avoid it in the future. In the imaginary view of projects, we’d ideally build with the planning, time, knowledge and resources to never have technical debt in the first place.
But that’s nonsense the world over, across almost every strata of projects. Code starts ugly, universally. It’s a basic truth of the industry.
There are no exceptions. If you live under delusions that your current solution isn’t ugly, be sure to revisit this assessment in a year. And when a project really tries to circumvent this, it invariably ends up in analysis paralysis, nothing of consequence generated after person-decades of development.
And this idealized hindsight suffers from a severe survivorship bias. The idealized “make-it-right-from-the-outset” projects that all failed and fell by the wayside years before get forgotten, essentially lost in time, but instead we remember and study the process leading to the clunky duct-tape project that has run the organization for the past decade, hanging around long enough to be resented and belittled.
Technical debt almost always comes with success. It comes with a project becoming important enough that it matters, drawing attention and considerations and criticisms. It’s exactly those projects that are good enough that we find it hard to rationalize replacements (this is where dogma diverges from reality), and when we do the second-system effect is in full effect, our efforts to justify new projects leading us to overwrought, overly ambitious efforts.
Celebrate if you have technical debt to complain about. It usually means you’re sitting on something successful enough to matter.