Technical debt concerns are not necessarily 'unvalidated' - at least not to the extent that almost everything is a little fuzzy in tech anyhow. For example: yo

Technical debt concerns are not necessarily 'unvalidated' - at least not to the extent that almost everything is a little fuzzy in tech anyhow. For example: you started a few feature with a few scripts, added a few new things here and there ad-hoc. Now it's growing and full blown and nary impossible to maintain. A more clear understanding of the problem space now exists, and also that a refactor would make sense. The continued inability to really move forward due to the rag-tag system is a kind of debt, and the trade off/decision has to be made as to wether or not the team needs to take a few steps back before moving forward. This is really common. I worked at BlackBerry during their heyday. If you are old enough to remember, there used to be international headlines when the BB email service went down. Everyone in the press was using BB and would harp on it. This is partly because BlackBerry had made a bunch of acquisitions and gun-taped the systems together, as opposed to properly integrating them. There was a real 'cost' to this bad press. The only real and fundamental way to avoid those systematic failures was to do a proper integration which in and of itself was a risky and unwieldy proposition for the company at the time. I'd argue that was a fairly material and validated form of technical debt.