Technical Debt Quadrant

by Krishna on October 14, 2009

Martin Fowler clears up some of the confusion around the term “technical debt“:

The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small – such as if it were in a rarely touched part of the code-base.

So the useful distinction isn’t between debt or non-debt, but between prudent and reckless debt. […]

there [is] a difference between prudent and reckless debt, there’s also a difference between deliberate and inadvertent debt. The prudent debt example is deliberate because the team knows they are taking on a debt, and thus puts some thought as to whether the payoff for an earlier release is greater than the costs of paying it off. A team ignorant of design practices is taking on its reckless debt without even realizing how much hock it’s getting into.

It seems that Martin is suggesting that the best debt you should have is the prudent-inadvertent debt, where you only understand the technical debt after working with the application. It is not a case of recklessness where you decided to ignore design, or be content in your ignorance. Or a case where you weighed all the pros and cons and then decided for the quick-and-dirty approach. The prudent-inadvertent debt is something that happened despite your best intentions and efforts.

The way to explain this is that there are potentially different ways to design an application. For example, if you take the creational design patterns, you may have to choose between competing patterns. You may start using a Factory pattern, but then need to change that for something more flexible. Or you start out with a relational database design and then later find you have to denormalize or use a NoSQL database because the application became too successful. It is hard to predict the changes in requirements and sometimes, you have to make the decision using present day considerations.

There are always gray areas in those quadrants. Assume that you are building an online application. It is impossible to know ahead of time whether you will get 100 visitors per day or 10,000 or a million. You could choose to target a million, but that could be over-engineering the application. Maybe 1,000 seems a happy medium or maybe you are making a terrible mistake of under-estimating traffic. Making design decisions in these cases can seem reckless or prudent after the fact.

Perhaps the real mistake is to think of design as an independent process. Much is tied to business decisions and forecasts. And where your technical debt falls is determined by those business factors.

{ 2 comments }

Mike Marshall October 14, 2009 at 8:43 pm

Good Points. Martin’s 4th quadrant feels like the old “We don’t know what we don’t know.” problem. It seems like we could sit and deliberate over those items for a long time, but in the end — you have to go. Whining about “unknowns” wastes time & money.

Design a good solution based on what you know. Test it against several possible “futures”, and understand what you will do if any of those futures comes to be. Accept that there are gray areas in the real world. Make a decision, and go.

Krishna October 15, 2009 at 10:46 am

Yes, Mike. You have to make some tough decisions at some point. It is not possible to design for every eventuality.

Comments on this entry are closed.

Previous post:

Next post: