SonarQube Technical Debt management with Quality Gate

Question

Configuring a custom Quality Gate, the default SonarQube Way has been taken as initial reference and further adjusted and customized (adding further checks). Our current quality gate looks as following (old version vs current version):

Blocker issues:             error threshold at 0
Complexity/class:           error threshold at 12
Complexity/file:            error threshold at 12
Complexity/function         error threshold at 2
Coverage                    error threshold at 100 >> changed to 65
Critical issues             error threshold at 0
Duplicated lines (%)        error threshold at 5
Info issues                 error threshold at 10
Major issues                error threshold at 50
Minor issues                error threshold at 100
Overall coverage            error threshold at 100 >> changed to 65
Public documented API (%)   error threshold at 50
Skipped Unit tests          error threshold at 0
Technical Debts             error threshold at 10d >> change to (?? < 10)
Unit test errors            error threshold at 0
Unit test failures          error threshold at 0

The main point is about the Technical Debts days, which should be enforced from 10 to something smaller, given that other checks have been relaxed (complexity and coverage). This is indeed reasonable: relaxing some rules you should have more margin for controlled technical debt and hence shorter threshold for the number of accumulated days for uncontrolled technical debt.

However, the overall quality gate should somehow (mathematically?) follow a certain proportion.

Question : how to calculate the most appropriate technical debt threshold given the relaxations above?

From an old article (2009, hence most probably not applicable any longer) the following formula has been deducted:

TechDebt = (cost_to_fix_one_block * duplicated_blocks) + \
     (cost_to fix_one_violation * mandatory_violations) + \
     (cost_to_comment_one_API * public_undocumented_api) + \
     (cost_to_cover_one_of_complexity * uncovered_complexity_by_tests) + \
     (cost_to_split_a_method * function_complexity_distribution) + \
     (cost_to_split_a_class * class_complexity_distribution)

Note: \\ added for readability.

However, there are too many unknown variables to make a proper calculation, yet it is not covering all of the quality gate items above (again, it's an old reference).

Other more recent sources explain in details concerned items, but not how to adjust values in a proportionated manner .

The sonar.technicalDebt.developmentCost ( Admin / Configuration / Technical Debt ) has a default value of 30 minutes, which means 1 LOC (cost to develop 1 line of code) = 30, but still not at the granularity level of the variables above nor useful in this case.

Answer 1

A Quality Gate is made up of a set of conditions. Your list of conditions is far longer than the one in the default quality gate. Most of the conditions you list aren't in the default quality gate. It looks instead as though you've edited the default thresholds of a number of rules.

And in a sense, you're talking about apples and oranges.

A Technical Debt threshold can be included in a Quality Gate, but by default is not. Instead, the Technical Debt Ratio on New Code is included in the default QG. But the concept of the Technical Debt Ratio does have bearing on your question. If you set a hard threshold on technical debt in a quality gate, small projects will have an easier time passing the QG than large projects. If you instead use the Technical Debt Ratio or the Technical Debt Ratio on New Code (recommended) then you're setting your quality gate on a ratio based on code base size versus technical debt. So every project has the same chance of passing or failing. The formula is this:

Remediation cost / (Cost to develop 1 line of code * Number of lines of code)

with, an estimated line development cost of 30 min. This value is editable, BTW: Administration > Technical Debt > Development cost

The default quality gate includes a Technical Debt Ratio on New Code error threshold of 5.