Technical Debt Series – Good Technical Debt vs. Bad Technical Debt

  • Post author:
  • Reading time:5 mins read
You are currently viewing Technical Debt Series – Good Technical Debt vs. Bad Technical Debt

In my previous post, we defined technical debt and saw how not all technical debt is bad. Just like in the financial world, some type of debt is 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 Flower1 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. On the other hand, 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 then we think, measured in weeks and not months or years.

Fowler2 also introduces the concept of the technical debt quadrant to highlight the need to understand 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 new to development, they don’t yet know some of the best practices of good design and 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 like we saw in the earlier post, things like we don’t have time, testing is hard, we already took a short cut here, etc…
  • In the prudent and deliberate quadrant, we are making a conscious decision to taking 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 McConnell3 takes another angle at 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 re-payment 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 not paying down the debt creates a vicious technical debt cycle.

1. http://martinfowler.com/bliki/DesignStaminaHypothesis.html

2. http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

3. http://www.construx.com/10x_Software_Development/Technical_Debt/