Static code analysis is valuable in finding code that is overly complex, violates a specific style guide, or contains error prone constructs.
It’s genuinely useful, and I use static code analysis myself as a low-level verification technique.
However, the very nature of static code analysis means that it focuses on a snapshot of the code as it looks right now. This means that static analysis won’t work well to prioritize technical debt, nor is it intended to; a piece of code isn’t technical debt unless we have to pay interest on it. Static analysis lacks this temporal dimension as well as a link to the business impact. CodeScene was created to fill these gaps.
Research Findings on Prioritizing Technical Debt with CodeScene
These observations are supported by a recent research paper from the University of Ottawa which concludes that:
- “in reality, acting upon all the TD instances is not worthy” (Parthiban, D.G. Examination of tools for managing different dimensions of Technical
Debt, 2019).
There’s simply too much technical debt, and the business value from fixing it isn’t clear. But the paper continues:
- There are tools like CodeScene which helps in prioritizing the refactoring targets. It prioritizes TD instances based on their technical debt interest rate, which is exactly our claim above.
So CodeScene works well in practice for prioritization. But what about the impact of its reported issues? Additional research, this time from the University of Victoria’s code quality study, compared CodeScene to SonarQube, a market-leading static analysis tool, and verified the reports by human inspection:
- The study claims that “the problems found using SonarQube had little effect on technical debt and were likely small issues which would result in little reward if fixed”.
- The study also claims that “Next, we ran CodeScene on Bokeh [a codebase], which lead to more significant results”. and states that “Ultimately, there were more alarming issues found by CodeScene”.
- The case study concludes that “We found CodeScene to be more useful [..] as it provided us with a higher level view of problems and potential issues”.
- Using CodeScene also “shed a light on issues that were not apparent while previously examining the source code”.
Both of these studies also looked at people-factors. This is another area where behavioral code analysis shines; the people side of software development simply isn’t available in the source code itself, whereas tools like CodeScene – with its additional data sources – can analyse aspects like knowledge distribution, team coupling, and off-boarding risks.
Explore More and try CodeScene
Check out our white paper to learn more about CodeScene, its use cases, and how they fit into your existing workflow and roles.
CodeScene’s social team analyses are described this blog post.
CodeScene is available as an on-premise version and as a hosted CodeScene Cloud that’s free for open source projects.