Advanced
Code Quality
#technical-debt
#SonarQube
#hotspot
#code-smell
Technical Debt Measurement Language
5 exercises — master the vocabulary of technical debt measurement: debt ratio, SQALE method, hotspots, SonarQube security classifications, and stakeholder communication.
0 / 29 completed
1 / 29
A SonarQube dashboard shows a project with a technical debt ratio of 8%. A new engineer asks: "What is the technical debt ratio and how is it calculated?"
The technical debt ratio is the primary objective metric for quantifying and communicating the scale of accumulated code quality issues to both engineering and business stakeholders.
Formula:
Technical Debt Ratio = (Remediation effort / Development cost) × 100
• Remediation effort — the total time SonarQube estimates is needed to fix all code smells and rule violations (e.g. 340 developer-hours)
• Development cost — the estimated cost to rebuild the codebase from scratch (calculated from LOC using a standard productivity rate, e.g. 30 minutes per line)
SQALE grade thresholds:
Key vocabulary:
• Technical debt ratio — remediation effort as a percentage of rebuild cost; the SQALE method's primary metric
• SQALE — Software Quality Assessment based on Lifecycle Expectations; the methodology underlying SonarQube debt calculation
• Code smell — a characteristic of source code that indicates a deeper problem without being a bug itself
Formula:
Technical Debt Ratio = (Remediation effort / Development cost) × 100
• Remediation effort — the total time SonarQube estimates is needed to fix all code smells and rule violations (e.g. 340 developer-hours)
• Development cost — the estimated cost to rebuild the codebase from scratch (calculated from LOC using a standard productivity rate, e.g. 30 minutes per line)
SQALE grade thresholds:
| Grade | Debt Ratio | Interpretation |
|---|---|---|
| A | ≤5% | Excellent — low debt, easy to maintain |
| B | 6–10% | Good — managed debt, monitor trends |
| C | 11–20% | Acceptable — address during refactoring sprints |
| D | 21–50% | Concerning — slowing down delivery significantly |
| E | >50% | Severely indebted — major remediation required |
Key vocabulary:
• Technical debt ratio — remediation effort as a percentage of rebuild cost; the SQALE method's primary metric
• SQALE — Software Quality Assessment based on Lifecycle Expectations; the methodology underlying SonarQube debt calculation
• Code smell — a characteristic of source code that indicates a deeper problem without being a bug itself
2 / 29
A security review of SonarQube results shows items labelled as "hotspots" and others labelled as "vulnerabilities". A developer asks: "What is the difference between a hotspot and a vulnerability in SonarQube?"
The hotspot vs vulnerability distinction in SonarQube reflects a fundamental security review concept: the difference between "potentially risky" and "definitely exploitable".
Security Hotspot:
• Code that is security-sensitive but may or may not be an actual vulnerability
• Requires a security-aware developer to review the context
• Example: use of
• Workflow: Review → Confirm (becomes a real vulnerability) OR Dismiss (false positive in context)
• Status: "To Review" → "Reviewed"
Vulnerability:
• Code that SonarQube's analysis has determined is directly exploitable
• No human review needed to classify — requires immediate remediation
• Example: SQL query built by string concatenation of user input (SQL injection)
• Workflow: Fix or accept with documented risk justification
Key vocabulary:
• Security hotspot — security-sensitive code requiring manual review to classify as safe or vulnerable
• Vulnerability — definitively exploitable security defect requiring remediation
• False positive — a tool-reported issue that is not actually a problem in context
Security Hotspot:
• Code that is security-sensitive but may or may not be an actual vulnerability
• Requires a security-aware developer to review the context
• Example: use of
Random instead of SecureRandom in Java — suspicious, but may be used only for non-security purposes• Workflow: Review → Confirm (becomes a real vulnerability) OR Dismiss (false positive in context)
• Status: "To Review" → "Reviewed"
Vulnerability:
• Code that SonarQube's analysis has determined is directly exploitable
• No human review needed to classify — requires immediate remediation
• Example: SQL query built by string concatenation of user input (SQL injection)
• Workflow: Fix or accept with documented risk justification
| Attribute | Hotspot | Vulnerability |
|---|---|---|
| Confidence | Possible risk — review needed | Confirmed exploitable issue |
| Action required | Human review (confirm or dismiss) | Remediation (fix or accept with justification) |
| Quality gate impact | Yes — unreviewed hotspots can fail security rating | Yes — new vulnerabilities fail security rating |
Key vocabulary:
• Security hotspot — security-sensitive code requiring manual review to classify as safe or vulnerable
• Vulnerability — definitively exploitable security defect requiring remediation
• False positive — a tool-reported issue that is not actually a problem in context
3 / 29
A new hire from a background in testing asks: "What is the SQALE method and how does it relate to SonarQube's technical debt calculations?"
SQALE is the conceptual framework that makes SonarQube's technical debt numbers meaningful — understanding it allows you to explain and defend debt estimates to engineering leadership.
How SQALE works:
① Every SonarQube rule (e.g. "Function has cyclomatic complexity >10", "Duplicated block of 15 lines") has a defined remediation cost
② Example remediation costs: fix a code smell = 20 min, extract a duplicated block = 1h, fix a critical vulnerability = 4h
③ SonarQube scans the codebase, counts all violations, multiplies each by its remediation cost
④ Sum of all remediation costs = total technical debt (e.g. "342 hours")
⑤ Debt ratio = debt ÷ rebuild cost → SQALE grade A–E
SonarQube technical debt grade calculation:
Key vocabulary:
• SQALE — Software Quality Assessment based on Lifecycle Expectations; the debt calculation methodology used by SonarQube
• Remediation cost — the estimated developer time required to fix a specific rule violation
• Technical debt — the cumulative cost of shortcuts and quality compromises that must eventually be addressed
How SQALE works:
① Every SonarQube rule (e.g. "Function has cyclomatic complexity >10", "Duplicated block of 15 lines") has a defined remediation cost
② Example remediation costs: fix a code smell = 20 min, extract a duplicated block = 1h, fix a critical vulnerability = 4h
③ SonarQube scans the codebase, counts all violations, multiplies each by its remediation cost
④ Sum of all remediation costs = total technical debt (e.g. "342 hours")
⑤ Debt ratio = debt ÷ rebuild cost → SQALE grade A–E
SonarQube technical debt grade calculation:
| Grade | Debt Ratio | Business translation |
|---|---|---|
| A | ≤5% | Healthy codebase — low maintenance burden |
| B | 6–10% | Managed debt — minor slowdown to delivery |
| C | 11–20% | Noticeable debt — impacting velocity |
| D | 21–50% | Significant debt — requires investment plan |
| E | >50% | Crisis debt — significant team productivity lost |
Key vocabulary:
• SQALE — Software Quality Assessment based on Lifecycle Expectations; the debt calculation methodology used by SonarQube
• Remediation cost — the estimated developer time required to fix a specific rule violation
• Technical debt — the cumulative cost of shortcuts and quality compromises that must eventually be addressed
4 / 29
An engineer says: "We should prioritise this file for refactoring — it's a hotspot." Colleagues look confused because they thought hotspots referred only to security issues in SonarQube. What does "hotspot" mean in the broader technical debt vocabulary?
The technical debt hotspot concept (distinct from the SonarQube security hotspot) is one of the most actionable ideas in software engineering — it tells you exactly where to spend refactoring effort for maximum bug reduction.
The hotspot definition (Tornhill, "Your Code as a Crime Scene"):
Hotspot = High complexity × High churn
• Complexity — how hard the file is to understand and modify correctly (cyclomatic complexity, LOC, number of responsibilities)
• Churn — how frequently the file is modified (commit frequency, number of authors)
Why the intersection matters:
A complex file that is never changed: theoretical risk, low practical impact
A simple file that changes constantly: low risk per change, low overall risk
A complex file that changes constantly: highest statistical bug density
Research evidence:
• Microsoft Research: top 10% of complex files by churn contain significantly more bugs than the rest of the codebase combined
• Google: hotspot refactoring shows the highest return on investment in defect prevention
How to extract hotspots from a codebase:
This command extracts the 20 most-changed files — combine with SonarQube complexity to identify hotspots.
Key vocabulary:
• Hotspot (debt context) — a file combining high complexity and high churn; highest refactoring priority
• Churn — the number of times a file has been modified over a period
• Temporal coupling — files that always change together; another hotspot signal
The hotspot definition (Tornhill, "Your Code as a Crime Scene"):
Hotspot = High complexity × High churn
• Complexity — how hard the file is to understand and modify correctly (cyclomatic complexity, LOC, number of responsibilities)
• Churn — how frequently the file is modified (commit frequency, number of authors)
Why the intersection matters:
A complex file that is never changed: theoretical risk, low practical impact
A simple file that changes constantly: low risk per change, low overall risk
A complex file that changes constantly: highest statistical bug density
Research evidence:
• Microsoft Research: top 10% of complex files by churn contain significantly more bugs than the rest of the codebase combined
• Google: hotspot refactoring shows the highest return on investment in defect prevention
How to extract hotspots from a codebase:
git log --format=format: --name-only | sort | uniq -c | sort -rn | head -20This command extracts the 20 most-changed files — combine with SonarQube complexity to identify hotspots.
Key vocabulary:
• Hotspot (debt context) — a file combining high complexity and high churn; highest refactoring priority
• Churn — the number of times a file has been modified over a period
• Temporal coupling — files that always change together; another hotspot signal
5 / 29
The engineering team's quarterly report states: "We reduced technical debt by 1,800 developer-hours this quarter." What does this mean, and how should it be communicated to non-technical stakeholders?
Communicating technical debt reduction effectively to non-technical stakeholders is a critical senior engineering skill — it bridges the gap between code quality work and business outcomes.
What 1,800 developer-hours of debt reduction means technically:
• The team resolved code smells, refactored complex functions, eliminated duplication, and improved test coverage
• SonarQube now estimates 1,800 fewer hours of remediation work remaining than at the start of the quarter
• This is quantified by the SQALE method: each fixed violation removes its remediation cost from the total
How to translate for different stakeholders:
Framing technical debt repayment as an investment:
Avoid framing tech debt work as "fixing past mistakes" — this invites blame. Instead use: "We invested in foundation work this quarter. This increases our delivery capacity by approximately 15% in Q3 as these areas no longer require careful workarounds."
Key vocabulary:
• Debt remediation — the act of fixing code quality issues to reduce technical debt
• Maintenance burden — the ongoing engineering cost of working around poor code quality
• Foundation work — the business-friendly term for technical debt reduction and infrastructure improvements
What 1,800 developer-hours of debt reduction means technically:
• The team resolved code smells, refactored complex functions, eliminated duplication, and improved test coverage
• SonarQube now estimates 1,800 fewer hours of remediation work remaining than at the start of the quarter
• This is quantified by the SQALE method: each fixed violation removes its remediation cost from the total
How to translate for different stakeholders:
| Stakeholder | Translation |
|---|---|
| Product Manager | "Future features in these areas will take 20–30% less time to implement" |
| CEO / CTO | "We reduced maintenance burden equivalent to ~1 engineer-year of hidden cost" |
| Finance | "Risk of costly emergency incidents from these modules is significantly reduced" |
| Engineering team | "SonarQube debt ratio improved from C-grade (14%) to B-grade (8%)" |
Framing technical debt repayment as an investment:
Avoid framing tech debt work as "fixing past mistakes" — this invites blame. Instead use: "We invested in foundation work this quarter. This increases our delivery capacity by approximately 15% in Q3 as these areas no longer require careful workarounds."
Key vocabulary:
• Debt remediation — the act of fixing code quality issues to reduce technical debt
• Maintenance burden — the ongoing engineering cost of working around poor code quality
• Foundation work — the business-friendly term for technical debt reduction and infrastructure improvements
6 / 29
PR Description: 'Just spent the last few hours cleaning up this legacy code. Fixed a bunch of duplication and made it much more readable. Added some unit tests.'
During a code review, your team lead asks you to elaborate on the PR description. Which of the following best captures the concept of 'technical debt' in this context?
Option A: The PR demonstrates a commitment to continuous integration and automated testing.
Option B: The PR addresses potential future problems by improving code clarity and reducing redundancy – essentially, proactively managing technical debt.
Option C: The PR simply makes the code easier to understand for the current developers.
Option D: The PR prioritizes immediate performance improvements over long-term maintainability.
This question assesses understanding of how technical debt manifests in practical code changes. Option B is correct because it highlights that a PR like this represents an acknowledgment and proactive attempt to address potential future issues through improved code quality – reducing the risk of accumulating more significant technical debt later. Options A, C, and D misunderstand the core concept; they focus on superficial aspects (CI/CD, readability, or performance) rather than recognizing the underlying issue of deferred maintenance and its potential impact.
7 / 29
PR Description: 'Just spent the last few hours cleaning up this legacy code. Fixed a bunch of duplication and made it much more readable. Added some unit tests.'
During a code review, your team lead asks you to elaborate on the PR description. Which of the following best captures the concept of 'technical debt' in this context?
Option A: The PR demonstrates a commitment to continuous integration and automated testing.
Option B: The PR addresses potential future problems by improving code clarity and reducing redundancy – essentially, proactively managing technical debt.
Option C: The PR simply makes the code easier to understand for the current developers.
Option D: The PR prioritizes immediate performance improvements over long-term maintainability.
This question assesses understanding of how technical debt manifests in practical code changes. Option B is correct because it highlights that a PR like this represents an acknowledgment and proactive attempt to address potential future issues through improved code quality – reducing the risk of accumulating more significant technical debt later. Options A, C, and D misunderstand the core concept; they focus on superficial aspects (CI/CD, readability, or performance) rather than recognizing the underlying issue of deferred maintenance and its potential impact.
8 / 29
PR Description: 'Just spent the last few hours cleaning up this legacy code. Fixed a bunch of duplication and made it much more readable. Added some unit tests.'
During a code review, your team lead asks you to elaborate on the PR description. Which of the following best captures the concept of 'technical debt' in this context?
Option A: The PR demonstrates a commitment to continuous integration and automated testing.
Option B: The PR addresses potential future problems by improving code clarity and reducing redundancy – essentially, proactively managing technical debt.
Option C: The PR simply makes the code easier to understand for the current developers.
Option D: The PR prioritizes immediate performance improvements over long-term maintainability.
This question assesses understanding of how technical debt manifests in practical code changes. Option B is correct because it highlights that a PR like this represents an acknowledgment and proactive attempt to address potential future issues through improved code quality – reducing the risk of accumulating more significant technical debt later. Options A, C, and D misunderstand the core concept; they focus on superficial aspects (CI/CD, readability, or performance) rather than recognizing the underlying issue of deferred maintenance and its potential impact.
9 / 29
PR Description: 'Just spent the last few hours cleaning up this legacy code. Fixed a bunch of duplication and made it much more readable. Added some unit tests.'
During a code review, your team lead asks you to elaborate on the PR description. Which of the following best captures the concept of 'technical debt' in this context?
Option A: The PR demonstrates a commitment to continuous integration and automated testing.
Option B: The PR addresses potential future problems by improving code clarity and reducing redundancy – essentially, proactively managing technical debt.
Option C: The PR simply makes the code easier to understand for the current developers.
Option D: The PR prioritizes immediate performance improvements over long-term maintainability.
This question assesses understanding of how technical debt manifests in practical code changes. Option B is correct because it highlights that a PR like this represents an acknowledgment and proactive attempt to address potential future issues through improved code quality – reducing the risk of accumulating more significant technical debt later. Options A, C, and D misunderstand the core concept; they focus on superficial aspects (CI/CD, readability, or performance) rather than recognizing the underlying issue of deferred maintenance and its potential impact.
10 / 29
Sarah (Senior Developer): "I'm seeing a high 'Code Smells' count on this module. Should we just ignore it and move forward with the feature?" What's the most appropriate response to suggest addressing this issue?
Code Smells are deviations from good coding practices that can accumulate into technical debt. Ignoring them risks increased complexity and maintenance costs later on. Addressing them proactively – even if it's just a small refactoring – demonstrates a commitment to long-term code quality. The correct answer emphasizes the potential for these issues to evolve into significant problems.
11 / 29
Mark (Tech Lead) sends this Slack message: 'The SonarQube report flagged this as a 'high severity' issue. I'm going to fix it ASAP!' What does the term 'high severity' typically mean in the context of SonarQube results?
'High Severity' in SonarQube signifies a critical issue with a potentially detrimental impact. It usually indicates a vulnerability or code smell that poses a substantial risk—often related to security, performance, or stability. The term isn't purely subjective; it represents a prioritized level of concern based on pre-defined rules.
12 / 29
David (Junior Developer) asks: 'What's the purpose of using the SQALE method for measuring technical debt?'
The SQALE method (Severity, Question, Area, Latency, Effort) provides a structured approach to technical debt measurement. It goes beyond simply counting defects; it assesses the *quality* of the debt – how serious is it, what area of the code does it affect, and how much effort will be required to resolve it? This allows for more informed prioritization.
13 / 29
Emily (Code Reviewer) comments on a PR: 'This code is quite complex and difficult to understand. I'd suggest refactoring it into smaller, more manageable functions.' What does Emily likely mean when she says this about the code?
When Emily says the code is 'complex and difficult to understand,' she's likely referring to technical debt. Complex code often stems from hasty solutions, poor design choices, or a lack of attention to maintainability – all hallmarks of accumulated technical debt. The goal is to reduce this complexity and improve its long-term health.
14 / 29
John (Product Manager) asks the development team: 'We've managed to reduce our technical debt by 25% this quarter. How should we explain this to stakeholders?'
Stakeholders need to understand the *value* of reducing technical debt, not just the number. Framing it as a reduction in future development costs and improved stability provides context. It's crucial to translate the technical metric into business benefits – faster feature delivery, reduced risk, etc.
15 / 29
Sarah (Senior Developer): "I'm seeing a high 'Code Smells' count on this module. Should we just ignore it and move forward with the feature?" What's the most appropriate response to suggest addressing this issue?
Code Smells are deviations from good coding practices that can accumulate into technical debt. Ignoring them risks increased complexity and maintenance costs later on. Addressing them proactively – even if it's just a small refactoring – demonstrates a commitment to long-term code quality. The correct answer emphasizes the potential for these issues to evolve into significant problems.
16 / 29
Mark (Tech Lead) sends this Slack message: 'The SonarQube report flagged this as a 'high severity' issue. I'm going to fix it ASAP!' What does the term 'high severity' typically mean in the context of SonarQube results?
'High Severity' in SonarQube signifies a critical issue with a potentially detrimental impact. It usually indicates a vulnerability or code smell that poses a substantial risk—often related to security, performance, or stability. The term isn't purely subjective; it represents a prioritized level of concern based on pre-defined rules.
17 / 29
David (Junior Developer) asks: 'What's the purpose of using the SQALE method for measuring technical debt?'
The SQALE method (Severity, Question, Area, Latency, Effort) provides a structured approach to technical debt measurement. It goes beyond simply counting defects; it assesses the *quality* of the debt – how serious is it, what area of the code does it affect, and how much effort will be required to resolve it? This allows for more informed prioritization.
18 / 29
Emily (Code Reviewer) comments on a PR: 'This code is quite complex and difficult to understand. I'd suggest refactoring it into smaller, more manageable functions.' What does Emily likely mean when she says this about the code?
When Emily says the code is 'complex and difficult to understand,' she's likely referring to technical debt. Complex code often stems from hasty solutions, poor design choices, or a lack of attention to maintainability – all hallmarks of accumulated technical debt. The goal is to reduce this complexity and improve its long-term health.
19 / 29
John (Product Manager) asks the development team: 'We've managed to reduce our technical debt by 25% this quarter. How should we explain this to stakeholders?'
Stakeholders need to understand the *value* of reducing technical debt, not just the number. Framing it as a reduction in future development costs and improved stability provides context. It's crucial to translate the technical metric into business benefits – faster feature delivery, reduced risk, etc.
20 / 29
Sarah (Senior Developer): "I'm seeing a high 'Code Smells' count on this module. Should we just ignore it and move forward with the feature?" What's the most appropriate response to suggest addressing this issue?
Code Smells are deviations from good coding practices that can accumulate into technical debt. Ignoring them risks increased complexity and maintenance costs later on. Addressing them proactively – even if it's just a small refactoring – demonstrates a commitment to long-term code quality. The correct answer emphasizes the potential for these issues to evolve into significant problems.
21 / 29
Mark (Tech Lead) sends this Slack message: 'The SonarQube report flagged this as a 'high severity' issue. I'm going to fix it ASAP!' What does the term 'high severity' typically mean in the context of SonarQube results?
'High Severity' in SonarQube signifies a critical issue with a potentially detrimental impact. It usually indicates a vulnerability or code smell that poses a substantial risk—often related to security, performance, or stability. The term isn't purely subjective; it represents a prioritized level of concern based on pre-defined rules.
22 / 29
David (Junior Developer) asks: 'What's the purpose of using the SQALE method for measuring technical debt?'
The SQALE method (Severity, Question, Area, Latency, Effort) provides a structured approach to technical debt measurement. It goes beyond simply counting defects; it assesses the *quality* of the debt – how serious is it, what area of the code does it affect, and how much effort will be required to resolve it? This allows for more informed prioritization.
23 / 29
Emily (Code Reviewer) comments on a PR: 'This code is quite complex and difficult to understand. I'd suggest refactoring it into smaller, more manageable functions.' What does Emily likely mean when she says this about the code?
When Emily says the code is 'complex and difficult to understand,' she's likely referring to technical debt. Complex code often stems from hasty solutions, poor design choices, or a lack of attention to maintainability – all hallmarks of accumulated technical debt. The goal is to reduce this complexity and improve its long-term health.
24 / 29
John (Product Manager) asks the development team: 'We've managed to reduce our technical debt by 25% this quarter. How should we explain this to stakeholders?'
Stakeholders need to understand the *value* of reducing technical debt, not just the number. Framing it as a reduction in future development costs and improved stability provides context. It's crucial to translate the technical metric into business benefits – faster feature delivery, reduced risk, etc.
25 / 29
Sarah (Senior Developer): "I'm seeing a high 'Code Smells' count on this module. Should we just ignore it and move forward with the feature?" What's the most appropriate response to suggest addressing this issue?
Code Smells are deviations from good coding practices that can accumulate into technical debt. Ignoring them risks increased complexity and maintenance costs later on. Addressing them proactively – even if it's just a small refactoring – demonstrates a commitment to long-term code quality. The correct answer emphasizes the potential for these issues to evolve into significant problems.
26 / 29
Mark (Tech Lead) sends this Slack message: 'The SonarQube report flagged this as a 'high severity' issue. I'm going to fix it ASAP!' What does the term 'high severity' typically mean in the context of SonarQube results?
'High Severity' in SonarQube signifies a critical issue with a potentially detrimental impact. It usually indicates a vulnerability or code smell that poses a substantial risk—often related to security, performance, or stability. The term isn't purely subjective; it represents a prioritized level of concern based on pre-defined rules.
27 / 29
David (Junior Developer) asks: 'What's the purpose of using the SQALE method for measuring technical debt?'
The SQALE method (Severity, Question, Area, Latency, Effort) provides a structured approach to technical debt measurement. It goes beyond simply counting defects; it assesses the *quality* of the debt – how serious is it, what area of the code does it affect, and how much effort will be required to resolve it? This allows for more informed prioritization.
28 / 29
Emily (Code Reviewer) comments on a PR: 'This code is quite complex and difficult to understand. I'd suggest refactoring it into smaller, more manageable functions.' What does Emily likely mean when she says this about the code?
When Emily says the code is 'complex and difficult to understand,' she's likely referring to technical debt. Complex code often stems from hasty solutions, poor design choices, or a lack of attention to maintainability – all hallmarks of accumulated technical debt. The goal is to reduce this complexity and improve its long-term health.
29 / 29
John (Product Manager) asks the development team: 'We've managed to reduce our technical debt by 25% this quarter. How should we explain this to stakeholders?'
Stakeholders need to understand the *value* of reducing technical debt, not just the number. Framing it as a reduction in future development costs and improved stability provides context. It's crucial to translate the technical metric into business benefits – faster feature delivery, reduced risk, etc.
Frequently Asked Questions
What does the "Technical Debt Measurement" exercise practise?
Practice English vocabulary for discussing technical debt: technical debt ratio, SQALE method, SonarQube hotspots, vulnerabilities, and communicating debt to stakeholders. 5 exercises.
How many questions are in this exercise?
This exercise has 29 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Advanced. If the vocabulary feels difficult, browse the Code Quality & Metrics category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Technical Debt Measurement" part of a larger series?
Yes — it's one exercise in the Code Quality & Metrics category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Quality & Metrics category page for related exercises, or browse the main Exercises hub for other IT English topics.