On Technical Debt: An Interview with Philippe Kruchten
Join the DZone community and get the full member experience.Join For Free
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:
Can a development process generate/facilitate technical debt, if it's not optimized or well-defined?
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
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).
For further reading please see the Nov. 2012 special issue of IEEE Software magazine at: http://www.computer.org/csdl/mags/so/2012/06/mso2012060018.html
About Philippe KRUCHTENPhilippe 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.
Published at DZone with permission of Michael Muller. See the original article here.
Opinions expressed by DZone contributors are their own.