In terms of a loan, the "principal" is the short-term productivity gains by hacking solutions. The "interest rate" is the percentage loss in future productivity or the added expense in percentage terms of maintenance. It may be fixed over time as fixing bugs and adding features is more expensive by some constant factor. It probably compounds over time though as hacks are built upon hacks (and therefore be a variable increasing rate).

The interest is more important to medium- to long-term projects. It's also the explanation for why I read so often that salaried employees hate consultants setting up a system; the consultants are in essence borrowing from the future productivity of another companies' employees and yet they get to reap the short-term productivity gains in the form of getting paid for delivering on time - what a deal for them!

As a framework for pricing the loan I suggested thinking about it in the reverse; rather than acquiring technical "debt" you are implicitly forgoing technical "investments" - spending time today to realize greater output per time in the future. This is opportunity cost, and it has value. The choice becomes whether or not to make the investment.

Anti-regressive measures like refactoring in a sense have zero short-term productivity but positive long-term productivity. If short-term output is more important to a company then they have a higher discount rate and therefore losses in short-term productivity must be compensated by greater gains in long-term productivity.

There are two types of risk - one affects the estimates of the cost of the loan (return on investment) and the other the discount rate (time value of money). For the former, a big risk is staff turnover, not just in terms of employment but at the project level. If the developers of a system leave after it ships, future productivity losses from such loans are likely to be far greater than retaining people with an intimate knowledge of the system. For the latter, start-ups have a higher bankruptcy risk and therefore a higher discount rate. There are business and economic risks as well, such as lost market share and shocks to the labor market.

I don't think there can ever be a formal model since it's an impure science. My post was merely an outline of the required steps to perform a traditional financial calculus of the decision to take on a single debt item. It implied a lot of intermediate estimation and guesswork and for some loans it may not produce reasonable values.

And it can be argued, no matter the method used, that it's impossible to capture the positive externalities that are realized by committing to best practices. Developers are people after all, and people are arguably more motivated by being in a culture that cares about quality work and low-level input.

I had a thought on this early this morning when I was somewhat less than awake.

Although there's no concept of separate lenders in technical debt, we can get something almost as good. When faced with the need to take on technical debt it might be possible to select among several solutions that have different interest rates.

Imagine a problem that we don't have time to solve correctly, but a small amount of brainstorming produces two potential hacks. One is the nightmare you normally get in this situation. The other leaves some wiggle room for a few unit tests or some minor validation code that helps recognize edge cases.

Even though this second solution still increases the technical debt in the system, it has a lower interest rate because it helps to point out the places where it makes maintenance harder.

I have known good programmers who added some kind of trap code in a half-way solution to point out when boundaries were reached. This allowed writing simpler, mostly right code that could be ready now, without incurring all of the problems of the complete hack. When we approached the areas where this solution began to break down, we got an indication that there was a problem and could fix it when needed.

This might even be a good tactic to help mitigate the risks in a quick-and-dirty solution.

Imagine the following scenario.

• The right solution will take a week
• The quick hack will take a day, but will cost a day's effort every month to work around/clean up
• With an extra hour or two of effort, we can think we can reduce the monthly cost to somewhere between 2-4 hours.

It is likely the business side and technical side would see this as a worthwhile investment of extra time.

As I was writing the other comment, another strategy came to mind. Anyone with a mortgage or car loan is probably familiar with a useful piece of advice for servicing a long-term debt. Making an extra payment now and again can make a significant difference in the time to pay off a loan

In the context of technical debt, we could imagine a commitment to spend some time now and again to adding tests or doing some refactoring to pay of some of the principal of the technical debt when we get a little time. Imagine you have a little time at the end of an iteration, adding a few unit tests or validation for edge cases to our worst offenders could reduce the cost of working with this code. As the debt is reduced, so is the interest we end up paying.

In the case of a financial debt, this kind of extra payment strategy requires a fair amount of discipline, but it can reduce the time to pay off a debt significantly.

It might even be possible to schedule this kind of work in a bug tracking system or as part of the task list for a project. We could consider this lower priority work that is only scheduled when we begin to catch up.

G. Wade

You would probably think of developing a method of measuring technical debt (rather than a simple equation or model) because it must necessarily be project-specific, and the "true cost" of each item (ex. deferred refactoring) is best known by those that would implement them.

"True cost" of each item not only depends on how often bugs need to be fixed, but also on how many additional features need to be implemented - and that's likely to be a more significant cost. After all, technical debts often comes from taking short-cuts - which lead to less code. Less code leads to fewer bugs, and easier fixes. But it makes it harder to expand the system. However, it's usually not the developer who decides if and how many features will be added. It's the customer (internally or externally).

And this brings up another point. Debt in the financial world is often a well understood quantity. A mortgage lasts 20 or 30 years. Loans between banks will have a known interest rate, and it's known when it will be repaid. Not so with software. I may have some idea how much "technical dept" a project creates, but often it's not clear at all how long it will last. A piece of software may be obsolete within a year. It may last 20 years. And even if it lasts 20 years, there may not be demand for change.

Quantifying debt (and its risks) means you have to have a good idea of the future. Financial institutions do that with contracts and collaterals. But that doesn't translate to software.