Technical Debt: Lessons from 10 Years of Change

Focussing on tech debt can feel like a new thing. After all, software has evolved to become far more efficient.

But a decade-old research paper from researchers at Carnegie Mellon University and the University of British Columbia shows that it's nothing new at all. In fact, in 2022, this paper won the Most Influential Paper award. This is awarded to a paper from 10 years ago that the IEEE judge to have had the greatest influence on software architecture research and practice since its original publication.

The paper is titled "In search of a metric for managing architectural technical debt." 

Don't worry if you don't have a paid IEEE membership. You can also read the full paper here in all its glory.

Managing technical debt in simulated disaster response 

The paper offers a foundation for incurring and managing technical debt in a deliberate, intentional way. 

The researchers use software architecture to identify and monitor architectural technical debt so that developers can make effective refactoring decisions. 

Their focus is the Disaster Response Network-Enabled Platform (DRNEP). 

The Disaster Response Network-Enabled Platform (DRNEP) is a system that integrates a set of independently developed infrastructure and disaster simulators. DRNEP gives governments a way to prepare and respond to large disasters like earthquakes, tsunamis, flooding, or hurricanes. It simulates disasters, and the impact on critical infrastructure like the power grid, water, transport and communications. It does this by bringing together infrastructure and disaster simulators from a set of independent sources. That means governments can prepare a strategy.

What's the challenge of technical debt in disaster relief planning? 

Projects like the DRNEP are large-scale long-term endeavours. They use different simulators developed by independent research groups over several years to model the impact of different environmental changes or human-made decisions.

But all of this simulation work needs to be integrated into the DRNEP. The technical debt research authors wanted to see which process would be better – quick and dirty or slow and structural. 

The choice of two paths

The researchers looked in detail at two paths over a three-release cycle. (The original paper has all the working mapped out in graphs if that's your thing, feel free to dig in deep there). In short:

1. The easy path: Make ad hoc adaptors and translators between the concepts and data of the simulator and DRNEP. 
2. The ambitious path: Define a standard architecture with mechanisms to achieve a more systematic integration.

What did the research find that can help us today? 

‍

A slower, planned approach can mean less technical debt 

Researchers found that the second path looks more costly but paid off rapidly with subsequent releases, as more simulators are integrated into DRNEP. 

What first appears most valuable is not necessarily the case in later iterations

Until release 2, path #1 delivers more value for the cost. But a switch starts with release 3.

Path #1 starts creating debt right after the first release and incurs 18% more cost than path #2 on release 3.

By the time we’re at release 4? Bad news… The quick and dirty approach has made it a whopping 55% more expensive than the carefully planned approach.

Quick and dirty delivery has its merit

The researchers note that both paths have their merit depending on the age of a project. For example, Path #1 could suit a new system, such as one in a business value exploration phase. During this phase, getting some functionality out of the door and testing it in the field is critical. 

Active monitoring could have reduced the problem of technical debt

The researchers find that by the time the costs of technical debt begin to show, especially in Path #1, it's too late. Actively monitoring and making these decisions visible could have reduced or even prevented technical debt. 

But back in 2012, tech debt-related tools were in their infancy. JetBrains released IntelliJ IDEA in 2000, and SonarQube was initially released in 2006. Stepsize started in 2015, and Visual studio intellicode wasn't made by Microsoft until 2018. 

Today, we can use a tool like Stepsize to track technical debt. It’ll allow you to quickly report technical issues in your code without leaving your editor.

Conclusion: the quickest path is not always the best

‍

‍

While this research is hardly recent, it shows us that the problem of technical debt is nothing new. It also reveals that technical debt can be more evident in scrappier projects. What may first appear efficient can leave you in a world of pain in later versions, designs, or updates of your product. 

Fighting and preventing technical debt is crucial to managing it effectively. Here are 3 of the best proven methods for doing this.

Continuous tracking of technical debt is the only way to understand and manage it. Make sure you track your technical debt with Stepsize. It’ll allow you to quickly report technical issues in your code without leaving your editor (get started here). More advanced features can help you monitor which issues get resolved, which issues linger, and more.

The moral of this thought experiment? Make sure to have a process that makes it easy to accumulate tech debt strategically, and track and resolve technical debt continuously.

‍