CodeGuru content and product recommendations are
editorially independent. We may make money when you click on links
to our partners.
Learn More
Day 1 â?? Yeepie! We declare war to Technical Debt…
Today is a great day. Everyone is now aware of the problem and truly believes that technical debt affects the velocity of teams, by decreasing the applications quality level (performance, ability to add new features, reliability of maintenance tasks, testability, maintainability, etc.).
Everyone agrees that we need to control code quality in order to apply programming best practices. Developers are enthusiastic, and the application owner hopes that the project will be back soon on the track of excellence.
This is the first day of the â??big fightâ?? against technical debt: all members of the organization are in the starting blocksâ?¦
Day 2 â?? Flooded with post-its on the board. Weâ??ll fight technical debt later…
Developers have their favorite tool installed in their favorite IDE, and their favorite coding rules are activated. First code audits are performed, but â?¦ oh wait! â?¦ a huge and endless list of violations suddenly appears on developersâ?? screens. Which rule violations really need to be fixed? Moreover, do we have to fix all violations? Would the criticity of a rule be equally considered between two different developers?
When facing this mountain of technical debt that covers every single wall with post-its, many development teams renounce to continue code quality remediation projects. They are lost in the mass of violations and discouraged by the effort induced by the correction of 45,978 defects. â??OK, weâ??ll spend time on it when big problems appear in productionâ??.
Day 3 â?? Hell, why didnâ??t we take care of those post-its?
Big problems finally appeared in the application, but the mountain of violations to be corrected still remains. Worse, it enlarged, following the pace of project deliveries. We call it â??Debt Interestsâ??!
Told in 3 days, this story might seem a little grotesque. Unfortunately, this is a true story for many development teams, although it is experienced in a longer period of time. This â??tunnel effectâ?? inspired us for a new feature in our Scertify Eclipse plugin: the dynamic violation filtering. Even if your quality profile contains only useful coding rules (well, if itâ??s not useful to fix a violation, why would you keep these rules in your quality profile?), some things are better left unsaid â?¦ or said later!
How to use Dynamic Violation Filtering with Scertify
In this post, I will highlight an interesting feature of Scertify that enables developers to give a leg up to concretely reduce technical debt of their projects, without being unmotivated by a tons of violations that would flood your Eclipseâ??s marker view. This is the Dynamic Violation Filtering.
This feature, which can be customized for every project, allows user to define a dynamic display of violations in the Eclipseâ??s marker view. This means you can show, for example, only blocker violations until no cases of this criticity remain in the code. Once all blocker defects have been fixed, the critical vioations will be shown, and so on.
To set this feature, right-click on your project » Properties » Scertify, then click on the â??Audit Configurationâ?? tab. A drop-down list details analysis options for each level of cricity (blocker, critical, major, minor, info). During a code audit, Scertifyâ?¢ will take these parameters into account by applying cascade, starting with the higher criticity (blocker).
4 options are available to customize your analysis:
– Never Audit: Whatever happens, violations for the selected criticity wonâ??t appear in the marker view (we generally advise to select this option for minor and informative violations at the beginning of a remediation project)
– Always Audit: Violations of the selected criticity will be always displayed in the marker view (generally used with blocker violations)
– No Error: Violations of the selected criticity will be shown in the marker view, only if no violations with a higher criticity has been detected (ie: if no critical violations are detected, Scertifyâ?¢ will display major)
– No Error Threshold Exceeded: Violations of the selected criticity will be displayed only if the number of violations with a superior criticity do not exceed a specific threshold you defined
In conclusion, this feature -that may look trivial- will progressively provides the info you need to reduce technical debt with efficiency. It will help you to set the cadency you want to give for your remediation campaigns:
– Short-term: First, keep the focus on real issues (blocker, critical). The other violations with a lower criticity have to be considered as secondary at this stage
– Mid-term: Fix code violations that have a lower immediate impact (major, minor), but generally related to strategic quality domains such as maintainability and extensibility (in the mean time, stay sure that no new blocker and critical appear again)
– Long-term: well, basically you just annihilated your technical debt without noticing the initial big mountain
