When you were a child, you may have played with a paper fortune teller (a.k.a. cootie catcher). By folding and unfolding this origami-like construct, you produced answers for questions you posed.
The topic of technical debt is a lot like the paper fortune teller: the more you unfold the topic, the more interesting observations emerge. Israel Gat wrote two recent posts (click here and here) at his blog, The Agile Executive, that illustrate the sort of costs that technical debt imposes. His second post focuses on the most conspicuous cost: The more you develop, heedless of the technical debt you create, the harder and harder it becomes to make further changes. While this may seem like an obvious conclusion, it's not one that has the impact on software development that it should. In their rush into the future, building code that is supposed to expand choices, many teams are actually constraining their choices.
For ISVs, technical debt has a lot of important ramifications. Here are just a few:
For startups, aggressive product road maps can be counterproductive. The more you develop, the more competitive your product, right? That formula seems obvious to most insurgent vendors, but there's definitely a point of diminishing marginal returns, when the cost of maintaining all that aggressively-developed code exceeds the company's ability to continue developing and supporting it.