How to Tackle Your Backlog of Static Analysis Warnings and Technical Debt

After static analysis tools have been integrated into the everyday workflow of the development team, the next phase is working to reduce the backlog of warnings and technical debt in a project.

In the case of a product under maintenance or in development, there is likely a sizeable backlog to deal with. In the case of a greenfield project, there’s less backlog. However, the recommendations remain the same for each stage of maturity.

The best starting point for dealing with a backlog of warnings is to prioritize and filter the results based on the desired outcome. Using security as an example, it makes sense to prioritize the backlog in terms of security warnings, ranked by criticality.

This is a continuation of the approach used when first introducing static analysis into a project, but now the focus is on the next digestible set of warnings for the team to analyze. This is handled in several ways by Parasoft C/C++test, as we’ll get into below.

What Is Technical Debt and Why It Matters

Technical debt is the cost incurred from delaying essential work or taking shortcuts during software development. This form of debt, like financial debt, accrues interest over time and can become expensive to fix if left unresolved.

Examples of technical debt include:

• Code that’s challenging to maintain or extend
• Outdated dependencies
• Security vulnerabilities

Unfortunately, technical debt is a common issue as software development teams often prioritize delivering features quickly over creating a robust codebase.

Addressing technical debt is crucial for several reasons. It can:

• Impede software teams’ ability to deliver high-quality products.
• Decrease productivity.
• Increase development time.
• Lower customer satisfaction.
• Pose security risks.

Resolving technical debt is essential to building sustainable and maintainable software products that can adapt to changing business and customer needs.

Types of Technical Debt

When it comes to technical debt, there are two broad categories.

1. Intentional
2. Unintentional

Intentional technical debt is incurred when a team consciously cuts corners to meet a deadline or achieve a specific goal. This type of technical debt is often accrued as a result of business considerations, such as market pressures, and is seen as a necessary evil. The downside is that it can lead to additional work down the road, such as refactoring, which can be costly.

On the other hand, unintentional technical debt is incurred when a team is unaware of the impact of the decisions they make during development. This can happen as a result of a lack of understanding or expertise in a specific area, a lack of resources or time, or simply due to a lack of discipline or rigor.

This type of technical debt is often more insidious, as it can be difficult to detect and diagnose, and can lead to unforeseen consequences down the line. Regardless of the type of technical debt, it’s important to be aware of its existence and to take steps to manage it effectively in order to ensure the long-term health and success of a software project.

Examples of Technical Debt

Unintentional technical debt can accumulate over time if left unaddressed, eventually making it difficult to maintain and evolve the software. Some examples of unintentional technical debt include:

• Design debt arises when design decisions are made to meet short-term goals or delivery targets, without considering the long-term implications of those decisions.
• Code debt emerges from poor coding practices and shortcuts taken to meet deadlines, resulting in issues such as duplicated or overly complex code that is difficult to maintain or test.
• Testing debt occurs when proper testing is not carried out or is insufficient, leading to challenges in detecting and addressing defects and the potential for the release of bugs into production.

Intentional technical debt is taken on with the understanding that it will need to be paid back at some point in the future. Some examples of intentional technical debt include:

• Planned technical debt is deliberate. It involves taking shortcuts with the knowledge that they’ll be addressed in the future, such as using a third-party library that will be replaced with a custom solution.
• Business debt is intentionally incurred by the development team to meet a business need, such as launching a product with fewer features than planned to meet market demand, with the understanding that it will need to be improved later on.
• Strategic debt occurs when a team intentionally postpones work on new features or systems to prioritize other areas, despite knowing that it will be more costly in the future.

The best practice for technical debt is to take a proactive approach to manage code quality for software developers to be able to reduce the risk of accumulating too much technical debt and ensure that their software remains healthy and sustainable over the long term by prioritizing high-quality code and design practices and regularly paying down technical debt. This means investing in code quality, testing, and documentation, and ensuring that the software remains maintainable, scalable, and secure over time.

Importance of Static Analysis for Managing Technical Debt

Static analysis is an automated method of reviewing source code for quality and compliance issues. It can be useful for identifying safety issues, security vulnerabilities, and reliability concerns, or areas where code may be more difficult to maintain or extend in the future.

By catching technical debt early, teams can take steps to address it before it becomes a bigger problem. This can help improve code quality, reduce development time, cut labor costs, and enhance the overall value of software products.

Dashboards for High-Level Analysis

Parasoft’s centralized reporting and analytics dashboards provide developers and managers with the ability to see the current state of a project from various viewpoints and further navigate into more detail where needed to establish a set of warnings for further investigation. Consider the following dashboard showing a project’s current compliance with the CERT C security coding standard.

Using this web portal, users can dig deeper into the analysis, down to the file and code level if needed, and investigate warnings entirely within the web portal or in an IDE. Warnings can be prioritized, assigned to developers, suppressed, or marked as a false positive at this stage. See the following example from the Parasoft explorer.

Managing Violations of Coding Standards

In most cases when analyzing source code for coding standard compliance, violations are reported as static analysis warnings. In a large project, there are initially going to be lots of warnings. Managing them quickly and efficiently is critical. Parasoft’s violation explorer is the key tool to navigate, evaluate, prioritize, and assign reported errors for remediation.

If a static analysis rule violation turns out to be valid but justifiable, considered harmless, or not applicable, a developer can suppress the error and a deviation can be documented. These deviations are reported through each level of the project to the dashboard and compliance documentation.

To make coding standard compliance feasible for existing projects, it’s critical that teams focus on the rules that are considered mandatory first. Compliance is often based on meeting the mandatory requirements with violations of recommended rules if they are documented appropriately. Standards allow rules to be re-categorized, if they’re non-mandatory, allowing for violations, if justifiable and documented. Without this, trying to correct every violation becomes infeasible.

Leveraging artificial intelligence (AI) and machine learning (ML), Parasoft’s reporting and analytics learn from both historical interactions with the code base and prior static analysis findings to predict relevance and prioritize the new findings.

Development managers and leaders also save extra hours of work with a navigable interface to explore violations and automatically generate reports for certification evidence, if needed. An example of a MISRA C deviation report is shown below.

Managing Backlog of Bug and Security Warnings

It’s important for teams that are adopting static analysis to understand that it isn’t necessary to fix or analyze all warnings. All warnings are not created equally, so the severity level is the best indicator of how much effort should be placed into investigating and fixing a warning. When digging into the backlog of warnings, teams effectively move “the line in the sand” a bit further each time.

Parasoft’s Jtest and C/C++test enable users to prioritize and filter warnings within the IDE using configurations. For example, they can use a severity level and category to create a set of warnings suitable for analysis. An example of a new user configuration is shown below.

This configuration can be used to filter the warnings in the IDE.

Incrementally moving the “line in the sand” to tackle the next highest priority and category is the best approach for dealing with a large backlog of warnings. Eventually, software teams reach a cutoff point due to time and budget. But they should feel comfortable that they made significant improvements in quality and security despite any remaining backlog of warnings.

Best Practices for Preventing Technical Debt

Preventing technical debt requires a proactive approach that involves the entire software development team. Here are some best practices that can help prevent technical debt.

• Prioritize and plan. Develop a clear plan and prioritize tasks based on business value and risk. This can help avoid taking shortcuts to meet unrealistic deadlines.
• Code reviews. Conduct code reviews to ensure code quality and identify potential issues early in the development process.
• Automate testing. Use automated testing to detect issues early and reduce the risk of introducing new problems.
• Continuous integration and delivery. Implement continuous integration and delivery to ensure that code changes are regularly integrated and tested, reducing the risk of integration issues.
• Track technical debt. Track technical debt and prioritize paying it off as part of regular development cycles.
• Share knowledge. Foster a culture of knowledge sharing to ensure that the team is up to speed on the latest updates and best practices.

By following these best practices, software development teams can help prevent technical debt and ensure that they are building safe, secure, reliable, and maintainable software products.

Summary

In a large project, there are initially going to be lots of warnings. Managing them quickly and efficiently is critical. It’s important for teams adopting static analysis to understand that fixing or analyzing all warnings is unnecessary. Instead, make sure to select a tool that enables you to navigate, evaluate, prioritize, and assign reported errors for remediation. Incrementally moving the “line in the sand” to tackle the next highest priority and category is the best approach for dealing with a large backlog of warnings.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.