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