The first activity of IASA Israel in the year of 2015 was a full-day workshop by Prof. Philippe Kruchten on “Managing Technical Debt”. The workshop was highly interactive with many questions from the audience. Prof. Kruchten covered the subject of Technical Debt with depth and details, bringing many relevant references and concrete examples from the industry. By the end of the day, the workshop participants, including me, had a much better understanding of the causes and consequences of Technical Debt, as well as some tools and techniques to manage it.

Title: Managing Technical Debt

Abstract

Technical debt is a metaphor to explain a common phenomenon in software development projects: 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 (including increased cost over time).

While the metaphor has gain a lot of success, lately, it is still a rather vague or mysterious concept in many organizations, who are struggling to detect, measure assess, and remedy their technical debt. In this workshop we’ll explore the various facets of technical debt, discover how to characterize it, measure it where possible, and develop strategies for prevention and for remediation.

Presenter Bio

Philippe Kruchten is professor of software engineering at the University of British Columbia in Vancouver, where he retired in 2004 after 30+ years in industry, primarily with Alcatel and Rational Software (now IBM). He developed a software architecture method in the early 1990s, and led the development of the Rational Unified Process from 1996 to 2003. Over the last few years he has led a research effort to better characterize technical debt, in particular intentional, strategic technical debt, at the architectural level. He has organized a series of research workshops on technical debt in Pittsburgh (2010), Honolulu (2012), Zürich (2012) San Francisco (2013), and Victoria (2014), and he has written several papers on the topic, notably with his colleagues at the Software Engineering Institute. He is the co-founder and past chair of Agile Vancouver.

Slides

You can download the slides of a previous presentation.

Motivation

Technical Debt is a metaphor introduced by Ward Cunningham in 1992 to help us think about a problem that is crippling many software endeavours. In his metaphor, doing things the “quick and dirty” way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to dedicate in future development because of this quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor saw little use for many years, but suddenly around 2000 and curiously in parallel with the advent of agile methods (though this may be just coincidental), it met quite some success, especially in the blogosphere and in many software gurus’ sermons. And the phrase started to be used to label all kinds of software ills. Since 2010 it became the subject of more scrutiny and researchers have attempted to better understand the concept, define it, measure it, assess its impact, and propose tools and methods to manage it.

A more recent definition of technical debt which seems to aptly convey the current consensus is given by Steve McConnell: “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 (including increased cost over time).”

While the phrase ‘technical debt’ is used a lot now in industry, is it really a useful concept, that can lead to improvements, or at least a better understanding, of the way we develop software? It is probably a useful rhetorical concept, as pointed out by many to start a dialogue between business people and technical people about schedule pressure, architecture, poor internal quality, release planning. But it is hard to go beyond the rhetoric and get to the point where it leads to actionable, objective, concrete facts, data, techniques or even tools.

One of the issues is that the metaphor has been applied loosely to a vast range of issues or concept, and that the metaphor, like any good metaphor, has its limits and we should understand what these limits are: technical debt in software development is not literally a financial debt, like a mortgage. “…there is a plethora of attention-grabbing pronouncements in cyberspace that have not been evaluated before they were published, often reflecting the authors’ guesses and experience on the subject of Technical Debt.”

This being said, the metaphor proved to be useful, and large organizations have explicitly introduced it in some form of another in their software development process, as a something to identify, value, and take into consideration while planning iterations and releases; one such example is Cisco in Ireland.

This workshop was organized in cooperation with ILTAM. Please share your comments below.