Manage Technical Debt With Augmented Code Analysis

Many organizations spend significant parts of their development budgets in parts of the code that are more expensive to extend and maintain than they have to be. 

That’s why a behavioral code analysis tool like CodeScene identifies and prioritizes technical debt based on how you, as an organization, works with the code. This is a powerful first step, but like all code analysis tools, a crucial component is missing: your context.

Context matters. What features do you plan to implement next and what parts of the system will they affect? How much can you spend on re-work and improvements? And when is a piece of code good enough? That’s why CodeScene introduces the concept of augmented code analysis that lets you specify contextual information, which is then processed as part of the analysis. This means that the analyses are aware of your goals and can measure the progress towards them. Let’s see how this technique lets us manage technical debt.

Managing Technical Debt Is About Trade-Offs

There’s always a trade-off between improving existing code versus adding new features. Improvements cost time and money, and when we refactor or even re-design a piece of code we are placing a bet that our investment will pay-off in the future. As such, larger and more significant improvements have to be balanced against the short-term goals of the product. Maybe it’s just more important to get that critical feature out than to clean-up those nested if-statements that are so hard to understand?

Over the years I’ve seen several products canceled. Not due to lack of code quality, but due to lack of delivery. Fascinatingly enough, there’s a lot of horrendous code out there that keeps making money that funds entire organizations, sometimes for decades. That doesn’t mean we should accept code with severe quality issues. It just means that we need to prioritize what and when we invest in larger improvements, and we need to do it based on data that can assess the likely return on investment.

CodeScene provides those priorities through its hotspot analysis. A hotspot is code that the developers have to work with frequently. If that code is hard to understand and extend, your development is likely to be more expensive than it has to. Let’s look at an example from the Linux Kernel:

CodeScene detects a growing problem that affects the development efficiency.

In the preceding figure, we see that the hotspot x86.c, a virtual machine driver in Linux, has degraded in quality. CodeScene detects this through its code biomarkers that scores each hotspot from A to E where A is the best and E indicates code with severe potential problems. In this case we note that the x86.c has degraded from a C to a D. These are bad news since that degradation is very likely to affect us – it’s a hotspot after all, which means it’s a piece of code we will most likely have to continue to work on. And now all that future work is going to be more expensive.

Once CodeScene has detected a potential problem, we – as an organization – have to investigate it in more depth. CodeScene guides your investigation through its virtual code review and X-Ray analysis. Once we decide to invest in specific improvements to our hotspot, we tell CodeScene about it:

Add contextual information and planned steps through intelligent notes that CodeScene will supervise.

The contextual information and plans that you add are intelligent notes, which means that CodeScene will feed that information into its analysis and inform you about the progress and possible warnings. CodeScene supports three different categories for its intelligent notes:

1. Planned Refactoring: Chose this category when you have investigated the code, perhaps with CodeScene’s virtual code reviewer or its X-Ray analysis and see the need to pay-off some technical debt in the short term.
2. Supervise: Chose this category for code that might be acceptable for now, but that shouldn’t grow worse.
3. No Problem: Chose this category to let CodeScene know that you don’t consider the code a problem. Perhaps you plan a replacement of the hotspot code, or the code is good enough for your purposes.

In this case, with the Linux hotspot, we specified that we wanted a Planned Refactoring in order to reverse the negative trend of the code. Given that input, CodeScene will supervise the evolution of the hotspot and keep us in the loop. Here’s an example on such possible future outcomes:

CodeScene delivers continuous feedback and supervises your planned refactorings.

This way, a quick glance at your CodeScene dashboard will immediately show you the measurable progress towards paying off the identified technical debt. Since CodeScene now knows your context, the tool can also inform you about failures to meet the planned refactoring goals.

Let CodeScene Supervise Your Hotspots

Like we discussed earlier, you might chose a different trade-off and wait with a larger refactoring; Perhaps you know that the particular area of the code is feature complete, or maybe you conclude that the code is acceptable after all. In that case you want to ensure that it stays that way. You do that by delegating the responsibility of supervising such hotspots to CodeScene:

CodeScene acts as an extra team member that constantly supervises code at risk to grow worse.

With the hotspot supervision, you ensure that no new technical debt is taken on without you getting an alert from CodeScene.

Ignore Expected Hotspots With Automated Supervision

False positives show up every now and then in all automated code analyses. CodeScene is no exception. For example, there might be this gigantic hotspot file that is worked on all the time but just contains common declarations like enumerations or constants. While that might not be an award winning design, such code is usually not a primary driver of excess development costs. Or maybe you do identify a problematic hotspot but know – again: contextual information – that this code will be replaced by a new library next month. In that case you can make the decision to ask CodeScene to ignore a specific hotspot, and it won’t show up as prioritized technical debt in your next analysis.

However, there’s always a danger of suppressing warning signs or problems. Hence, CodeScene keeps analyzing ignored hotspots in the background even if you explicitly marked them as no problem. Should something dramatical happen to that code, let’s say five nested if-statements or a bunch of other coding sins are committed, CodeScene will point your attention to it:

In the background, CodeScene continues to scan hotspots marked as No Problem to ensure they stay that way.

The preceding figure is CodeScene’s way of pointing your attention to what looks like a growing problem. CodeScene will also issue a warning on the project’s dashboard.

View Your Technical Debt At A Glance

By augmenting your hotspots with contextual information and refactoring plans, CodeScene lets you view your prioritized hotspots in the context of your goals and situation:

View your hotspots in context of your decisions and plans.

Using CodeScene’s dashboard, you can even have the data updated in real-time as the code is being developed. That way, the whole organization gets to share a common view of what the state of the code actually looks like and how it evolves. That’s the first step towards true improvements.

Explore More and try CodeScene

CodeScene’s augmented code analysis introduces intelligent notes that let you manage technical debt by keeping your contextual knowledge and plans integrated with the codebase. That is, everything is stored directly in the CodeScene tool rather than in your head. Combined with CodeScene’s existing analyses, this gives you a complete framework for managing technical debt from detection to action. You will never miss a hotspot again.