SONAR Rules and Technical Debt

This is short narrative compared to my first one on Evolutionary Architecture, but I think it can have a big impact on how practitioner teams work these days. Many teams use SONAR (or related tools) to measure Technical Debt. These tools analyze your code base and estimate: your current debt is 2345,94 USD. They also support you with a pre-configured set of rules to determine what’s important to fix and what is not. SONAR, for example, categorizes debt items as info, minor, major, critical and blocker. A missing documentation of a method is “major”, also a magic number or a duplicated String value. If you iterate over a Map in a very inefficient way, it’s surprisingly “critical”. But to be fair, possible NullPointerExceptions are also “critical”. These issues are usually easy to fix.
To my surprise, classes with 1000 LoC and/or 15 dependencies on class level are OK, and even worse: if you have a class with 3000 LoC and 30 class level dependencies, you only have a major problem.

What do teams do if they have 250 SONAR violations? Right, they try to get rid of most of them as quickly as possible, by usually choosing the easy ones first. In the end, you have only 3 major issues left, unfortunately 2 really complex god classes with many dependencies and one 500 LoC method with a very high cyclomatic complexity. All is good! Only 3 major problems, we can lay back and relax! Our code is awesome and we don’t have much Technical Debt.

What are you saying, Sven? We only fixed the unimportant stuff? We should better have fixed the 3 remaining issues instead, because they are really slowing us down. They cause a lot of bugs and it’s really hard to make changes in these classes and methods? No, no, we disagree, because a) the SONAR guys are the real experts in this, they do the whole day nothing else than debt analysis and when they say something is major or critical they are probably right and you are not; b) it takes a lot of time to fix these 3 issues, if even possible. This code is really complex and it is really risky to break down! The way we did it makes even the management happy, because we spent only a couple of hours to basically reduce our Technical Debt to 400 USD and SONAR looks really good right now!

Maybe most of my colleagues are right with that. But I would be really happy if we could analyze the current state-of-the-practice during the workshop and, if necessary, come up with a better proposal on how tool vendors should categorize Technical Debt. Every team is of course free to configure their own importance of rules, but a solid and often cited publication will help to drive discussions besides “but SONAR says so”.