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. 
• In marketing their platforms, big vendors often overlook technical debt. For example, these vendors like to talk about the myriad capabilities their platforms (.Net, Fusion, Google App Engine, etc.) provide. Their customers might be just as interested in these platforms as an opportunity to consolidate technical debt, making it more manageable.
• ISVs rarely see all of the customer's accumulated technical debt. When customers grumble about upgrading their customizations and integrations to accommodate a new version of a product, vendors are hearing the tail end of a discussion about the technical debt customers imposed on themselves with customizations, integrations, and other aspects of the actual factual systems as they are deployed. 
• In the customer's eyes, upgrades are inflection points. Vendors who have a hard time understanding their customers' unwillingness to upgrade are often making very different calculations than their customers. From the vendor's perspective, migrations from older to newer versions are always good, since the new versions have more capabilities (and bug fixes) than older ones. Customers are looking at a very different set of numbers. Prominent among these calculations are (1) the ratio of benefits to costs of sticking with the old version, and (2) the ratio of benefits to cost of migrating to the new version. Whatever numbers you want to plug into those calculations, you always wind up with one line that starts higher than the other. While they eventually intersect (the value of moving to the new one exceeds the value of sticking with the old one), the customer is hard to budge until they reach that inflection point.

As you can see, the questions that technical debt inspires keep unfolding. Since I just published a piece on the business ramifications of software as a service (SaaS), it's also worth noting that SaaS changes some of these considerations about technical debt. For example, through SaaS, ISVs can get more visibility into the technical debt from the customer's perspective, and they can help customers reach the inflection point for upgrading earlier. Still, technical debt never disappears, either in the ISV's own code, or the customer's implementation of it.