Technical Debt – not to be taken at face value

The term “technical debt” has done a lot to help get acceptance for the issues and problems we are dealing with. – However, it is ultimately a metaphor, i.e., an analogy. Analogies are handy tools to get a first intuition about a problem. However, they are not a model of the problem!
So, ultimately, on the way towards a better understanding they turn from support to obstacle. The most famous example is the “atom = planetary system” metaphor. Initially it helped a lot, but over time it became clear that the analogy leads to very much inappropriate reasoning and had to be completely abandoned in favor of quantum mechanics to really understand and solve the problems.

Already now we see that a lot of elements of the “debt”-metaphor do not work [1] (and various people also mentioned the problems on this blog). To give only a few examples:

  • the notion of a principal does not really fit: you do NOT pay off the same debt. – In some cases you will actually never pay of the debt as it makes no sense [2]
  • interest payments: financially there is a fixed rate (typically), but in TD it only depends on how your further development goes.
  • there is no reasonable notion of risk-free, not because there is no possibility for an optimal design, but rather because what was optimal can usually only determined in retrospect when also future requirements are known.

So it seems a reasonable question to ask:

“Is the TD-metaphor (and the financial analogy) actually helping or hurting the cause of dealing with technical problems in development?”

Given the overall amount of work that was poured into this and the fact that still today many arguments are based on this analogy , it must be allowed to at least ask this question. What if we step back, completely forget about the term “debt” and ask what is it we really want to address from a SE perspective?
In some earlier work [2] I actually tried this and as a result was able to propose an approach for the systematic management of technical debt that effectively navigates treacherous waters like the lack of a meaningful definition of principal in TD, paying back being not mandatory, etc. – So from that perspective I am happy, but at the same time this work was still strongly influenced by the metaphor, so I think, we can surely do better.
I say this in particular, because conceptualization is on the agenda for the workshop, hence forbidding the term “debt” and any referral to the analogy for a day or two might actually be a healthy exercise..

[1] K. Schmid. On the Limits of the Technical Debt Metaphor – Some Guidance on Going Beyond. Fourth Workshop on Managing Technical Debt, Workshop at the International Conference on Software Engineering, 2013, pp. 4, IEEE, 2013.
[2] K. Schmid. A formal approach to technical debt decision making. Proceedings of the 9th international ACM Sigsoft conference on Quality of software architectures (QoSA), 2013, pp. 153-162