IMHO, "rot" or "wear and tear" is actually much better metaphor to use with management than "debt" or "unhedged call option". Financial terms implies a degree of precision to the cost, and for debt, it also implies some predictability.
In reality, code that's fine today may become problematic tomorrow for all sorts of reasons -- some internal to the organization, some external, some predictable, some not. Like rot, the exact amount of code that needs refactoring or fixing is difficult to quantify precisely. Like rot, there's often some (sometimes crazy) workaround in lieu of fixing the rotted bits. And just as we can design our structures in ways that are less likely to rot over time, we can write code that's less likely to become problematic in the future (with the corollary that the decision not to invest in better initial infrastructure today may result in problems tomorrow at some unknown time and place).
Its obviously semantics, and I'm not advocating sloppy programming / architecture, but the term is both inaccurate and leads people to blinkered thinking.
Isn't this the definition that everyone uses?
