Talks of the Week

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

 

Day 2 -Defining TD, Measurement & Analysis and Caipirinhas

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:

  • Exists in a system artifact, such as code, build scripts, automated test suites, data;
  • Is traced to several locations in the system, implying ripple effects of impact of change;
  • Has a quantifiable effect on system attributes of interest to developers, such as increasing number of defects, negative change in maintainability and code quality indicators.

And last, but not least, thanks a lot to our colleagues from Brazil (Graziela ToninFabio Queda Bueno da SilvaAlfredo GoldmanGuilherme 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.

Technical Debt Conceptual Model

We, the technical debt research community, agree that a common conceptual model of technical debt that we collectively improve and validate would increase the pace of technical debt research. Therefore, as organizers we felt it is important to tease this apart together during the workshop. Early conceptual models offered by Martin Fowler (the debt quadrants) and Steve McConnell (intentional versus unintentional debt) provided useful starting points, but do not suffice to guide answering the hard questions for eliciting, quantifying, and reducing debt and transitioning to developers validated, easy to adopt practices.

Different technical debt enthusiasts refer to this semantic model in different ways: “technical debt framework”, “technical debt landscape”, “conceptual model”, “empirical model”, “financial model” ,“quality model”, “measurement model”.  The concepts discussed in these models are not consistent either.  Is design debt the same as architectural debt? If defects are not technical debt, what are postposed defects? Does principal of debt map to all code quality violations? Does principal change? What are the attributes of interest?

The underlying goal of all these models are common, to guide defining technical debt concepts and creating methods to control the inputs and outputs for managing it. Several blog posts here already refer to the conceptual model.  In addition, there are several papers already published that can help shape a strawman conceptual model of technical debt.  We compiled a reading list to help us all prepare for our sessions during the workshop when we discuss the conceptual model.

We believe that a baseline model will help the technical debt community make collective progress rather than coming up with yet another model variation. The reading list is meant to be representative rather than all-inclusive. If we have skipped a fundamental work that should be included comment and we will add it.

All the papers referred to are here: Ipek TD papers (in a zip file).

Systematic literature reviews and technical debt landscape

Chen Yang, Peng Liang, Paris Avgeriou:
A systematic mapping study on the combination of software architecture and agile development. Journal of Systems and Software 111: 157-184 (2016)

Areti Ampatzoglou, Apostolos Ampatzoglou, Alexander Chatzigeorgiou, Paris Avgeriou:
The financial aspect of managing technical debt: A systematic literature review. Information & Software Technology 64: 52-73 (2015)

Zengyang Li, Paris Avgeriou, Peng Liang:
A systematic mapping study on technical debt and its management. Journal of Systems and Software 101: 193-220 (2015)

Edith Tom, AybüKe Aurum, and Richard Vidgen. 2013. An exploration of technical debt. J. Syst. Softw. 86, 6 (June 2013), 1498-1516.

Nicolli S. R. Alves, Thiago Souto Mendes, Manoel Gomes de Mendonça Neto, Rodrigo O. Spínola, Forrest Shull, Carolyn B. Seaman:
Identification and management of technical debt: A systematic mapping study. Information & Software Technology 70: 100-121 (2016)

Clemente Izurieta, Antonio Vetro, Nico Zazworka, Yuanfang Cai, Carolyn B. Seaman, Forrest Shull:
Organizing the technical debt landscape. MTD@ICSE 2012: 23-26

Philippe Kruchten, Robert L. Nord, Ipek Ozkaya:
Technical Debt: From Metaphor to Theory and Practice. IEEE Software 29(6): 18-21 (2012)

Comparative studies on debt identification:

Nico Zazworka, Antonio Vetro, Clemente Izurieta, Sunny Wong, Yuanfang Cai, Carolyn B. Seaman, Forrest Shull: Comparing four approaches for technical debt identification. Software Quality Journal 22(3): 403-426 (2014)

Griffith I., Reimanis D., Izurieta C., Codabux Z., Deo A., Williams B., “The Correspondence between Software Quality Models and Technical Debt Estimation Approaches,” IEEE ACM MTD 2014 6th International Workshop on Managing Technical Debt. In association with the 30th  International Conference on Software Maintenance and Evolution, ICSME, Victoria, British Columbia, Canada, September 30, 2014.

Case Studies:

Griffith I., Izurieta C., Taffahi H., Claudio D., “A Simulation Study of Practical Methods for Technical Debt Management in Agile Software Development,” Winter Simulation Conference WSC 2014, Savannah, GA, December 7-10, 2014.

Antonio Martini, Lars Pareto, Jan Bosch:
A multiple case study on the inter-group interaction speed in large, embedded software companies employing agile. Journal of Software: Evolution and Process 28(1): 4-26 (2016)
http://www.sciencedirect.com/science/article/pii/S0950584915001287

Ariadi Nugroho, Joost Visser, and Tobias Kuipers. 2011. An empirical model of technical debt and interest. In Proceedings of the 2nd Workshop on Managing Technical Debt (MTD ’11). ACM, New York, NY, USA, 1-8.

Does principal really exist in technical debt ?

Ipek Ozkaya
Feb 5, 2016

The inability to conceptually and quantitatively clarify how to map financial concepts captured powerfully within the financial debt metaphor to software hinders our progress in research and application of technical debt in practice. In particular, there is increasing conceptual mismatches in articulating and calculating interest. Consequently, the tendency to equate any code quality issue that a static analysis tool may find to the principal or interest of technical debt in the software realm puts us on the wrong path.

In this note I will map interest and principal to their economic foundations and argue that a fine tuned quantification of technical debt requires defining their counterparts, in some cases completely dispensing them. Let us start by recalling the financial definitions:

Debt – in its simplest form, a financial debt is an obligation to repay an amount you owe. Repaying the amount means repaying the principal and the accrued interest.

Principal – initial amount borrowed

Interest – money paid at a rate or as a fixed amount for the use of money lent

Interest rate – the percentage of the principal to be paid, often regularly until the debt is paid back in full, as compensation for the loss of the initial borrowed amount value

Variable interest rate — an interest rate that fluctuates over time

Period – duration that the debt is paid back, hence interest is calculated against.

Steve McConnell’s technical debt definition has been the one that stuck with the community; a design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now. Cost more is a proxy for the interest. What we are borrowing, the thing that we have an obligation to repay, is the construction approach often referred to as a short-cut. We are committing to “pay that back” by calling that approach “technical debt”.

In the literature there are two classes of technical debt quantification, repayment strategies if you will, exist.

Lump sum repayment – Lump sum repayment typically takes a code quality lens. This approach looks at the entire software and equates all the code quality violation found as technical debt principal and interest. While there is acknowledgement that all issues found are not of equal importance, the resulting lump sum quantification does not provide enough context for project managers or team members to decide how to respond.

Variable repayment – Variable repayment focuses on the rework, accumulated rework as often referred to. What is quantified for recognizing the accumulated rework are measures related to maintainability, such as defect proneness, time to add new issues in addition to redoing the initial design approach. This approach differs from the lump sum repayment as it scopes the conditions of the debt. The ideal repayment strategy here is doing the rework as soon as possible, i.e. pay back the principal, to avoid interest, i.e. additional defects. This approach assumes that the cost of required changes can be bucketed cleanly as rework of the original design + eliminating the side effects.

In financial debt, the consequences of just paying the interest is never getting out of debt. Principal in software has a very short span, it is only applicable during decision making. I argue that we never pay back the actual principal in software, we only deal with reducing or eliminating interest and principal gets factored into that activity. One-to-one mapping of the principal is often not feasible. Software changes, but not in the form of a backwards looking lens as in financial debt where when we borrow 5K we pay back 5K + the interest. Consider the following example, in a recent project that we studied the development team did not understand the requirements well enough and picked a UI Framework that was not best suited for the project. After several months of development it finally came to a state where they had to spend more and more of their time trying to figure out the root causes of the odd behavior of the UI framework that they did not foresee. Driven by this problem they decided to step back and rearchitect the UI framework, but since a significant amount of functionality had already been built they also had further knowledge about their expectations from a UI framework and picked a solution that they would not have gone with to start with in the first place. They definitely had technical debt and significant rework, but there is probably not much value in capturing it as principal + interest when they are in a position to make the rearchitecting decision. Given a one-to-one mapping does not exist, philosophically arguing principal quantification and articulation sets us back.

I argue that the goal of any effective technical debt management strategy is to reduce or eliminate the variable interest of technical debt, not pay back principal. Consequently, interest takes three forms and different quantification approaches are required for each:
1) Visible interest: interest already accumulated and currently visible
You have some code clones: a developer did some “cut-and-paste-and-modify” of a fragment of code, about 20 times throughout the system. But the software works fine. Identified classes that are highly coupled through a code analysis tool is also a form of potential visible interest.

2) Probabilistic interest: possible future interest (accumulation) that builds-up if the issue is not fixed.
In our example above, the UI framework has unanticipated behavior, but you have implemented it already and made it work one way or another. The question is what is the likelihood that as the system continues to evolve this behavior will cause other issues and will the team be able to continue development around it.

3) Sweeping interest: the design related added cost as a result of remediation (.e.g. removing additional patching)
If we decide to change the design we need to change the code clones in all of the 20 places (as articulated in #1 above) each of which may require additional design fixes, and create a utility to call the code from a single location. Or in the example in #2, if we decide to change the UI framework we need to ensure that we not only cleanly introduce the new framework and but ensure not to leave any of the workarounds related to fixing the odd behavior.

Cost of remediation does take into account principal. But since we have already established that it is most likely not the same work as the initial decision cost of remediation comes down to the following:

Cost of remediation = work on (sweeping interest + visible interest + new design)

Let us also take a look at the period, duration the debt is paid back and during which interest accumulates. In finance the period of the debt has an influence on the accumulated interest. The longer the period the higher the interest. In technical debt this too is probabilistic, the lower the probability of the changes executing the debt area, the lower the impact of the period.

Not all technical debt accumulates all of the three interests. By articulating technical debt in terms of these three kinds of interests as a starting point concrete payback and quantification strategies can be articulated. For example in the examples above, the visible interest is low because the software works, so the developers should evaluate the probabilistic interest. If for example they have only occasionally new features requiring changes in the cloned code, and when that occurs it is in one of the areas only they may articulate the probabilistic interest to be low, hence decide postpone remediation. In a different scenario, if the developers find that new changes push them to create new clones of the same code, adding to both visible and probabilistic interest, remediation may need to be done.

Solely focusing on interest and its probabilistic and deterministic forms can allow us to better take advantage of existing tools and develop an economic model for technical debt quantification and communication.

How to structure your blog contributions?

This blog is for the preparation of the Dagstuhl seminar on Technical debt. To contribute to the blog, you will need to have a WordPress login (You do not need to create a new one, if you have one), and communicate to the admin of the site (Philippe Kruchten) admin@mtd2016dagstuhl.org the email address associated to your WordPress ID.

We will use this blog to collect contributions of the workshop participants and share any relevant background material. We hope a blog will help us all to share relevant information easier, provide a repository while allowing for better collaboration and exchange of ideas while we all prepare for the workshop. All workshop participants are asked to prepare one or more narratives (outlining an idea, an experience, a question, a challenge, or an insight) and post them here as blog entries. Workshop participants will be able to see the contributors as well as discuss the submissions using the WordPress blog discussion features. Please structure your blog pots to address the following questions:

What is a key practical challenge, research question, insight, experience, or idea that requires collective attention by the managing technical debt community?
Please focus each blog entry around one idea. If you see multiple key challenges/research questions you can submit multiple entries. The workshop organizers will go over all the entries and organize them around key themes in preparation for the workshop.

Have you done any work to address the question?
This is intended to be a short summary, with possibly pointers to relevant resources.

Have others done any relevant work to address the question?
This is intended to be a short summary, with possibly pointers to relevant resources.

What needs to be done to make progress? How do we define success and completion ?
This will help us get feedback from each other to focus on most relevant aspects as well as define a roadmap.

Please keep in mind that these blog posts are not intended to be research papers, but a lean way of sharing ideas among about 30 people. The blog is private, open to workshop participants only, at least until the completion of the workshop. All participants will be able to contribute and edit their own contributions and provide comments and discussion on all of the posts. Do not exceed 1000 words. Remember if needed you can provide pointers to relevant reading material, but try to be selective. The blogs are also not intended to be literature reviews. There are already several good literature reviews published.

And most importantly, let us have fun with it!