SPLASH workshop on Technical Debt - position paper


Dennis Mancl - Alcatel-Lucent
October 2013

Technical debt is something that both software developers and corporate leaders need to be aware of. But just knowing the term "technical debt" is not enough -- we all need to have a deeper understanding of our actions, habits, and attitudes relating to reusing existing code in the process of software product development.

There has long been an effort to reuse individual functions, data models, libraries, and software components. Software reuse is an essential part of building large systems for two reasons. First, by reusing existing modules from another product, developers save a lot of design, coding, and testing effort. Second, by reusing existing modules from one release of a product to the next, the behavior of the product will be much more consistent with the behavior that customers expect.

Technical debt, which is the increased accidental complexity introduced into a software product as it evolves, has many sources. Two of these sources are special cases of the technical debt metaphor:

In the first case, the reuse has a "reuse tax" -- extra unplanned work that needs to be added to the work plan.

In the second case, the reuse has a "hacking penalty" -- extra costs that are due to making undisciplined changes to the code base of a long-lived product.

What do you think? Are there any other good metaphors for the sources of technical debt?