Exercises › Technical Due Diligence Language › Tech Debt Quantification

Tech Debt Quantification

5 questions · Technical Due Diligence Language

1. SonarQube calculates that remediation of all code quality violations in the system would take 28 engineering weeks. This is an example of:

Code coverage deficit Technical debt expressed as remediation effort Cyclomatic complexity

2. The tech debt ratio is calculated as remediation effort divided by estimated original build cost, expressed as a percentage. A ratio of 35% in a due diligence context means:

35% of the codebase needs to be rewritten Remediation would cost 35% of the original build cost — a significant technical debt burden 35% of features are affected by technical debt

3. The team uses CodeScene to find files that are both highly complex and frequently changed. These files are the most likely source of bugs and the most expensive to modify. What are these files called?

Critical path modules Code hotspots High-churn components

4. The due diligence team finds that test coverage is 28% on the core business logic module. This is presented as a risk because:

Low coverage means the code doesn't compile Low coverage means bugs in that module may not be caught before reaching production Low coverage is required by regulators

5. The lead engineer explains that the payment processing module hasn't been updated because it still works, even though it uses deprecated libraries with known vulnerabilities. What type of technical debt does this represent?

Design debt Dependency and security debt Test debt

Exercise complete!

out of 5 questions

Back to Technical Due Diligence Language All exercises