When Technical Debt Costs You MORE!
We've all heard of the metaphor of technical debt by now. Maintaining poorly written software costs more in the long term, even if it saves in the short term. Thinking of this as a form of debt helps explain this in terms business-oriented stakeholders can understand.
Metaphors are valuable because they can meaningfully convey a concept through a different context. They bridge the gap between two different ways of thinking. Sometimes we can take the metaphors a little too far, and they become disconnected from what they are actually trying to represent. This has happened with the metaphor of technical debt. Other times, we can explore the metaphor to find deeper relationships between the real concepts and the metaphorical ones.
Financial debt has the concept of interest in it. Interest is an extra charge on top of the original value lent. It covers risk and provides incentive to the lender. It is calculated as a percentage on top of the principle amount of the loan. So a loan of $1,000 with an annual interest rate of 5% incurs $50 of interest in a year.
Technical debt is not as easy to quantify, but the idea of interest carries over. The interest on technical debt is manifest in the need for change. Code needs to change to meed new needs and new demands. Code that is technical debt is hard to change, and costs more when it does need to change. The additional cost comes in the form of time spend to understand what the code is doing, time spent refactoring the code, time spent shoe-horning in a change that could be simpler, and time spent fixing bugs because the code is too complicated. If the debt is not paid off through refactoring, the interest keeps accruing every time that code needs touched.
This definition, equating the rate of interest to the rate of change, leads us to a few conclusions. First, we see that if we need to change a bad piece of code often, that code is more expensive. Conversely, bad code we never or rarely change doesn't cost as much. The "interest rate" is lower for code that doesn't change. From this, we can see that we need to focus refactoring efforts on high-traffic code. We should do the refactoring as we are making changes to that code as we are already taking on the risk of making changes. We should also use automated tests to "collateralize" our technical debt, lowering the risk of change when we do need to make those changes.
By seeing the technical debt as not just a static metric, but as one that grows over time, we can make the case to address the right debt first for the best outcomes.
Metaphors are valuable because they can meaningfully convey a concept through a different context. They bridge the gap between two different ways of thinking. Sometimes we can take the metaphors a little too far, and they become disconnected from what they are actually trying to represent. This has happened with the metaphor of technical debt. Other times, we can explore the metaphor to find deeper relationships between the real concepts and the metaphorical ones.
Financial debt has the concept of interest in it. Interest is an extra charge on top of the original value lent. It covers risk and provides incentive to the lender. It is calculated as a percentage on top of the principle amount of the loan. So a loan of $1,000 with an annual interest rate of 5% incurs $50 of interest in a year.
Technical debt is not as easy to quantify, but the idea of interest carries over. The interest on technical debt is manifest in the need for change. Code needs to change to meed new needs and new demands. Code that is technical debt is hard to change, and costs more when it does need to change. The additional cost comes in the form of time spend to understand what the code is doing, time spent refactoring the code, time spent shoe-horning in a change that could be simpler, and time spent fixing bugs because the code is too complicated. If the debt is not paid off through refactoring, the interest keeps accruing every time that code needs touched.
This definition, equating the rate of interest to the rate of change, leads us to a few conclusions. First, we see that if we need to change a bad piece of code often, that code is more expensive. Conversely, bad code we never or rarely change doesn't cost as much. The "interest rate" is lower for code that doesn't change. From this, we can see that we need to focus refactoring efforts on high-traffic code. We should do the refactoring as we are making changes to that code as we are already taking on the risk of making changes. We should also use automated tests to "collateralize" our technical debt, lowering the risk of change when we do need to make those changes.
By seeing the technical debt as not just a static metric, but as one that grows over time, we can make the case to address the right debt first for the best outcomes.
Comments
Post a Comment