Interview with Philippe KRUCHTEN on technical debt

Let’s continue our serie of interviews with people who had and continue having major influence on the definition of technical debt and its implementation in software development projects. Philippe KRUCHTEN, software engineering professor at UBC, who directed the development of the RUP (Rational Unified Process), explains his vision of technical debt and how to manage it, in order to take right decisions at the right time.

What would be the best definition you could give to explain technical debt?

Technical debt started as a simple, nice metaphor—”not quite right code” which we postpone making it right (Ward Cunningham, 1992)— but various people have used the metaphor of technical “debt” to describe many other kinds of debts or “ills” of software development, encompassing broadly anything that stands in the way of deploying, selling or evolving a software system, anything that adds to the friction that software development endeavors suffer from: test debt, people debt, architectural debt, requirement debt, documentation debt. As a result, the concept of debt becomes somewhat diluted. Is a visible bug or defect really a kind of technical debt? Is a new requirement, a new function or feature not yet implemented requirement debt?

Here is a visualization of the technical debt landscape:

To avoid diluting the term even further, I would restrict “debt” to the elements in the box, that is, the elements not visible outside of the development organization, and relative to the past, not to the future.

If you conceptualize software development as a sequence of changes, then a some point in time (i.e., now), your system is the result of all the changes in the past. Some of these changes are the events that triggered the technical debt you have accumulated (if any). The real issue is then: what changes (improvement, additions, corrections) do we want to do from now on, in the future. Some of them may be reimbursing the debt. This cannot be done in isolation, there is a tension between the various future changes, and we need some common concept to balance between adding new functionality.

Can a development process generate/facilitate technical debt, if it’s not optimized or well-defined?

Developing and delivering very rapidly, with no time to do proper design (BUFD), or to reflect on the longer term (YAGNI), lack of rigour, no systematic (automated) testing, etc. will lead some projects into massive amount of debt very rapidly. But it is all a matter of choice. Maybe time to market is really essential, and the debt is a good investment, as long as you are conscious of it and of its impact on the increased friction the development team will suffer.

Would you recommend systematic actions in development process to control/manage/reduce technical debt? Are code analysis tools a sufficient support for that?

Manage debt explicitly, together with other “things to do”  in a common backlog:

• Green: new features
• Red: defects
• Yellow: architectural elements
• Black: technical debt

Very often a backlog contains oly the green stuff. Yellow stuff is in the minds of a few techies. The red stuff is in a defect database, and the black stuff is nowhere to be found.

Code analysis tools will identify a small part of the black stuff. No, code analysis tools are not sufficient, as often technical debt is not related to code, its intrinsic quality, but to structural or architectural choices, or technological gap. Such tools will not include the debt incurred not by making a wrong choice, originally, but a choice that due to the evolution of the context, merely the passing of time, is now “not quite right” in retrospect. Technical debt may not just be bad or smelly code, but it has become “not quite right” by external events: obsolescence, change of context, rapid commercial success, or advent of new and better technologies.

Is Technical Debt all about source code? What other aspects in software development may have impacts on debt? Architecture, individual skills?

No, architecture plays a significant role and large systems, and some other development activities as well, such as documentation and testing (or lack thereof) which can add significantly to the debt. See the figure above (landscape). Code analysis will only tackle the right side of the box. Professionalism, diligence, dedication, craftsmanship help for sure, but they are not the key determinant.

In your opinion, is it of interest to (try to) measure / compare technical debt of different projects (different people, technologies, companies…)? How can a benchmark on technical debt (such as our project http://techdebt.org) help development teams?

Benchmarking would help. This is what organization like Cast Software, or Software Improvement group, are also trying to do. I am unfamiliar with your tool. But again, the issue is not to identify all the “bad things” in the code, and put a frightening dollar value on it, and announce: this is our debt, let us start to reimburse it. An organization need to look at all the four colours simultaneously, using a single decision processe to define what to do from now on. Refactoring your code furiously may not be the answer. Unlike your mortgage debt, you can actually live with, or walk away from your technical debt.

Technical debt should not be treated in isolation from new functionality or defects, even if we chose to not include the latter two in the definition of “debt”. Expressing all of them in terms of sequences of changes, associated with a cost and a value (over time). These changes are not independent, unfortunately. A common indicator to balance cost and value can be economic or financial tools such as Net Present Value (NPV), or Total Cost of Ownership (TCO), or maybe even Real Option Analysis (ROA).

About Philippe KRUCHTEN

Philippe Kruchten is a professor of software engineering in the department of electrical and computer engineering of the University of British Columbia, in Vancouver, Canada. He joined UBC in 2004 after a 30+ year career in industry, where he worked mostly in with large software-intensive systems design, in the domains of telecommunication, defense, aerospace and transportation. Some of his experience is embodied in the Rational Unified Process (RUP) whose development he directed from 1995 till 2003, when Rational Software was bought by IBM. His current research interests are mostly in software architecture, and in particular architectural decisions and the decision process, as well as software engineering processes. More at : http://philippe.kruchten.com and http://ece.ubc.ca/faculty/philippe-kruchten

Michael MULLER (See other posts)

+10 years experienced Marketing & Communication Manager, specialized in Technology & Innovating companies. Marketing Manager at Tocea. Executive editor at http://dsisionnel.com, a french IT magazine. Creator of http://d8p.it, a cool url shortener. Dad of 2 kids.