How does Technical Debt being calculated

Dear Support,

I think this is a pretty straight forward question: how does the technical dept being calculated?

Thanks,
Tamas

Hi @tcsabina

You will find your answers on our docs.
Here are listed few pages:
https://docs.sonarqube.org/latest/user-guide/concepts/
→ Technical debt : The estimated time required to fix all Maintainability Issues / code smells

https://docs.sonarqube.org/latest/user-guide/metric-definitions/
Technical Debt ( sqale_index )
Effort to fix all Code Smells. The measure is stored in minutes in the database. An 8-hour day is assumed when values are shown in days.

Technical Debt on New Code ( new_technical_debt )
Effort to fix all Code Smells raised for the first time on New Code.

Technical Debt Ratio ( sqale_debt_ratio )
Ratio between the cost to develop the software and the cost to fix it. The Technical Debt Ratio formula is:
Remediation cost / Development cost
Which can be restated as:
Remediation cost / (Cost to develop 1 line of code * Number of lines of code)
The value of the cost to develop a line of code is 0.06 days.

Technical Debt Ratio on New Code ( new_sqale_debt_ratio )
Ratio between the cost to develop the code changed on New Code and the cost of the issues linked to it.

Enjoy the reading :slight_smile:
Carine

Hi Carine,

I was looking for a more explicit, math formula based reply ;).

To see the relation between issue severity (Blocker+Critical+Major+Minor+Info) and Technical Debt.
Or relation between issue type (Bug+Vulnerability+Code Smell) and Technical Debt.

I know that there is an admin setting (sonar.technicalDebt.developmentCost) that defines the time needed to solve 1 line of code.

But how is the Technical Debt exactly calculated, still seems to be a misery… Even after looking/reading the docs you have linked.

The reason I am looking for this, because there is an ongoing discussion in my team about “Shall we include the Technical Debt in the Quality Gate or not?”.

If the Technical Debt is a value that is purely based on the number of the issues, I say that we don’t need it in the Quality Gate. It is enough if you measure the issue count.
If the Technical Debt is not just purely based on the number of issues, I would like to see the formula it is using, to understand it. So we can make a conscious decision about adding it to the QG or not.

Regards,
Tamas

Hi Carine,

Any update on this from your side? Could you address my questions, comments?

Tamas

Hey @tcsabina

Most issues in SonarQube have a remediation cost attached (estimated time to fix an issue). This could be 1m, 5m, 30m, etc… The sum of all these remediation costs for Code Smells (maintainability issues) for a project is the technical debt.

Does such a quantitative value make sense in a Quality Gate? I don’t think so. A rocket-launcher is probably going to have more technical debt than a calculator. We would rather suggest a Quality Gate condition for the Maintainability Rating.

Maintainability Rating ( sqale_rating )
(Formerly the SQALE rating.) Rating given to your project related to the value of your Technical Debt Ratio. The default Maintainability Rating grid is:

A=0-0.05, B=0.06-0.1, C=0.11-0.20, D=0.21-0.5, E=0.51-1

The Maintainability Rating scale can be alternately stated by saying that if the outstanding remediation cost is:

  • <=5% of the time that has already gone into the application, the rating is A
  • between 6 to 10% the rating is a B
  • between 11 to 20% the rating is a C
  • between 21 to 50% the rating is a D
  • anything over 50% is an E

You can always find Metric Definitions in our docs

It’s a bit unfortunate that all Roslyn warnings gives 0 minutes.

We have many code smells, but a very low tech debt time. That’s not helping

Maybe de default should be at least 1 minute