Escape the Technical-Debt Trap

A hotspot analysis is an efficient strategy to prioritize technical debt. Hotspots gives you a prioritized list of the parts of your codebase where you’re likely to spend most of your time. This means you can take an iterative approach as you drive improvements based on data from how you have worked with the code so far.

Back in Chapter 1, ​Why Technical Debt Isn’t Technical​, we talked about a system that had accumulated 4,000 years of technical debt. It’s a high number, but all too common in legacy codebases. Now we’ve seen that not all technical debt is important. Using hotspots, you can ignore most of those 4,000 years of technical debt and focus on the parts that really matter to your ability to maintain the system. With behavioral code analysis we have that code narrowed down in just a few minutes.

A hotspot analysis also serves multiple audiences. While developers use hotspots to identify maintenance problems and focus code reviews, testers use the same information to select a starting point for exploratory tests. A hotspot analysis is an excellent way for a skilled tester to identify parts of the codebase that seem unstable due to lots of development activity.

Work with Untouchable Code

Sometimes I come across organizations that have decided to avoid touching their worst code. Thus, a hotspot analysis on the recent development activity would fail to highlight the most serious source of technical debt.

This situation is no different from a codebase built around any third-party framework or library—the only distinction is that the third-party code originated from within the same organization. If you’re in a similar situation, you use the hotspot analysis to supervise all the code that does get worked on to ensure it won’t end up sharing a similar fate and become the untouchable code to your next generation of developers.

As we’ll see in Part II, behavioral code analysis is also useful for exploring unknown code. Version-control data lets us travel in time and uncover the patterns of the original developers, which helps us understand the structure of seemingly impenetrable code. It may be hard, but if people managed to decipher the hieroglyphs and sequence the human genome, it should be possible to cast light on a legacy codebase, too. With hotspots as a guide, that work becomes more pleasant.

There’s More to Hotspots

There are several reasons why code grows into hotspots. The most common reason is low cohesion, which means that the hotspot contains several unrelated parts and lacks modularity.^[26] Such hotspots attract many commits because they have too many responsibilities and those responsibilities tend to be central to your domain, which is why they change. This is a problem that gets worse with the scale of the organization. In Chapter 7, ​Beyond Conway’s Law​, you’ll see that there’s a social cost to hotspots, too.

Another fascinating aspect of hotspots is that they tend to stay where they are and remain problematic for years. As an example, I’ve used ControllerActionInvokerTest.cs as a case study in my workshops on hotspot detection for a year now. In that time the code has accumulated even more complexity. Often, that’s because refactoring hotspots is hard and high risk, and we discuss patterns that help us refactor such hotspots in Chapter 4, ​Pay Off Your Technical Debt​. But before that our next chapter explores how we can detect maintenance issues across whole clusters of files.