Technical debt
en.wikipedia.org
en.wikipedia.org
Much of what counts as badness in code never gets in the way until you have to understand or touch a particular area of code. The impact depends upon change cases.
A good analogy is deferred maintenance [1]. That's where you fail to maintain something like a building or a piece of machinery. There's a new and complicated federal standard for measuring it. [2]
Measuring technical debt for software is especially hard, because we don't measure much else about it. Programmers sit around coding, presumably creating a valuable asset. But it's hard to say what the value is, so we mostly don't. That makes it even harder to estimate how bad code reduces the value of that asset.
One easy proof that it's more than a fuzzy metaphor, though, is how often people declare technical bankruptcy. There's the total rewrite, our equivalent of Chapter 7. [3] And we have the partial rewrite and the cleanup around a major new version, both akin to Chapter 11. [4]
I agree that some of those rewrites are driven by new use cases just being so wildly different than the old ones that it's on longer the same system. But a lot of what I'd call technical debt would have to be cleaned up for most likely changes.
One could look at it from an "if we don't change it, the debt never counts" perspective, which makes the debt look as if it isn't real. But I have yet to see a software project that keeps running for an extended period without anybody wanting to change it, so I think that perspective is a false hypothetical.
[1] http://en.wikipedia.org/wiki/Deferred_maintenance
[2] http://www.fasab.gov/pdffiles/handbook_sffas_42.pdf
[3] http://en.wikipedia.org/wiki/Chapter_7,_Title_11,_United_Sta...
[4] http://en.wikipedia.org/wiki/Chapter_11,_Title_11,_United_St...
One day you lose your home.