Here are all the presentations I received, organized by day:
Monday, April 18: DagstuhlMTD_Day1
Tuesday, April 19: Dagstuhl-MTD-Day2
Wednedsday, April 20: Dagstuhl-MTD-Day3
Thursday, April 21: Dagstuhl-MTD-Day4
Here are the slides presented during my lightening talk :
Remediations in SQALE-Dagstuhl
In software-intensive systems, technical debt is a design or implementation construct that is expedient in the short term, but sets up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.
As requested, the definition that Ipek presented is below. Feel free to refute, extend, show gaps, etc. in the comments so we can improve:
Technical debt as a software design issue that:
And last, but not least, thanks a lot to our colleagues from Brazil (Graziela Tonin, Fabio Queda Bueno da Silva, Alfredo Goldman, Guilherme Horta Travassos) for treating us all to such a fun, cultural classic from their part of the world. In case next week you would like to try this yourselves here is the recipe:
Ingredients: Half a lime cut into 4 wedges, 2 Teaspoons brown sugar, 1 2/3 oz Cachaça
Preparation: Place lime and sugar into old fashioned glass and muddle (mash the two ingredients together using a muddler or a wooden spoon). Fill the glass with crushed ice and add the Cachaça.
Joseph Purcell, from Palantir in Madison, Wisconsin has another interesting metaphor: Technical pollution
Slides here: https://josephdpurcell.github.io/Lorax/dist/2015-madison-php/index.html#/
and a video of his presentation:
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:
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 s.th. 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.
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  (and various people also mentioned the problems on this blog). To give only a few examples:
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  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..
 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.
 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
As I consider the different charts, models and diagrams most often used to explain the concept of technical debt, it occurs to me that they are missing an important dimension, which I will call ‘sensitivity.’ In short, does this item/problem/issue matter within the larger context of its (eco)system? This dimension was also missing from the static analysis tools I wrote and used earlier in my career, which severely impacted their usefulness, and therefore their usage.
In particular, I remember deploying FindBugs at Google , and the conclusion that the tool could not determine the impact of the defects it found because it had no context. Putting that context into economic terms, what is the price of an item, or perhaps the price of either fixing or ignoring it? We talk about costs and benefits, which to my mind are generally fixed quantities. But the price of a item is variable, and allows us to bring the powerful laws of supply and demand into the picture.
“What’s it worth to you?” I asked myself. When I was facing 100,000 build targets with missing direct dependencies while attempting to disallow transitive build dependencies , my price was very low. Once I had automatically fixed all the easy cases, my price rose as the goal got closer. I priced the final few, most difficult fixes very highly, as the value of all the earlier work depended on their timely completion. Once finished, the build system permanently enforced the desired property, essentially making the price infinite from then on. The debt in question had been paid off.
So, I am arguing that we use some analogy of ‘price’ as the measure of what matters in the larger context, and let the ‘market’ set that price for each TD item. Some items will be quite price sensitive, others quite insensitive, to extend the metaphor. This will bring the social aspects of economics into our models, and perhaps cube the quadrants by adding another orthogonal dimension.
 Nathaniel Ayewah, William Pugh, J. David Morgenthaler, John Penix, YuQian Zhou. Evaluating Static Analysis Defect Warnings on Production Software. Proc. 7th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, ACM Press, New York, NY, USA (2007).
 J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, Sanjay Bhansali. Searching for Build Debt: Experiences Managing Technical Debt at Google. Proc. Third International Workshop on Managing Technical Debt, IEEE (2012).