Misunderstanding technical debt

Things that seem self evident are often not… When Ward Cunningham coined the metaphor of technical debt he hardly suspected that there would be widespread controversy over what it was meant to explain. Yet, while researching my posts about Competence debt, I have come across a multitude of opinions. The only thing people seem to agree upon is that technical debt is bad (at least if it is allowed to grow too much) and that refactoring is a way of lowering technical debt.

A natural instinct for someone in software is to try to figure out the correct definition of technical debt. This is misguided since a metaphor can not really be defined. A metaphor is a tool that can help you explain a problem. The same metaphor can be used in many different ways. So the only way a metaphor can be used in the “wrong” way is if it does not help someone understand the problem you are concerned with. So with a slight nod to Douglas Adams: if technical debt is meant as an explanation, what is the question?

I would argue that the question is: What is it that makes many systems harder and harder to maintain over time? A secondary question is then: How can we keep systems from becoming harder and harder to maintain?

I have found two main schools in explaining the decline of maintainability: evolving understanding and crappy code.

Evolving understanding

Ward himself if the chief proponent of this view. Here is a short video where he explains what he originally meant with technical debt. Ward sees software development as a journey where you start out with a limited understanding of a problem domain. As your understanding grows you come to realize that some of the assumptions you made in the beginning were wrong. You therefore need to modify the system so that it reflects your current understanding. If you do not, the system will become harder and harder to maintain. Ward does not see any point in the idea of intentionally adding poor code and cleaning it up later.

One subtle aspect of the way Ward explains technical debt is that he is implicitly talking about software development as a solo effort. He never mentions the fact that there can be multiple and competing “understandings” of a problem in a group. Nor does he mention the fact that most software is built on top of frameworks and that these also evolve.

Crappy code

The other view of technical debt is best exemplified by Henrik Kniberg’s blog: The Solution to Technical Debt. Henrik describes technical debt as simply being badly written code in your system. He goes on to admonish developers for putting it there in the first place. I feel that Henrik oversimplifies since his view is in essence static: code is good or bad. He makes no provision for the fact that code can start out “good” but become “bad” over time. Still there is some truth to his view. In any development group with more than a few people there will be times when bad code is added.

Before and after the fact

Supporters of the evolving understanding view of technical debt often argue that poor code is not technical debt. I wonder if they are not confusing intent and result. I strongly support the notion that you should never intentionally put bad code into a system. The idea of technical debt should not be used to condone bad software craftsmanship. The question is still: what do we call the poorly written code that manages to become a part of our system despite our best efforts? Giving it a separate name will not alter the fact that the effects of crappy code are more or less identical to the “correct” type of technical debt.

Every single large system I have ever studied has had both types of technical debt. That is a much more serious problem than what we choose to call these problems.

Niklas Björnerstedt

Posted on 2013.12.10 at 9:29

Comments are off for this post.