How to Manage Technical Debt with Auto-Supervised Goals

A codebase under active development is a moving target that’s going to change over time. 

This makes it challenging to manage technical debt since it’s virtually impossible to manually track the status of planned improvements while keeping an eye on the rest of the code at the same time. This article introduces the concept of augmented code analysis, a concept that lets you specify your context and intentions in the form of goals. These goals can then be automatically supervised via tooling.

How to manage technical debt and classify hotspots with goals

We recently enabled our goal-oriented workflow in the SaaS version of CodeScene. This workflow lets you manage technical debt by specifying goals on the identified hotspots. A goal records your decision, and is automatically supervised by the tool as a quality gate in Pull Requests. As such, goals fill an important role by adding what’s otherwise always missing from a code analysis: context.

You plan a goal as a response to any identified code health issues. There are several types of goals:

• Planned Refactoring: By specifying a refactoring goal, CodeScene expects you to improve the code. Should the code degrade or – more common – nothing happens, the goal will fail and be reported.

• Supervise: Supervise is our way of saying: yes, we might have some code quality issues here and we can live with them – we just don’t want them to get worse. With a Supervise goal you put a quality bar on an existing code. This is by far the most common goal, and it’s particularly useful in legacy codebases where you want to ensure that no more technical debt is taken on in the application code.

• Critical Code: The Critical Code goal is used for tracking code where failures have dire consequences. The typical example is security critical code such as authentication and authorization logic. A Critical Code goals behaves like Supervise and can fail a build pipeline when violated.

• No Problem: Occasionally, there’s an ongoing initiative to replace some module or decommission it. In that case, you can instruct CodeScene to ignore this hotspot. However, under the hood, the tool continues to watch No Problem hotspots too, and should something dramatic happen to them, then CodeScene will call your attention to it.
  
  

Specify goals on the prioritized hotspots.

No matter what type of goal you specify, CodeScene will track it and report the progress and possible violations. Let’s see how that’s done.

Stop accumulating technical debt with automated supervision of goals

Goals are violated when we fail to meet them. For example, we had the best of intentions to finally refactor that CommonMiscUtilServiceManager.java that has been a problem for years, but something else came up instead. So the refactoring never happened. Or maybe we decided to supervise a module that we expected to be feature complete, but then we had an urgent support call forcing us to sprinkle the business logic with deep if-else chains. No matter why the code got worse.

CodeScene raises alerts when this happens:

CodeScene raises alerts on violated goals.

Goal violations are of course also included in CodeScene’s automated PDF reports, and goal violations can also be pushed to Slack channels if you have that integration. However, when that happens it might already be too late. It’s simply incredibly expensive to reverse a code health decline; the earlier we can catch a potential problem, the better.

This is why CodeScene integrates with Pull Requests. If a goal is violated, the tool detects the violation and informs. Here’s an example from how it looks in GitHub’s Checks API (other integrations like BitBucket, GitLab, and Azure DevOps are available too, of course):

CodeScene's quality gate triggers in a GitHub check on code health decline and goal violations.

As a developer, I can now click on the Details and get an explanation of the violated goal. This is information that forms the basis for conversations: is the feature so important that your organization is prepared to take a code health hit? Or should we get back to the drawing board and reformulate the goal? No matter the decision, you will no longer take on any reckless technical debt unless you actively chose to do so.

Reduce technical debt - towards an actionable code analysis

Many organizations spend significant parts of their development budgets working with code that’s more expensive to extend and maintain than it has to be. With CodeScene, you get situational awareness, clear priorities, and an automated workflow that lets you act on the findings.

And this is key; if you ever used a code analysis tool, then you know that the easy part of any analysis is to find problematic code – there’s no scarcity of that. The hard part is to classify and priorities the findings depending on the impact. Code improvements cost time and money, and we often have to balance improving existing code with the short-term goals of the product (read: more features).

A hotspot analysis helps you prioritize problematic code and manage technical debt by impact. The goal-oriented workflow makes it actionable. We've got a plenty of various blog posts about tech debt. What is technical debt? How do we define it?



Behavioral code analysis for different roles

Check out our white paper to learn more about CodeScene, its use cases, and how they fit into your existing workflows.