BT

Dissecting Technical Debt

by Vikas Hazrati on Oct 20, 2009 |

The term "technical debt" was coined by Ward Cunningham. It describes the obligation that a development team incurs when it chooses a design or construction approach that is easy to implement in the short run but has a larger negative impact in the long run. Agilists provide their view point on what should be considered a technical debt and how it could be classified.

Martin Fowler suggested the following definition for technical debt,

Technical debt, is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

Steve McConnell classified the technical debt into two kinds,

  • Unintentional – Junior developers writing bad code because of their inexperience.
  • Intentional - Team makes a conscious decision to optimize for the present rather than for the future by making some design choices which may be a quick and dirty way of resolving the situation.

Uncle Bob, added that sometimes mess is also considered to be technical debt. This is not correct. According to him,

A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.

Uncle Bob suggested that technical debt creates a need for cleanliness in the code, just like one needs to be more disciplined when he takes a big mortgage debt. He added that once the team decides to take a technical debt, it becomes all the more important to keep the code squeaky clean. Unless, this is done the situation might quickly disintegrate and paying off the debt would be a harder challenge.

Martin Fowler gave his view point that a mess is also a technical debt albeit of a different kind. He described mess as a reckless debt which results in amplified challenges as compared to a prudent debt which is based on well calculated situation. He further classified the technical debt as deliberate and inadvertent to complete the quadrant.

Martin gave the following examples for classifying technical debt into quadrants

  1. Reckless - Deliberate – The team does not have time for design and provides a quick and dirty solution with little foresight into quality.
  2. Prudent - Deliberate – The team must ship the product now with the known shortcomings and take a proactive lead on the consequences.
  3. Reckless - Inadvertent – The team is unaware of the basic design principles and hence does not even realize the mess that they are introducing.
  4. Prudent - Inadvertent – This is true for teams with excellent designers. They deliver a solution which is delivering business value but after completing the solution, they understand what the best design approach could have been.

Thus, having a technical debt in a project is usually inevitable and should be considered to be an expectation. The key lies in making sure that a team is not introducing reckless debts which contribute to the mess and are very difficult, if not impossible to deal with.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Messes happen for more reasons than inexperience by peter weissbrod

The above article implies that the blame for a mess always falls at the hands of the developer, but sometimes its not that simple. I have seen talented developers with over a decade of experience deliver "high-debt" solutions. Why? Inefficient solutions can come from poor cross-team communication and poorly executed up-front analysis. If your specs have oversights in terms of efficiency, then it will likely reflect in the code.

It's a management problem, really. by Jeroen van Bergen

This is just another manifestation of the usual trade off between quality, time and functionality. A team under pressure has to make decisions on what to sacrifice. Usually quality is dropped first, incurring the mess that we all know and love.

A clean rewrite of a 1.0 version might be expensive, but the lessons learned during the first development cycle will improve quality considerably. But the merits of this will only be visible in the long run. A lot of software is judged only on functionality, not on maintainability or adaptability.

And lets not forget how hard it is to write really good, bug free software. One of my favorite examples is how even the IEFBR14 program (en.wikipedia.org/wiki/IEFBR14#History_from_the_...) was incorrect in some ways. The story about IEFBR14 also illustrates that improving software is an evolutionary process. More modern techniques like refactoring have speeded up the process, but the basis is still the same.

Best definition I've seen of technical debt... by Jason Reid

The best definition of TD that I've seen is "the difference between what the code is and what the developers think it should be." This acknowledges that technical debt can accrue even if the developers always "do the right thing". All it takes is for them to learn something new and have the realization that the code should look different, and they've accrued technical debt. This kind of situation happens often, for example, when a new version of a library or framework is released and the developers feel it should be incorporated to their software.

Re: Best definition I've seen of technical debt... by Norbert Winklareth

The best definition of TD that I've seen is "the difference between what the code is and what the developers think it should be." ...


Jason, I find your definition to be too loose. It allows developers to make changes based on their biases and not on the ease of changeability of the code, which is what Ward was after. Consider a code base that is correct, DRY, uses Information Hiding correctly, has a test suit and a complexity measure of 2.6, see Keith Braithwaite's work on impact of Unit Tests on complexity and the problem with it is that for the current set of developers it was implemented to use Smoothsort instead of Heapsort which they are familiar with and so they wanted to change it, even though they had no requirements to make changes in that part of the code base. This example is based on a true situation I observed, with details changed to protect the innocent.

Technical Debt is about the economic cost of future development and if the definition one uses does not include this then it misses this point and does not provide a way for those involved to make decisions appropriately, see The Principles of Product Development Flow. So any Technical Debt definition needs to prevent changes based on developer biases that do not reduce the cost of future changes.

Re: Best definition I've seen of technical debt... by Brad Appleton

I blogged somewhat comprehensively on the subject of Technical Debt and included a fairly thorough list of hyperlinks and references over at Technical Debt - Definition and Resources

I defined it by saying ...

    "Technical Debt [a.k.a. Design Debt] occurs when our software becomes difficult or risky to change, and takes increasingly more time/effort to evolve.

    Technical debt represents the accumulated amount/cost of rework that will be necessary to correct and/or recover from the deviation between:
    * the current design of the system, versus ...
    * a design that is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery.


    This effort grows more than linearly over time as a system becomes bigger and more complex."


I think this manages to synthesize the definition that Jason liked so much while also addressing the issue the Norbert raised. Do you agree?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT