The 1M$ question I have is how do we measure that technical debt in such a way is to make it clear that its not just some off the cuff number that the (probably defensive) development team will try to discredit, and will at the same time speak to a product owner?

Different measures have been proposed. (1) James Shore suggests the spag (http://jamesshore.com/Blog/An-Approximate-Measure-of-Technical-Debt.html), (2) I (and you) have disscussed the the gap between today’s code base and and its envisioned production-worthy future, (3) even measurements of the impact on a teams velocity. All seem like good ideas, the first and last at least use measurable metrics. The second is tricky, I have seen teams very quickly deploy crap into production environments – sometimes said crap does not smell for quite some time.

I still can help but feel that in a concrete sense, the idea of technical debt is as hard to measure as its nemesis “clean code”.

One thing that I think needs to be done is for our industry to stop glorifying “the hacker”, the lone wolves of old who where praised for being able to decipher the cryptic messes they themselves wrote. We should start praising those who write code their grandmothers can understand (or at the very least a SME). This shift in culture at least will open the door to an era in which young developers stop being proud of what they can read, but rather what they can write.