Technical Debt in Product Lines – on the trouble of differentiation

Traditionally, technical debt research (implicitly) takes a single-system perspective. However, what happens in product lines? Is there also technical debt (you bet) – are there further forms of technical debt? Probably..

In our recent research, my group also addressed the notion of (code) smells in product lines. There is already some research in this direction, but very often from the perspective of: how do existing smells translate to the product line situation. We were more interested in the perspective: what are novel types particular to product lines.

What is particular about a product line is that it typically contains a variability model (describing possible features and their relations) and the code that is related to these features. For a specific feature combination that is selected then the corresponding code is extracted / generated / composed, etc.
We grounded our studies in Linux, a well-known reference case, as it is with about 15.000 features and industrial-size product line. (There code is C-code with pre-processor statements, while variability is expressed using the special language Kconfig)

So what are the kinds of problems that arise there? And are they REALLY technical debt items – or are they defects? (Kruchten argues very strongly on this blog – and I think correctly – that these two are actually very different)

Typical problems relevant for product lines are for example:

  • dead features,
  • dead code (or the inversion),
  • or where we was interested in: over-constrained code

But what are these beasts and if we use the following definitions

“Technical debt = non-user-visible issue in the system implementation that creates a problem for evolution”
“Defect = user-visible issue that leads to a problem for the user (unexpected / unintended) behavior”

are they defects or technical debt?

A dead feature is a feature that cannot be selected, although it is described as selectable. It is probably a safe bet this is a defect. For dead code, it is more difficult: this means that some code is not used in any variant, although it is described as variable in the code. This may have many reasons like added constraints in the build system or in the variability model that interact.
At first sight this may seem clear: certainly the problem is now not activated in some situations for which it was intended. This is surely a defect! – On the other hand, it may be due to the fact that these variants do not even exist any more, making it simply some code that is maintained, but effectively dead code, i..e, technical debt.
The situation of over-constrained code is even more complex as simply in some cases where one might expect this code to be present it won’t be. Whether this qualifies as a defect or technical debt requires a deep analysis of which code should be integrated under what circumstances and what would be required for correct functioning. We found in our analysis that there was hardly any difference in amount of effort spent between identifying whether had a user-visible effect (i.e., defect) or was technical debt and actually proposing a change for solving the problem altogether. Hence, while the differentiation between technical debt and defect seems rather obvious and intellectually appealing, we also saw that it sometimes is of rather little practical use.

Apart from this specific question of technical debt vs. defect, I am also looking forward to discussing special forms of technical debt like product line technical debt or debt handling in software ecosystems.

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