10 Years of Tech Debt Research

A look at the past, present, and future of tech debt.

This is the latest issue of my newsletter. Each week I cover research, opinion, or practice in the field of developer productivity and experience.

---

This week I read 10 Years of Technical Debt Research and Practice: Past, Present, and Future by Marcus Ciolkowski, Valentina Lenarduzzi, and Antonio Martini. This paper distills over a decades worth of research on technical debt and puts forth ideas about where future research should head.

My summary of the paper 

The past: Introducing the term

Ward Cunningham invented the “technical debt” metaphor in 1992 as a way to explain to management, who understood finance, why working in an iterative approach instead of a waterfall model increased project speed. Expanding on the metaphor, technical debt “interest” would come in many forms: lower maintainability, performance, operability, and usability. “Paying back” technical debt meant software needs would need to be refactored to reflect knowledge gained during the course of the project.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. — Ward Cunningham, The WyCash Portfolio Management System, 1992

This original understanding of technical debt has been adapted in the years since it was introduced. Some authors have presented a more narrow view of technical debt, using the term as a way to refer to deficiencies in internal quality. The idea was also introduced that technical debt is the act of taking shortcuts by writing bad code to speed up development, which is an idea that Cunningham explicitly opposed. Today, the meaning has been further expanded to include any code a developer dislikes.

Technical debt has gained significant traction amongst researchers and practitioners, especially in the past ten years and even more so in the past five. All in all, it has been a useful tool: the metaphor has paved the way for business and technical people to discuss software quality. 

The present: A better understanding

As publications about the topic have multiplied, we now have a better understanding of the costs of technical debt. For instance, one key finding is that an estimated 30% of development resources are wasted because of technical debt. Additionally, technical debt negatively impacts the morale of developers, who often refer to high levels of it as “wading through mud.”

We also know that software companies are still immature at managing technical debt. One key issue is that there is a desire to use tools that detect technical debt within code, but existing tools lack accuracy and are not usable in practice. 

The future: Addressing open issues 

According to the authors of this paper, we can expect to see more works investigating the impact technical debt has on internal qualities such as faultiness, reliability, and code maintainability. However, they note that “the current focus on internal qualities is too restrictive,” and suggest that researchers should explore other ways tech debt impacts teams, pointing to a paper on how tech debt impacts morale as an example. Researchers should also look to other sources of data for identifying technical debt. And finally, researchers should explore the relationship between various aspects and tech debt, such as organizational structures and social contexts. 

We can also expect to see more research into how to plan for tech debt and prioritize paying it back. “After all, the whole purpose of the research in this area is to understand when technical debt should be taken up, when it should be kept, and when it should be avoided or repaid.” A few approaches have been proposed, however steps toward a more holistic approach are needed. 

The authors conclude with this: “We believe it will take several more years to bring technical debt management from adolescence to adulthood.” 

Final thoughts

Given its impact on developer productivity, I frequently summarize papers on tech debt. This paper distilled findings from research both familiar and new to me, and I appreciated that it challenged researchers to expand their view surrounding this topic. With that, I’ll add my recommendations for practitioners to better communicate and manage tech debt moving forward:  

1. Move away from using the phrase “technical debt” 

Technical debt is a metaphor, it’s not “the thing.” It’s a tool to communicate the need to allocate time towards work that does not directly result in new features, and it has been successful in doing so. However, because the term has become more widespread and many non-technical stakeholders now have adverse reactions when they hear “technical debt," I have to agree with Kent Beck that it is time to move away from using the phrase. 

“Technical debt” is widespread enough that there is backlash to it. “That’s just an excuse for programmers to mess around.” While a useful metaphor for communicating with some audiences, technical debt may have outlived its usefulness for communicating with non-technical audiences… It’s not what you say, it’s what they hear. Many business folks hear “mistakes”, “delay”, and “no progress” when they hear “technical debt.” — Kent Beck, “Friction” Over “Debt”

In his article, Beck proposes the word “friction” as a replacement. I prefer this term as well, partly because it drops the baggage associated with tech debt and also because, as Beck says, it “implies we are continuing to move forward.”

2. Define what the problem really is

While useful for communicating with executives, “tech debt” and “friction” are too high-level to be useful when communicating with teams. Get clear on what the problem really is. Laura Tacho and Thoughtworks have written about this, so use their resources as a helpful starting point. Once we know what the problems actually are, we can better manage them.

---

That’s it for this week! Share your thoughts and feedback anytime by replying to this email.  

If this email was forwarded to you, subscribe here so you don’t miss any future posts: 

-Abi