In my previous post, we defined technical debt and saw that not all technical debt is bad. Just like in the financial world, some types of debt are considered ok, as long as it is paid back. Consider a house loan or a car loan for example. Those are generally considered acceptable types of debt […]
In my previous post, we defined technical debt and saw that not all technical debt is bad. Just like in the financial world, some types of debt are considered ok, as long as it is paid back. Consider a house loan or a car loan for example. Those are generally considered acceptable types of debt in order to enable us to achieve more by having housing and transportation. Martin Fowler uses the design stamina hypothesis to describe this.
Here, we see that we get some benefit by ignoring good design and taking on technical debt. But soon the productivity flattens out. The good design route starts out slower but soon becomes almost linear. The intersection point between good design and bad design is referred to as the design pay-off line. This means once you are above the line, it no longer makes sense to ignore good design decisions because you would be delivering more functionality on the good design route. The trick is to figure out how far off are we from the pay-off line and Fowler argues that this is a lot closer than we think, measured in weeks, not months or years.
Fowler also introduces the concept of the technical debt quadrant to highlight under what circumstances we take on debt. In the inadvertent and reckless quadrant, we have folks that just don’t know any better. They are unaware that the actions they are taking are piling up debt. In the reckless and deliberate quadrant, we have folks that know that the actions they are taking cause debt but make up excuses, things like we don’t have time, testing is hard, we already took a shortcut here, etc… In the prudent and deliberate quadrant, folks make a conscious decision to take on debt for a specific business outcome with an action plan to pay it back later. The prudent and inadvertent case is a rare one and refers to hindsight being 20:20. Given the best intentions at the start, we still ended up with some debt and now we know better.
Most of us are probably in the reckless-inadvertent or reckless-deliberate and we should all move to the prudent-deliberate. Once there, we can strategically take advantage of technical debt the same way we do with financial debt. That is, we keep our code base debt free and when the right opportunity presents itself, we can then take on debt to pursue that opportunity and deliver quickly to take advantage of market conditions. On the other hand, if we are marred with technical debt, then we will have to watch that opportunity pass us by as we are unable to respond to it due to our already high debt and our slow moving process.
Steve McConnell takes another angle on technical debt and categorizes it as long term or short term. Think mortgage balance vs. a credit card balance. A long-term strategic type of debt can be a decision to support a single platform. For the next 5 or 10 years, we expect to use only that platform and there is no need to complicate things by supporting multiple platforms. This is considered a good long-term type of debt as we will not face slowdowns or high-interest payments over the 10 years.
A short term strategic debt can be a decision to quickly patch up a piece of code in order to release a product and come back and fix it immediately after the release. This is kind of like making a purchase on credit and then paying back the balance the next month or so.
Bad debts are the short term kind with no repayment plans. This is where many small short debts quickly accumulate and hamper our progress. These types of debts need to be avoided at all costs similar to high-interest credit cards.
In my next post, we will see how this creates a vicious technical debt cycle.
Good Technical Debt vs. Bad Technical Debt is the fourth in a seven-part series on Technical Debt from Excella Software Development Lead Fadi Stephan.
Part 1: Top 4 Symptoms of Bad Code
Part 3: What is Technical Debt?