Facing Technical Debt: How to not discourage developers?

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 ;-)



Posted by
Michael MULLER (See other posts)

+10 years experienced Marketing & Communication Manager, specialized in Technology & Innovating companies. Marketing Manager at Tocea. Executive editor at http://dsisionnel.com, a french IT magazine. Creator of http://d8p.it, a cool url shortener. Dad of 2 kids.

2 thoughts on “Facing Technical Debt: How to not discourage developers?

  1. Ludovic Urbain

    @Hrish: I don’t think tocea’s tool is mature enough to fix the core problems (the focus on Java hints to a relatively standard coder behind the project), but a software written by brilliant people can surely do 80% of the work to transform very crappy software to ok-ish software, and that in itself would be a major improvement for many projects.

    The problem is not people/ attitude, it’s businesses wanting cheap 100 programmers, and 1337 coders absolutely not interested by stupid languages or projects.

    The summary is that the people most qualified to write (business) software are invariably uninterested by it (the only way I can do it is by stretching the goals to something worthwhile).

    So in the end, you will always have mediocre (and cheap) programmers using mediocre (like java) languages and producing gigabytes of bad code, that will need to be cleaned up for cheap.

Comments are closed.