Garbage Collect Your Technical Debt

Techniques for controlling tech debt. Choose a philosophy for managing tech debt.

This week I read Garbage Collect Your Technical Debt, an article by Michael Keeling (author of Design It!), Timothy J. Halloran (Google), and George Fairbanks (author of Just Enough Software). Here, the authors describe techniques for controlling tech debt. 

My summary of the article

The authors open the article by comparing tech debt to garbage collection: "running a program creates garbage, which is memory that’s been allocated but is unused. Garbage creation is unavoidable, so we must occasionally pause to collect garbage.” Similarly, creating tech debt is unavoidable, so we must occasionally pause to refactor the code. 

Teams can control tech debt in two ways: by cleaning up existing tech debt, and by avoiding the creation of tech debt. 

Technique: tech debt cleanup 

Teams can control tech debt by cleaning it up after it exists. Small problems can be refactored in minutes, but bigger problems can take days, weeks, or months to clean up. Teams tend to clean up small problems but delay cleaning up big problems because the activity steals time from feature building. 

Technique: tech debt avoidance

Teams can also control tech debt by creating less of it. This is an iterative process: when asked to add a new feature, a team considers how well the current design can accommodate that feature. If the design is already suitable, they add the feature. But if the design is unsuitable, they update the design first, then add the feature. 

The authors note that some tech debt is unavoidable, so effort towards cleanup is still recommended. 

Selecting an approach

Expanding on the two techniques, there are four approaches teams can choose from to keep tech debt low:

1. None. Teams may choose to ignore tech debt. Sometimes this approach makes sense for the business: consider commercial computer games, where developers know they will start with a fresh codebase the next game. 

2. Reactive. This approach uses only tech debt clean up. “This is what most teams do today.” The authors point out that “it’s easier to recognize problems than it is to avoid them,” so this approach may make sense when developers have limited design skills. 

3. Proactive. This approach focuses only on avoiding tech debt, and is uncommon today. Completely avoiding tech debt is ideal, however it is unrealistic. Teams that start with a proactive approach may switch to a balanced approach. 

4. Balanced. This approach includes both cleanup and avoidance, and is considered the most pragmatic of the four.

Ultimately, tech debt might be inevitable, but it can be minimized by choosing a suitable approach. 

Final thoughts

I’ve heard some managers say tech debt is uncontrollable and others say it is the result of cutting corners. This article presents a more clear-eyed view of the problem: tech debt is inevitable, it is controllable, and teams can choose a strategy for creating and managing it. We also know from research that technical debt cripples productivity.

What this article does not address is the question of understanding how severe technical debt has become, and then knowing how to communicate that problem to executives. This is another area of debate, but I think the answer is simple: just ask developers how many hours per month get wasted due to tech debt, and then take the average. Show that number to executives to make a case for investing in cleanup.

---

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