Advanced
Code Quality
#technical-debt
#debt-ratio
#debt-metaphor
#backlog-prioritisation
Technical Debt Metrics Vocabulary
5 exercises — master the English vocabulary engineers and managers use when discussing technical debt: debt ratio, the interest metaphor, backlog prioritisation, debt types, and compounding.
0 / 25 completed
1 / 25
In an architecture review, a tech lead says: "The SonarQube report shows our technical debt ratio is 18%. That means it will take roughly 18% of the original development investment to clean this codebase up to a maintainable baseline. We're in the 'C' band — we should be targeting 'A'." What does a debt ratio of 18% mean operationally, and what is the 'A' band target?
The SQALE debt ratio expresses the total cleanup cost of a codebase as a proportion of its estimated development cost — turning an abstract quality score into an engineering-time estimate that leadership can understand and budget for.
SQALE maintainability rating:
Path from C to A — highest-leverage actions:
① Remove duplicated code blocks (SonarQube often assigns 30–60 min per duplication violation)
② Reduce cognitive complexity in the highest-scoring functions
③ Fix naming violations and magic numbers (fast wins; many small issues add up)
④ Set a new-debt quality gate: prevent the ratio from increasing while old debt is paid down
Reporting language:
• "At 18% debt ratio, we're about 180 developer-days of remediation work from a clean codebase."
• "Our target is the A band — below 5% — which would require approximately 130 days of focused remediation."
• "If we allocate 10% of each sprint to debt remediation, we can reach the A band in about 18 months."
Key vocabulary:
• Debt ratio — remediation cost ÷ estimated development cost, as a percentage
• SQALE rating — SonarQube's A–E maintainability grade derived from debt ratio
• Remediation cost — the estimated developer time needed to fix a specific code issue
• Debt band — a named category of debt ratio ranges (A through E) with associated risk levels
SQALE maintainability rating:
| Rating | Debt ratio | What it means |
|---|---|---|
| A | ≤ 5% | Maintainability in excellent shape |
| B | 6–10% | Small debt — manageable with routine hygiene |
| C | 11–20% | Significant debt — proactive remediation needed |
| D | 21–50% | High debt — serious maintenance burden |
| E | > 50% | Extreme debt — potentially untestable/unmaintainable |
Path from C to A — highest-leverage actions:
① Remove duplicated code blocks (SonarQube often assigns 30–60 min per duplication violation)
② Reduce cognitive complexity in the highest-scoring functions
③ Fix naming violations and magic numbers (fast wins; many small issues add up)
④ Set a new-debt quality gate: prevent the ratio from increasing while old debt is paid down
Reporting language:
• "At 18% debt ratio, we're about 180 developer-days of remediation work from a clean codebase."
• "Our target is the A band — below 5% — which would require approximately 130 days of focused remediation."
• "If we allocate 10% of each sprint to debt remediation, we can reach the A band in about 18 months."
Key vocabulary:
• Debt ratio — remediation cost ÷ estimated development cost, as a percentage
• SQALE rating — SonarQube's A–E maintainability grade derived from debt ratio
• Remediation cost — the estimated developer time needed to fix a specific code issue
• Debt band — a named category of debt ratio ranges (A through E) with associated risk levels
2 / 25
A developer presents a technical debt item to the product manager: "This function has no unit tests, duplicated logic, and a cyclomatic complexity of 28. SonarQube estimates it will take 4.5 hours to fix the associated issues. But the real cost is the interest we're paying — every feature we add to this module takes twice as long as it should because of the existing mess." What does the "interest" metaphor communicate, and why is it persuasive for non-technical stakeholders?
The financial debt metaphor (coined by Ward Cunningham) is one of software engineering's most effective communication tools precisely because it translates technical concerns into business-familiar language.
The debt metaphor in full:
• Principal — the cost to fix the debt (4.5 hours in this example)
• Interest — the ongoing productivity slowdown on every piece of work that touches the debt
• Compound interest — when new features are built on top of debt, they inherit the debt and amplify its slowdown effect
• Bankruptcy — when debt accumulates to the point where the system must be rewritten from scratch
Why the interest framing is persuasive:
• It makes the cost ongoing and escalating, not a one-time expense
• It creates urgency: the longer you wait to pay the principal, the more interest accumulates
• It quantifies opportunity cost: if features take 2× longer, that's a concrete velocity impact
• Product managers understand loan interest — they don't need to understand cyclomatic complexity
How to make the interest cost concrete:
• "This module accounts for 3 features per sprint. If each takes 2× longer due to debt, we're losing 3 engineer-days per sprint — about 75 days per year — to interest payments."
• "Paying the 4.5-hour principal now saves an estimated 75 days of interest over the next year."
Key vocabulary:
• Technical debt principal — the one-time cost to fix or resolve the debt
• Technical debt interest — the ongoing productivity cost of leaving debt in place
• Compound interest (debt) — new work built on top of debt that inherits and amplifies the slowdown
• Velocity tax — the recurring slowdown on feature delivery caused by accumulated technical debt
The debt metaphor in full:
• Principal — the cost to fix the debt (4.5 hours in this example)
• Interest — the ongoing productivity slowdown on every piece of work that touches the debt
• Compound interest — when new features are built on top of debt, they inherit the debt and amplify its slowdown effect
• Bankruptcy — when debt accumulates to the point where the system must be rewritten from scratch
Why the interest framing is persuasive:
• It makes the cost ongoing and escalating, not a one-time expense
• It creates urgency: the longer you wait to pay the principal, the more interest accumulates
• It quantifies opportunity cost: if features take 2× longer, that's a concrete velocity impact
• Product managers understand loan interest — they don't need to understand cyclomatic complexity
How to make the interest cost concrete:
• "This module accounts for 3 features per sprint. If each takes 2× longer due to debt, we're losing 3 engineer-days per sprint — about 75 days per year — to interest payments."
• "Paying the 4.5-hour principal now saves an estimated 75 days of interest over the next year."
Key vocabulary:
• Technical debt principal — the one-time cost to fix or resolve the debt
• Technical debt interest — the ongoing productivity cost of leaving debt in place
• Compound interest (debt) — new work built on top of debt that inherits and amplifies the slowdown
• Velocity tax — the recurring slowdown on feature delivery caused by accumulated technical debt
3 / 25
During sprint planning, the engineering manager says: "Let's review the technical debt backlog. I want to prioritise items based on cost to fix vs. cost of delay — not just by how annoying they are to live with." What is a technical debt backlog, and what does "cost of delay" mean in this context?
Prioritising technical debt by "cost of fix vs. cost of delay" is a data-driven approach that treats debt remediation decisions with the same economic rigour as feature prioritisation decisions.
The two-dimensional prioritisation framework:
Signals of high cost of delay:
• The debt is in a file that is modified frequently (high churn)
• The debt is blocking a planned feature or architecture change
• The debt is in a security or compliance-critical area
• The debt is causing recurring on-call incidents
• The debt is making onboarding new team members significantly harder
Technical debt backlog item structure (best practice):
• Description of the issue and which files are affected
• Estimated fix time (from SonarQube or team estimate)
• Cost of delay rationale: why does this need to be fixed now vs. later?
• Expected outcome: what improves after this debt is resolved?
Key vocabulary:
• Technical debt backlog — a curated list of known debt items prioritised for future remediation
• Cost of delay — the ongoing business and productivity cost of not fixing a debt item
• Boy scout rule — leaving the codebase slightly better than you found it; cleaning up small debt opportunistically
• Remediation ROI — the ratio of productivity gain to fix cost; used to prioritise debt items
The two-dimensional prioritisation framework:
| Quadrant | Cost to fix | Cost of delay | Action |
|---|---|---|---|
| High value | Low | High | Fix immediately — best ROI |
| Invest carefully | High | High | Schedule a dedicated remediation sprint |
| Low priority | Low | Low | Fix opportunistically (boy scout rule) |
| Leave alone | High | Low | Rarely touched; not worth the risk of change |
Signals of high cost of delay:
• The debt is in a file that is modified frequently (high churn)
• The debt is blocking a planned feature or architecture change
• The debt is in a security or compliance-critical area
• The debt is causing recurring on-call incidents
• The debt is making onboarding new team members significantly harder
Technical debt backlog item structure (best practice):
• Description of the issue and which files are affected
• Estimated fix time (from SonarQube or team estimate)
• Cost of delay rationale: why does this need to be fixed now vs. later?
• Expected outcome: what improves after this debt is resolved?
Key vocabulary:
• Technical debt backlog — a curated list of known debt items prioritised for future remediation
• Cost of delay — the ongoing business and productivity cost of not fixing a debt item
• Boy scout rule — leaving the codebase slightly better than you found it; cleaning up small debt opportunistically
• Remediation ROI — the ratio of productivity gain to fix cost; used to prioritise debt items
4 / 25
A CTO presents to the board: "We've identified three categories of technical debt in our platform: deliberate debt we took on knowingly to hit last quarter's launch deadline, inadvertent debt from code written before we had code review standards, and bit rot — code that was fine when written but has become outdated as dependencies and practices evolved." Why is distinguishing between these three categories important for remediation planning?
The technical debt taxonomy (deliberate, inadvertent, bit rot) was developed to help teams recognise that different debt types require fundamentally different responses — the same remediation approach does not work for all three.
The three debt types in detail:
Why this categorisation matters to stakeholders:
• Deliberate debt has a clear repayment commitment — the board can hold engineering accountable to a timeline
• Inadvertent debt reveals process gaps — prevention investment is the right response, not just cleanup
• Bit rot is predictable and preventable — regular "maintenance sprints" catch it before it becomes critical
Communication language for board presentations:
• "Our deliberate debt from Q3 is fully inventoried — we've scheduled 6 weeks of repayment in Q1."
• "The inadvertent debt reflects a period before we had code review standards — we've since implemented linting and mandatory reviews."
• "Bit rot in the authentication layer will be addressed in a modernisation sprint before the v4.0 release."
Key vocabulary:
• Deliberate debt — a known, intentional trade-off accepted to meet a deadline; should be documented and scheduled for repayment
• Inadvertent debt — poor quality code created without awareness; prevented by improving team practices
• Bit rot — previously correct code that has become outdated as the ecosystem around it evolved
• Strangler fig pattern — incrementally replacing a legacy system by building new functionality around it
The three debt types in detail:
| Type | Origin | Prevention | Remediation |
|---|---|---|---|
| Deliberate | Intentional shortcut taken knowingly | Track and repay explicitly; don't let it become inadvertent | Schedule before next build in same area |
| Inadvertent | Poor code quality without awareness | Linting, code review standards, training | Address through quality gate improvements and team practices |
| Bit rot | Good code made obsolete by time | Dependency management process; regular update sprints | Planned modernisation sprints; strangler fig pattern |
Why this categorisation matters to stakeholders:
• Deliberate debt has a clear repayment commitment — the board can hold engineering accountable to a timeline
• Inadvertent debt reveals process gaps — prevention investment is the right response, not just cleanup
• Bit rot is predictable and preventable — regular "maintenance sprints" catch it before it becomes critical
Communication language for board presentations:
• "Our deliberate debt from Q3 is fully inventoried — we've scheduled 6 weeks of repayment in Q1."
• "The inadvertent debt reflects a period before we had code review standards — we've since implemented linting and mandatory reviews."
• "Bit rot in the authentication layer will be addressed in a modernisation sprint before the v4.0 release."
Key vocabulary:
• Deliberate debt — a known, intentional trade-off accepted to meet a deadline; should be documented and scheduled for repayment
• Inadvertent debt — poor quality code created without awareness; prevented by improving team practices
• Bit rot — previously correct code that has become outdated as the ecosystem around it evolved
• Strangler fig pattern — incrementally replacing a legacy system by building new functionality around it
5 / 25
An engineering manager proposes a new policy to the team: "We're introducing a 20% debt budget — every sprint, 20% of capacity is ring-fenced for technical debt remediation. This is not optional and it's not negotiable with product. The goal is to stop debt from compounding." What does "debt compounding" mean, and why does ring-fencing capacity prevent it?
Technical debt compounding is one of the most important and least understood dynamics in software engineering — it explains why ignored debt becomes exponentially more expensive over time.
How debt compounds:
① Feature A is built on top of poorly structured Module X (existing debt)
② Feature A is harder to implement, takes longer, and introduces new code smells — adding new debt
③ Feature B is built on top of Module X and Feature A — inheriting debt from both
④ Each subsequent feature that touches this area carries the full weight of all accumulated debt
⑤ The codebase becomes progressively harder to modify, test, and extend — velocity declines over time
Why ring-fencing debt capacity works:
• Without a protected budget, debt remediation is always de-prioritised when sprint capacity is under pressure
• A fixed allocation (20%) makes debt repayment a non-negotiable structural commitment rather than an aspiration
• Continuous small debt payments prevent large accumulations that require expensive heroic remediation efforts
• The 20% investment typically returns 30–50% in improved delivery velocity for features touching the cleaned-up areas
Negotiating the debt budget with product:
• "Without 20% debt budget, we're borrowing velocity from our future selves at compound interest."
• "The 20% debt investment will deliver a net velocity increase of 30% within two quarters."
• "We can show you the correlation: sprints with no debt work have higher velocity short-term but higher defect rates the following sprint."
Key vocabulary:
• Debt compounding — the process by which existing debt makes new features more complex, generating additional debt
• Debt budget — a ring-fenced portion of sprint capacity allocated to technical debt remediation
• Ring-fenced — allocated for a specific purpose and protected from reallocation to other priorities
• Velocity tax — the recurring slowdown in feature delivery caused by accumulated technical debt
How debt compounds:
① Feature A is built on top of poorly structured Module X (existing debt)
② Feature A is harder to implement, takes longer, and introduces new code smells — adding new debt
③ Feature B is built on top of Module X and Feature A — inheriting debt from both
④ Each subsequent feature that touches this area carries the full weight of all accumulated debt
⑤ The codebase becomes progressively harder to modify, test, and extend — velocity declines over time
Why ring-fencing debt capacity works:
• Without a protected budget, debt remediation is always de-prioritised when sprint capacity is under pressure
• A fixed allocation (20%) makes debt repayment a non-negotiable structural commitment rather than an aspiration
• Continuous small debt payments prevent large accumulations that require expensive heroic remediation efforts
• The 20% investment typically returns 30–50% in improved delivery velocity for features touching the cleaned-up areas
Negotiating the debt budget with product:
• "Without 20% debt budget, we're borrowing velocity from our future selves at compound interest."
• "The 20% debt investment will deliver a net velocity increase of 30% within two quarters."
• "We can show you the correlation: sprints with no debt work have higher velocity short-term but higher defect rates the following sprint."
Key vocabulary:
• Debt compounding — the process by which existing debt makes new features more complex, generating additional debt
• Debt budget — a ring-fenced portion of sprint capacity allocated to technical debt remediation
• Ring-fenced — allocated for a specific purpose and protected from reallocation to other priorities
• Velocity tax — the recurring slowdown in feature delivery caused by accumulated technical debt
6 / 25
During a Slack discussion about a new API endpoint, a developer posts: "Just finished implementing this feature. The response time is consistently slow – around 3 seconds. I've profiled the code and it's hitting a database query with a high number of joins. SonarQube flags this as 'High Complexity' and estimates a potential technical debt contribution of 25% to refactor.". What does SonarQube's "High Complexity" flag, combined with a 25% debt estimate, primarily indicate in this situation?
The SonarQube "High Complexity" flag combined with a debt estimate isn't just about the query itself. It signals that the complexity of the code *and* its potential impact on future maintenance and development time are elevated. The 25% debt estimate reflects the anticipated effort to address those issues, acknowledging the risk of increased future costs if not tackled proactively – it's a warning against compounding technical debt.
7 / 25
A developer submits a pull request containing a large function with significant duplication and complex conditional logic. The team's automated code quality tool, CodeClimate, reports a 'High Technical Debt' score of 32% for this function. During the subsequent review, a senior engineer explains to the junior developer: "This isn't just about fixing the immediate problem; it's about preventing future issues and maintaining the long-term health of the codebase." What is the *primary* concern driving the senior engineer's statement, beyond simply resolving the current technical debt?
The correct answer is B. While a complex function can indeed pose deployment risks (A), the core concern here is about the *long-term* impact of technical debt – slowing down future development and increasing bug risk. The 'High Technical Debt' score isn't solely a measure of immediate problems, but rather an indicator that the codebase is becoming increasingly fragile and difficult to maintain. Options C and D are misinterpretations of what a 'High Technical Debt' score signifies; it doesn't automatically equate to incompetence or security vulnerabilities.
8 / 25
Sarah is reviewing a PR for a new microservice. The developer has implemented a complex algorithm using nested loops and switch statements, resulting in a cyclomatic complexity of 15. SonarQube flags this code with a 'Moderate Technical Debt' score of 12% and suggests refactoring. During the review, another engineer comments: 'This looks like it could become a major headache later if we need to add new features or change the logic.' What does this comment primarily highlight regarding the flagged technical debt?
The core issue isn't just the current debt score of 12%, but the *potential* for that score to increase significantly if the code is modified. The engineer is concerned about 'future-proofing' the codebase – the comment emphasizes the risk of increased complexity and difficulty in future development, which is a key aspect of technical debt management. The debt score itself is just a metric reflecting this potential; it's the *risk* that matters most.
9 / 25
During a code review, Liam points to a large, undocumented function and says, "SonarQube is flagging this with a 'Critical' debt score of 38% – it's heavily reliant on global variables and has no clear separation of concerns. It feels like we're building a house on sand.". Maria, the junior developer, replies, "But SonarQube just says it's complex; I can refactor it in an afternoon." What is Maria *primarily* misunderstanding about the 'Critical' debt score and Liam's comment?
Maria misunderstands that a 'Critical' debt score isn't just about lines of code or algorithmic complexity. It represents a quantifiable risk – potential instability, increased maintenance costs, and difficulty in future feature additions due to the function's design flaws. Liam is highlighting this systemic risk, emphasizing that the codebase's fragility could significantly impact long-term development velocity and stability, far beyond what a simple refactoring might address.
10 / 25
During a sprint retrospective, the team discusses recurring performance issues with a core service. The DevOps lead shares a graph showing a steady increase in database query execution time over the past six months. SonarQube's analysis of this service reveals a 'High' technical debt score of 28%, primarily due to deeply nested SQL queries and a lack of indexing. Mark, a junior developer, asks: 'So, what exactly *is* a 'high' debt score in this context?'
The 'High' debt score isn't just about code complexity; it quantifies the *risk* associated with that complexity. It represents an estimated cost – in developer time and resources – of addressing the performance issues and refactoring the codebase if those problems aren't resolved promptly. Misunderstanding this links the score to potential future costs, not just a simple measure of bad code.
11 / 25
During a Slack discussion about a new API endpoint, a developer posts: "Just finished implementing this feature. The response time is consistently slow – around 3 seconds. I've profiled the code and it's hitting a database query with a high number of joins. SonarQube flags this as 'High Complexity' and estimates a potential technical debt contribution of 25% to refactor.". What does SonarQube's "High Complexity" flag, combined with a 25% debt estimate, primarily indicate in this situation?
The SonarQube "High Complexity" flag combined with a debt estimate isn't just about the query itself. It signals that the complexity of the code *and* its potential impact on future maintenance and development time are elevated. The 25% debt estimate reflects the anticipated effort to address those issues, acknowledging the risk of increased future costs if not tackled proactively – it's a warning against compounding technical debt.
12 / 25
A developer submits a pull request containing a large function with significant duplication and complex conditional logic. The team's automated code quality tool, CodeClimate, reports a 'High Technical Debt' score of 32% for this function. During the subsequent review, a senior engineer explains to the junior developer: "This isn't just about fixing the immediate problem; it's about preventing future issues and maintaining the long-term health of the codebase." What is the *primary* concern driving the senior engineer's statement, beyond simply resolving the current technical debt?
The correct answer is B. While a complex function can indeed pose deployment risks (A), the core concern here is about the *long-term* impact of technical debt – slowing down future development and increasing bug risk. The 'High Technical Debt' score isn't solely a measure of immediate problems, but rather an indicator that the codebase is becoming increasingly fragile and difficult to maintain. Options C and D are misinterpretations of what a 'High Technical Debt' score signifies; it doesn't automatically equate to incompetence or security vulnerabilities.
13 / 25
Sarah is reviewing a PR for a new microservice. The developer has implemented a complex algorithm using nested loops and switch statements, resulting in a cyclomatic complexity of 15. SonarQube flags this code with a 'Moderate Technical Debt' score of 12% and suggests refactoring. During the review, another engineer comments: 'This looks like it could become a major headache later if we need to add new features or change the logic.' What does this comment primarily highlight regarding the flagged technical debt?
The core issue isn't just the current debt score of 12%, but the *potential* for that score to increase significantly if the code is modified. The engineer is concerned about 'future-proofing' the codebase – the comment emphasizes the risk of increased complexity and difficulty in future development, which is a key aspect of technical debt management. The debt score itself is just a metric reflecting this potential; it's the *risk* that matters most.
14 / 25
During a code review, Liam points to a large, undocumented function and says, "SonarQube is flagging this with a 'Critical' debt score of 38% – it's heavily reliant on global variables and has no clear separation of concerns. It feels like we're building a house on sand.". Maria, the junior developer, replies, "But SonarQube just says it's complex; I can refactor it in an afternoon." What is Maria *primarily* misunderstanding about the 'Critical' debt score and Liam's comment?
Maria misunderstands that a 'Critical' debt score isn't just about lines of code or algorithmic complexity. It represents a quantifiable risk – potential instability, increased maintenance costs, and difficulty in future feature additions due to the function's design flaws. Liam is highlighting this systemic risk, emphasizing that the codebase's fragility could significantly impact long-term development velocity and stability, far beyond what a simple refactoring might address.
15 / 25
During a sprint retrospective, the team discusses recurring performance issues with a core service. The DevOps lead shares a graph showing a steady increase in database query execution time over the past six months. SonarQube's analysis of this service reveals a 'High' technical debt score of 28%, primarily due to deeply nested SQL queries and a lack of indexing. Mark, a junior developer, asks: 'So, what exactly *is* a 'high' debt score in this context?'
The 'High' debt score isn't just about code complexity; it quantifies the *risk* associated with that complexity. It represents an estimated cost – in developer time and resources – of addressing the performance issues and refactoring the codebase if those problems aren't resolved promptly. Misunderstanding this links the score to potential future costs, not just a simple measure of bad code.
16 / 25
During a Slack discussion about a new API endpoint, a developer posts: "Just finished implementing this feature. The response time is consistently slow – around 3 seconds. I've profiled the code and it's hitting a database query with a high number of joins. SonarQube flags this as 'High Complexity' and estimates a potential technical debt contribution of 25% to refactor.". What does SonarQube's "High Complexity" flag, combined with a 25% debt estimate, primarily indicate in this situation?
The SonarQube "High Complexity" flag combined with a debt estimate isn't just about the query itself. It signals that the complexity of the code *and* its potential impact on future maintenance and development time are elevated. The 25% debt estimate reflects the anticipated effort to address those issues, acknowledging the risk of increased future costs if not tackled proactively – it's a warning against compounding technical debt.
17 / 25
A developer submits a pull request containing a large function with significant duplication and complex conditional logic. The team's automated code quality tool, CodeClimate, reports a 'High Technical Debt' score of 32% for this function. During the subsequent review, a senior engineer explains to the junior developer: "This isn't just about fixing the immediate problem; it's about preventing future issues and maintaining the long-term health of the codebase." What is the *primary* concern driving the senior engineer's statement, beyond simply resolving the current technical debt?
The correct answer is B. While a complex function can indeed pose deployment risks (A), the core concern here is about the *long-term* impact of technical debt – slowing down future development and increasing bug risk. The 'High Technical Debt' score isn't solely a measure of immediate problems, but rather an indicator that the codebase is becoming increasingly fragile and difficult to maintain. Options C and D are misinterpretations of what a 'High Technical Debt' score signifies; it doesn't automatically equate to incompetence or security vulnerabilities.
18 / 25
Sarah is reviewing a PR for a new microservice. The developer has implemented a complex algorithm using nested loops and switch statements, resulting in a cyclomatic complexity of 15. SonarQube flags this code with a 'Moderate Technical Debt' score of 12% and suggests refactoring. During the review, another engineer comments: 'This looks like it could become a major headache later if we need to add new features or change the logic.' What does this comment primarily highlight regarding the flagged technical debt?
The core issue isn't just the current debt score of 12%, but the *potential* for that score to increase significantly if the code is modified. The engineer is concerned about 'future-proofing' the codebase – the comment emphasizes the risk of increased complexity and difficulty in future development, which is a key aspect of technical debt management. The debt score itself is just a metric reflecting this potential; it's the *risk* that matters most.
19 / 25
During a code review, Liam points to a large, undocumented function and says, "SonarQube is flagging this with a 'Critical' debt score of 38% – it's heavily reliant on global variables and has no clear separation of concerns. It feels like we're building a house on sand.". Maria, the junior developer, replies, "But SonarQube just says it's complex; I can refactor it in an afternoon." What is Maria *primarily* misunderstanding about the 'Critical' debt score and Liam's comment?
Maria misunderstands that a 'Critical' debt score isn't just about lines of code or algorithmic complexity. It represents a quantifiable risk – potential instability, increased maintenance costs, and difficulty in future feature additions due to the function's design flaws. Liam is highlighting this systemic risk, emphasizing that the codebase's fragility could significantly impact long-term development velocity and stability, far beyond what a simple refactoring might address.
20 / 25
During a sprint retrospective, the team discusses recurring performance issues with a core service. The DevOps lead shares a graph showing a steady increase in database query execution time over the past six months. SonarQube's analysis of this service reveals a 'High' technical debt score of 28%, primarily due to deeply nested SQL queries and a lack of indexing. Mark, a junior developer, asks: 'So, what exactly *is* a 'high' debt score in this context?'
The 'High' debt score isn't just about code complexity; it quantifies the *risk* associated with that complexity. It represents an estimated cost – in developer time and resources – of addressing the performance issues and refactoring the codebase if those problems aren't resolved promptly. Misunderstanding this links the score to potential future costs, not just a simple measure of bad code.
21 / 25
During a Slack discussion about a new API endpoint, a developer posts: "Just finished implementing this feature. The response time is consistently slow – around 3 seconds. I've profiled the code and it's hitting a database query with a high number of joins. SonarQube flags this as 'High Complexity' and estimates a potential technical debt contribution of 25% to refactor.". What does SonarQube's "High Complexity" flag, combined with a 25% debt estimate, primarily indicate in this situation?
The SonarQube "High Complexity" flag combined with a debt estimate isn't just about the query itself. It signals that the complexity of the code *and* its potential impact on future maintenance and development time are elevated. The 25% debt estimate reflects the anticipated effort to address those issues, acknowledging the risk of increased future costs if not tackled proactively – it's a warning against compounding technical debt.
22 / 25
A developer submits a pull request containing a large function with significant duplication and complex conditional logic. The team's automated code quality tool, CodeClimate, reports a 'High Technical Debt' score of 32% for this function. During the subsequent review, a senior engineer explains to the junior developer: "This isn't just about fixing the immediate problem; it's about preventing future issues and maintaining the long-term health of the codebase." What is the *primary* concern driving the senior engineer's statement, beyond simply resolving the current technical debt?
The correct answer is B. While a complex function can indeed pose deployment risks (A), the core concern here is about the *long-term* impact of technical debt – slowing down future development and increasing bug risk. The 'High Technical Debt' score isn't solely a measure of immediate problems, but rather an indicator that the codebase is becoming increasingly fragile and difficult to maintain. Options C and D are misinterpretations of what a 'High Technical Debt' score signifies; it doesn't automatically equate to incompetence or security vulnerabilities.
23 / 25
Sarah is reviewing a PR for a new microservice. The developer has implemented a complex algorithm using nested loops and switch statements, resulting in a cyclomatic complexity of 15. SonarQube flags this code with a 'Moderate Technical Debt' score of 12% and suggests refactoring. During the review, another engineer comments: 'This looks like it could become a major headache later if we need to add new features or change the logic.' What does this comment primarily highlight regarding the flagged technical debt?
The core issue isn't just the current debt score of 12%, but the *potential* for that score to increase significantly if the code is modified. The engineer is concerned about 'future-proofing' the codebase – the comment emphasizes the risk of increased complexity and difficulty in future development, which is a key aspect of technical debt management. The debt score itself is just a metric reflecting this potential; it's the *risk* that matters most.
24 / 25
During a code review, Liam points to a large, undocumented function and says, "SonarQube is flagging this with a 'Critical' debt score of 38% – it's heavily reliant on global variables and has no clear separation of concerns. It feels like we're building a house on sand.". Maria, the junior developer, replies, "But SonarQube just says it's complex; I can refactor it in an afternoon." What is Maria *primarily* misunderstanding about the 'Critical' debt score and Liam's comment?
Maria misunderstands that a 'Critical' debt score isn't just about lines of code or algorithmic complexity. It represents a quantifiable risk – potential instability, increased maintenance costs, and difficulty in future feature additions due to the function's design flaws. Liam is highlighting this systemic risk, emphasizing that the codebase's fragility could significantly impact long-term development velocity and stability, far beyond what a simple refactoring might address.
25 / 25
During a sprint retrospective, the team discusses recurring performance issues with a core service. The DevOps lead shares a graph showing a steady increase in database query execution time over the past six months. SonarQube's analysis of this service reveals a 'High' technical debt score of 28%, primarily due to deeply nested SQL queries and a lack of indexing. Mark, a junior developer, asks: 'So, what exactly *is* a 'high' debt score in this context?'
The 'High' debt score isn't just about code complexity; it quantifies the *risk* associated with that complexity. It represents an estimated cost – in developer time and resources – of addressing the performance issues and refactoring the codebase if those problems aren't resolved promptly. Misunderstanding this links the score to potential future costs, not just a simple measure of bad code.
Frequently Asked Questions
What does the "Technical Debt Metrics" exercise practise?
Practice English vocabulary for technical debt metrics: debt ratio, remediation cost, debt interest metaphor, debt compounding, and backlog prioritisation language. 5 exercises.
How many questions are in this exercise?
This exercise has 25 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 Metrics" 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.