A simple conceptual model of technical debt

Ph. Kruchten, I. Ozkaya, R. Nord
January 2015

This document describe a simple conceptual model of technical debt in software-intensive systems, and its relationship with related concepts.

A simple UML model of technical debt

A simple UML model of technical debt

The technical debt associated to a software-intensive system is composed of a set of technical debt items (or TD items) and this technical debt is one of the many concerns associated with the system.
Technical debt items have both causes and consequences. The causes of technical debt can be a process, a decision, an action (or lack of action) or an event that triggers the existence of that debt item; schedule pressure, unavailability of a key person, lack of information about a technical feature, etc.
The consequences of a technical debt items are many: it ha effect on the value of the system, on the costs, past present and future, directly or through schedule or future loss of quality. The business objectives of the sponsoring organization developing or maintaining the software system are affected in two ways: either through a delay or loss of quality of some of the features of the system, or difficulties in maintaining the system operational (continuance).
A technical debt item is associated with one or more concrete, tangible artifacts of the software development process, primarily the code, but also to a certain extent the documentation, the known defects, and the tests associated with the system.
To keep with the financial metaphor, the cost impact of technical debt can be seen as composed of a principal and interests. The principal is the cost savings gained by taking some initial approach or shortcut in development (the initial principal, often the initial benefit), or the cost that it would take now to develop a different or better solution (the current principal).
The interest are costs that add up as time passes by. There are recurring interests: additional cost incurred by the project in the presence of technical debt, due to reduced velocity (or productivity), induced defects, and loss of quality (maintainability ifs affected). And there are also accruing interests: the additional cost of the developing new software depending on “not quite right code” (evolvability is affected).

For further reading
The notion of concerns associated with a system comes from ISO 42010-2015. Li, Liang and Avgeriou (2014) have proposed an alternative conceptual model, where they separate benefits and costs of a technical debt item.

Li, Z., Liang, P., & Avgeriou, P. (2014). Architectural Debt Management in Value-Oriented Architecting. In I. Mistrik, R. Bahsoon, R. Kazman, & Y. Zhang (Eds.), Economics-Driven Software Architecture, (pp. 183-204). Amsterdam: Elsevier.

This document in PDF:  Conceptual model of TD.

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!