Technical Debt: Visualizations, Priorities, and Use Cases

Not all code is equally important. CodeScene’s strength is its ability to prioritize technical debt based on how your team interacts with the code — not just what the code looks like.

CodeScene combines its Code Health metrics with development Hotspots to pinpoint the parts of your system where poor code quality slows down your team, your Technical Debt Friction. This is the debt that matters most. It’s also where refactoring delivers the biggest impact. (See CodeScene’s Framework for Managing Technical Debt: an introduction).

• Prioritizes based on how you work with the code, not just the code itself. This is a crucial difference from traditional static analysis tools: some technical debt may be neither urgent nor impactful. Fixing that debt could be wasteful. Instead, CodeScene understands how your codebase evolves and prioritizes based on the organizational impact.

• Limits recommendations to what’s relevant and actionable. With CodeScene, you never get a list of 5.000 items to fix. Instead, you get a view of the most impactful technical debt. This allows you to balance improvements vs new features.

• Automatically adapts to changing priorities and focus. Changing focus in your product development means that new hotspots emerge. CodeScene adapts automatically, updating its refactoring recommendations to what’s important for you now.

CodeScene presents its technical debt analysis as a four step process:

1. Code Health: Is the code easy to understand and evolve?

2. Hotspots: Where is the development activity?

3. Technical Debt Friction: What parts are causing friction between people and code?

4. Refactoring Targets: Pinpoint the technical debt with highest interest.

This document guides you through all four views.

Visualize Code Health: Is the code easy to understand and evolve?

CodeScene calculates the code health of all the files in your code base.

Fig. 28 View the code health of each file in your codebase.

Viewing the full code health perspective also highlights the importance of priorities. Even if a module has a lower health, that does not mean that it requires attention, nor immediate action. Code quality has to be put into perspective, which is something CodeScene’s other analyses do. Let’s look at some examples.

Fig. 29 CodeScene prioritizes the most relevant code health issues automatically.

Hotspots: Where is the development activity?

Most development activity tends to be located in relatively few modules`. A Hotspot analysis helps you identify those modules where you spend most of your development time.

Combined with CodeScene’s code health perspective, you can quickly prioritize technical debt or other code quality issues:

• Low code health in a development hotspots is expensive. Prioritize improvements here.

• Low code health in stable parts of the codebase, i.e. non-hotspots, has lower priority.

Hotspots are an excellent starting point if you want to find your productivity bottlenecks in code.

A large codebase will contain many different hotspots. Often, there will also be clusters of hotspots. Clusters may indicate that an entire component or package is undergoing heavy changes.

The visualizations on theis page are available from the analysis menu at “Code > Technical Debt” or by clicking on “View Hotspots” on the “Code Health” tab of the main analysis dashboard.

Know how to use Hotspots

The Hotspots map in CodeScene is a flexible analytic tool that can be adapted to your specific needs. This kind of visualization is used in several other places inside CodeScene, so it’s worth learning how to use these maps, which we refer to sometimes as System Maps.

A Hotspot Map has several use cases and also serves multiple audiences like developers and testers:

• Developers use hotspots to identify maintenance problems. Complicated code that we have to work with often is no fun. The hotspots give you information on where those parts are. Use that information to prioritize re-designs.

• Hotspots points to code review candidates. At CodeScene we’re big fans of code reviews. Code reviews are also an expensive and manual process so we want to make sure it’s time well invested. In this case, use the hotspots map to identify your code review candidates.

• Hotspots are input to exploratory tests. A Hotspot Map is an excellent way for a skilled tester to identify parts of the codebase that seem unstable with lots of development activity. Use that information to select your starting points and focus areas for exploratory tests.

Navigate the CodeScene Hotspot Map

The visualization is interactive and hierarchical; Each large circle represents a folder in your codebase. That means you can zoom in and out to the level of detail you’re interested in To zoom in and out, you

• click on a directory or file circle;

• scroll with your mouse wheel;

• use pinch-to-zoom gestures;

• click on the breadcrumbs at the bottom of the view

• click on subfolders in the “Content” tab of the node details in the sidebar.

You can also “grab” the system map with your cursor to pan left, right, up or down.

The most common interaction is to click on a Hotspot to get more details about it as illustrated in Fig. 30.

Fig. 30 Click on a Hotspot to access the context menu.

Use the context menu to access the code for inspection, run CodeScene’s X-Ray (see X-Ray), investigate trends (see Complexity Trends) and Change Coupling.

Technical Debt Friction: What parts are causing friction between people and code?

Fig. 31 CodeScene visualizes where technical debt is causing friction for developers.

The Technical Debt Friction view helps you answer the critical question: Where is productivity hurt the most in your codebase? This view builds on top of CodeScene’s Code Health and Hotspot analyses to identify the places where technical debt has the largest organizational impact. Unlike traditional static analysis tools that only look at the code itself, CodeScene also considers how you work with the code - how often it changes, who touches it, and how it evolves over time. Some technical debt may exist without being urgent or impactful. Fixing that debt could be wasteful. Instead, Technical Debt Friction highlights the areas where unhealthy code intersects with high development activity, making it clear where remediation efforts deliver the biggest payoff.

Tip: Filter Technical Debt Friction by Team and/or Developer

It’s common to have multiple development teams committing to the same codebase. The interactive visualization lets you filter the view by team or authors. That way, you limit the information to what’s relevant for your team:

Focus on your Refactoring Targets

To prioritize hotspots, CodeScene intersects the Code Health scores with the hotspotness of each file. That way, you get clear priorities on which files – and/or modules – that has the largest positive impact when refactored: high-friction files.

Fig. 32 CodeScene prioritizes the Hotspots in your code.

Remediating the Code Health issues in the red refactoring targets is likely to quickly produce a real return on your refactoring investment.

Local refactoring opportunities identify technical debt remediations on an Architectural Component level which can be helpful for teams owning specific parts of a larger project.

Move beyond files: Visualize implicit dependencies with change coupling

CodeScene identifies files that tend to change together. Change coupling indicates a relationship of some kind between files. These relationships are visible in the hotspot map when you hover your cursor over a file with coupling.

Fig. 33 Hover over a file to see its connections to other files.

Interpreting change coupling depends on the context. Widespread change coupling in a codebase can indicate tightly coupled logic and possible architectural issues, like in this example:

Fig. 34 A tightly coupled codebase.

Making a change in one of these files often means making changes to the others as well. It’s easy to imagine how these interdependencies complicate things for developers who need to fix bugs or add features in any of those files. In this case, change coupling is problematic.

Change coupling can also be positive, when it occurs between files that have a good reason for changing together. This is the case with test code, like in this example:

Fig. 35 Change coupling between a file and its tests.

There is coupling between SyntheticEvent.js and its test file: SyntheticEvent-test.js. This is a positive sign that suggests that the tests are being updated as the file evolves.

Hovering over files with change coupling causes the coupling lines to appear for as long as you hover. This can be inconvenient if you want to zoom out or shift the viewport to see the rest of the map. In that case, clicking will “lock” the change coupling visualization, leaving you free to continue to interact with the system map.

There are two other consequences when this happens:

1. When one file is “locked”, hovering over other files still works. In this case, the coupling lines are white, in order to differentiate them from the first set of couplings.

2. When a file with change coupling is selected, a third tab will appear in the sidebar, providing detailed information about the different change couplings.

Fig. 36 With a file locked, the change coupling sidebar appears

The “Degree” indicates the strength of the coupling. (For more information about how the couplings are calculated, see Change Coupling: Visualize Logical Dependencies. ) The “Coupling Source” identifies how CodeScene identified the change coupling. The system maps use two possible sources:

• Commits: files are modified as part of the same commit;

• Project management tool tickets: files are modified as part of the same ticket.

In general, commit-level change coupling indicates a stronger level of coupling. However, changes made in separate repositories cannot be part of the same commit, so we then turn to ticket-level change coupling, which is not perhaps as “strong” but has the advantage of seeing couplings that would otherwise remain invisible.

For more information, see Change Coupling: Visualize Logical Dependencies. The change coupling data used in the hotspot map is calculated the same way as for the other change coupling graphs, with two exceptions:

• Filters are not applied. This allows “positive” coupling, like for tests, to be visible.

• The coupling threshold is fixed at 20% which will generally be lower than the automatic default in the change coupling graph.