I've found the Technical Debt metaphor to be extremely helpful, especially when conversing with non-technical project stakeholders. The web is full of anecdotes about technical debt, but most of them never go beyond the basic notions of "accruing debt" and making "interest payments." I believe the we could go much deeper with this metaphor.
In the financial world, debt comes in many shapes and colors: short-term, long-term, collateralized, fixed-rate, floating-rate, installment, balloon, callable, convertible, and so on. And pricing that debt (i.e. determining the interest rate) is a complex calculation based on numerous risk factors such as default risk, exchange-rate risk, inflation risk, call risk, etc.
If we apply these concepts to software development and technical debt, perhaps we can develop the same kind of sophisticated models that are used for financial debt. In practice, these models usually require quantitative data that are rarely available in software development. But putting that aside, I wonder if we could at least produce some compelling theories.
I don't have a strong background in finance, so I just wanted to put the idea out there and see if my fellow Monks have any thoughts to contribute.
Thanks for sharing.
-Jeff
|
Re: RFC: Exploring Technical Debt
by BrowserUk (Patriarch) on Sep 24, 2009 at 00:39 UTC
|
| [reply] |
|
|
Whoa! And what about "Technical Default Swaps"? That would be scary...
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
Re: RFC: Exploring Technical Debt
by whakka (Hermit) on Sep 24, 2009 at 20:42 UTC
|
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. Having experience with similar projects would aid in more accurate estimates.
Simplified, the problem can be stated: "Solving debt item D now would take N man-hours. D makes it X% longer to fix certain kinds of bugs on average.* We can expect to encounter these sorts of bugs Y times per year. The average expected time it takes to fix these bugs is Z man-hours. Given the staffing on this project I would weight this figure by W." You should similarly add the man-hours saved for implementing new features. D's per anum opportunity cost (in man-hours) is then the sum of X * Y * Z * W for all such bugs + (similar sum for new features). This can be thought of as future "earnings" for fixing D now.
It then becomes an intertemporal cash flow problem. You must consider the time cost involved to make the fix now versus how much time is involved in repayment for the future. You only consider those years you expect the project to be maintained (the longer the time the less important this estimate is). The ultimate comparison of each item should be the cost of fixing D now (N) vs. the present value of all future productivity losses from D in maintenance and new features (F). If N - F < 0 it's better to fix the problem now, otherwise we should shelve it for later, if ever.
To calculate F you determine a discount rate, a non-trivial task based on a variety of difficult to estimate factors. In general it's the necessary return on investment of paying developers now to be more productive in the future, plus risk (ex. bankruptcy risk of delaying a shipped product, risk of employee turnover, security risks, inflation risk, etc). It's difficult to do this simply and in a suitably general way. If developer time would otherwise go to adding new features on the same product, the value of those features should be used to calculate an internal rate of return on those features (based on an analysis of how much higher the product would sell for or how many more copies it would sell). Similarly, if they would otherwise go to another project, that project's marginal IRR should be calculated and used. Alternatively, the company's WACC may or may not be appropriate. Calculating F is now a matter of running an NPV algorithm in a spreadsheet.
Since each input is an estimate, it would be prudent to repeat this calculation using a variety of values for your estimates, picked based on how confident you are in them (how well their cost is known) and for worst-case scenarios. For example you may consider a steep discount rate if your company's survival is strongly determined by the success of your product as it's shipped in 4 months.
**Updated for clarity.
*X must be determined inside the technical domain, so consulting existing studies might be misleading. | [reply]
[d/l] |
|
|
I think this is definitely on the right track. As you pointed out, the really hard part is devising a method for calculating the parameters in any such model. But for now, I'd like to put that aside and just focus on what the models might be.
Actually, what I really want might be a bit less academic than a formal model. I'd like to see a discussion that relates more financial concepts and terminology to software development. If we consider "technical debt" as some kind of loan, then who exactly is the lender and who is the borrower? What part of is the principal and what part is the interest? How does the "interest" compound? How are the "funds" actually exchanged between parties. What are the incentives for the lender and borrower to enter into this transaction? How do lenders choose the right borrowers? What are the risks for either party? How do parties hedge those risks?
Some of these questions seem to have intuitive answers at first glance, but I feel that they haven't been fully articulated yet. So as software developers, I think most of us really only have a superficial grasp of the "technical debt" concept. But I want to believe that our understanding can go much deeper than what we currently see in typical literature.
I don't have the answers here, but I'm eager to facilitate the discussion.
-Jeff
| [reply] |
|
|
I think to address the issue of terminology, the "debt" is simply all future productivity losses from "hacking" a short-term solution to a problem. You (the company or project owner) are "borrowing" from your developers' future productivity to increase their productivity today. Productivity (output/time) can be measured in value.
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.
| [reply] |
|
|
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.
| [reply] |
|
|
|
|
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.
Really? I find that a dubious statement, and I'm not going to accept it if you don't add some substance to the statement.
"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.
| [reply] |
Re: RFC: Exploring Technical Debt
by gwadej (Chaplain) on Sep 24, 2009 at 15:12 UTC
|
I read an article sometime in the last year that described explicitly taking on technical debt in order to get a project done before a conference. The author described it in terms of taking out a loan to help a business, knowing that the loan would need to be repaid with interest.
I need to find that article again.
| [reply] |
|
|
The article was older than I thought: Voluntary Technical Debt.
This article and Steve McConnell's work introduced me to potential benefits of technical debt. I had seen this (without a good term for it) from really good programmers in the past. But, this was the best explanation I had seen.
| [reply] |
|
|
Thanks for the link! I had read this before, but it was worth revisiting. I especially like McConnell's distinction between long and short-term debt.
This is basically the kind of thing I'm looking for, but I'd like to see more details. In other words, more analogies between financial and development concepts.
As soon as I have the spare cycles, I'm going to write up a hypothetical project scenario, and explore some of the equations that whakka proposed. I think that a narrative might be easier for me to understand than a formal model.
| [reply] |
|
|
