Technical debt; is it only technical?

Rogier Selie

The metaphor technical debt was introduced at the OOPSLA conference in 1992 by Ward Cunningham. The phrase was:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite...
The danger occurs when debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

The following picture shows how this "stand-still" described by Ward Cunningham is achieved.

http://theagileexecutive.com/2010/09/20/how-to-break-the-vicious-cycle-of-technical-debt/

In most discussions/blogs on the internet the following causes are mentioned and most are code related:

  • the business forces the development team to take shortcuts, aiming to get the requested functionality life as soon as possible.
  • the development team thought they didn't need to design.
  • the development team was incompetent/didn't bother to write maintainable/changeable code.
  • the development team  recognizes later for example by incorporating a change, that they made a suboptimal decision in the past (difficult to avoid).

Martin Fowler summarized this very well in his blog "TechnicalDebtQuadrant". He distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices. But this is still mainly code related.

But if you look at the forms of technical debt in real life situations, you'll see that these are not only code related. Technical debt may manifest itself in the following form to us:

  • Code form (as mentioned already), e.g. duplication, high McCabe index, high unit-length per method, high number of parameters in methods, wrong comments, unclear naming of objects, methods, variables and properties, etc.
  • Architectural form, e.g. violating separation of concern, the choice of not using a third party framework but build your own, not changing/adapting your architecture to the changes (gradual or abruptly) in the world around us.
  • Testing form, e.g. a decision to not do automatic testing, while testing the system by hand is to complex or takes to much time, to conclude after testing that everything is OK.
  • Deployment form, e.g. when a deployment is arranged in such a way that it costs a lot of time and is error prone, thus limiting the number of releases in a period in time.
  • Documentation form, e.g. it is unknown how the system should react in certain situations because it is not functionally described. This makes future functional wishes time-consuming to fulfill.
  • Functional form, e.g. by business requested and by the development team invented functionality that is not really needed and makes things unnecessary complex for the upcoming change.
  • Project form, e.g. distribution of experienced people vs. not experienced people in your team, same applies to skills in the team, onsite/off-shore team distribution, etc.
  • Organizational form, e.g. not asking your software (application) provider what kind of quality assurance policy they apply and if they can provide any quality figures based on a ISO maintainability-standard.

All these technical debt forms result in less changeability, more costs and delay in bringing new features life. All forms can be plotted on the TechnicalDebtQuadrant of Martin Fowler. Whether technical dept is categorized as deliberate, inadvertent, reckless or careful, it is good to be aware of this and see how you want to cope with it strategically.

Conclusion

Technical debt is not only technical and has several forms other then code form.  The metaphor "technical debt" is invented to visualize the problem of decreasing productivity in the life cycle of the software product. People  can communicate with the metaphor more easily about the problem it addresses. This way the concept became known by development community, and unfortunately less known in other areas listed above.

Management familiar with the metaphor, can use it as an advantage by making strategic decisions regarding technical debt, because they understand the concept of normal debt. But for strategic decisions the management should be aware how much technical debt there currently is (like a normal debt) and the chances of a technical credit crunch leading to possible technical bankruptcy....

So is technical debt only technical. No, it is not.

Comments (4)

  1. [...] Technical debt; is it only technical? [...]

  2. Paying Off Technical Debt « Codecraft - Reply

    October 15, 2012 at 7:28 am

    [...] Technical debt; is it only technical? (xebia.com) [...]

  3. Wicomico Bankruptcy Lawyer - Reply

    December 15, 2012 at 2:05 pm

    Thinking of technical debt in this way is attention-grabbing; however let us stop pretending that these are hard numbers that we can use to make trade-off decisions.

    • Rogier Selie - Reply

      December 19, 2012 at 12:29 pm

      Lindsay, thanks for responding on my blog. According to me technical debt was, when the metaphor was introduced in 1992 by Ward Cunningham meant for attention grabbing for developers. In 1992 there were no tools who measured technical debt on source code. Nowadays there is tooling which come up with numbers which according to me give an indication about the amount of technical debt on source code. They are not hard numbers too, because it is possible to write code which is not changeable but has a low technical debt number in several tools. In my blog I mention more facets where there can be technical debt. I agree with you that for other areas then code it is even harder to give "hard" numbers. But with that the problem that technical debt addresses (changes are getting harder an harder) does not disappear. My advice is to handle technical debt with care and with full awareness on the mentioned areas.

Add a Comment