Advanced
Code Quality
#dora-metrics
#deployment-frequency
#mttr
#lead-time
DORA Metrics Communication Language
5 exercises — master the English vocabulary engineers and managers use when discussing DORA metrics: deployment frequency, lead time, MTTR, and change failure rate.
0 / 41 completed
1 / 41
An engineering director opens the quarterly review meeting with: "Our deployment frequency is currently weekly. The goal for next quarter is to reach on-demand deployment — multiple times per day. What changes do we need to enable that?" What is deployment frequency and why does the director frame it as a capability goal?
Deployment frequency is one of the four DORA (DevOps Research and Assessment) metrics established by Google DORA research as the strongest predictors of software delivery performance and organisational outcomes.
The four DORA metrics:
Why "on-demand" requires capability building:
• Automated test suite with high coverage (fast safety net for each deployment)
• CI/CD pipeline that deploys automatically on every merge to main
• Feature flags to separate deployment from release
• Trunk-based development (short-lived branches, frequent integration)
• Observability to detect and recover quickly from failures
Language for DORA discussions:
• "We're currently in the 'high' performer band for deployment frequency; elite is on-demand."
• "To increase deployment frequency, we need to invest in test automation first."
Key vocabulary:
• Deployment frequency — how often an organisation successfully deploys to production
• On-demand deployment — the elite DORA benchmark: deploying whenever ready, multiple times per day
• DORA metrics — the four key engineering performance indicators from Google's DevOps research
• Capability goal — a target that requires building new engineering practices, not just more effort
The four DORA metrics:
| Metric | What it measures | Elite benchmark |
|---|---|---|
| Deployment frequency | How often code is deployed to production | Multiple times per day (on-demand) |
| Lead time for changes | Time from commit to production | Less than one hour |
| Change failure rate | % of deployments causing incidents | 0–15% |
| MTTR (time to restore) | Time to recover from a failure | Less than one hour |
Why "on-demand" requires capability building:
• Automated test suite with high coverage (fast safety net for each deployment)
• CI/CD pipeline that deploys automatically on every merge to main
• Feature flags to separate deployment from release
• Trunk-based development (short-lived branches, frequent integration)
• Observability to detect and recover quickly from failures
Language for DORA discussions:
• "We're currently in the 'high' performer band for deployment frequency; elite is on-demand."
• "To increase deployment frequency, we need to invest in test automation first."
Key vocabulary:
• Deployment frequency — how often an organisation successfully deploys to production
• On-demand deployment — the elite DORA benchmark: deploying whenever ready, multiple times per day
• DORA metrics — the four key engineering performance indicators from Google's DevOps research
• Capability goal — a target that requires building new engineering practices, not just more effort
2 / 41
In a sprint review, the team lead presents: "Our lead time for changes is currently averaging 12 days. That means a feature a developer commits today won't reach production for nearly two weeks. We need to understand what's blocking the pipeline." What does lead time for changes measure, and how would you discuss this with management?
Lead time for changes is arguably the DORA metric that best exposes pipeline bottlenecks because it measures the total elapsed time across all delivery stages from commit to production.
DORA performance bands for lead time:
Common sources of lead time delay (value stream mapping):
① Code review queue — PRs waiting hours or days for reviewers
② Long-running CI — test suites taking 45–90 minutes discourages frequent integration
③ Manual approval gates — human sign-off required before staging/production promotion
④ Release windows — deployments only allowed on specific days/times
⑤ Staging environment contention — shared environments with booking queues
Reporting to management:
• "Our lead time of 12 days places us in the medium performer band; elite performers average under an hour."
• "We've mapped the value stream and found that 8 of the 12 days are spent waiting in the code review queue and staging environment."
• "Investing in parallel test environments and a review SLA policy would cut lead time by an estimated 60%."
Key vocabulary:
• Lead time for changes — elapsed time from code commit to code running in production
• Blocking the pipeline — a stage in the delivery process that causes code to wait, increasing lead time
• Value stream mapping — a technique to visualise all stages of the delivery process and identify waste
• Performance band — the DORA classification of teams into elite, high, medium, or low performers
DORA performance bands for lead time:
| Band | Lead time |
|---|---|
| Elite | Less than one hour |
| High | Between one day and one week |
| Medium | Between one week and one month |
| Low | More than one month |
Common sources of lead time delay (value stream mapping):
① Code review queue — PRs waiting hours or days for reviewers
② Long-running CI — test suites taking 45–90 minutes discourages frequent integration
③ Manual approval gates — human sign-off required before staging/production promotion
④ Release windows — deployments only allowed on specific days/times
⑤ Staging environment contention — shared environments with booking queues
Reporting to management:
• "Our lead time of 12 days places us in the medium performer band; elite performers average under an hour."
• "We've mapped the value stream and found that 8 of the 12 days are spent waiting in the code review queue and staging environment."
• "Investing in parallel test environments and a review SLA policy would cut lead time by an estimated 60%."
Key vocabulary:
• Lead time for changes — elapsed time from code commit to code running in production
• Blocking the pipeline — a stage in the delivery process that causes code to wait, increasing lead time
• Value stream mapping — a technique to visualise all stages of the delivery process and identify waste
• Performance band — the DORA classification of teams into elite, high, medium, or low performers
3 / 41
After a major production incident, the CTO asks in the post-mortem: "What was our MTTR on this one?" The on-call engineer replies: "Four hours from first alert to full service restoration." The CTO says: "That's in the medium performer band. We need to drive MTTR down systematically." What does MTTR mean in this context, and what does "drive MTTR down systematically" imply?
MTTR (Mean Time to Restore) is one of the most operationally important DORA metrics because it measures an organisation's resilience and recovery capability when things inevitably go wrong.
MTTR performance bands (DORA):
"Drive MTTR down systematically" — key capabilities:
• Observability: structured logging, distributed tracing, dashboards — detect failures in seconds, not minutes
• Alert quality: actionable alerts with runbook links; eliminate alert fatigue from noise
• Runbook automation: scripted recovery steps that on-call engineers execute (or that run automatically)
• Feature flags / kill switches: disable a broken feature in seconds without a deployment
• Rollback automation: one-command rollback to previous known-good deployment
• Game days / chaos engineering: practice incident recovery before real incidents happen
Post-mortem and management language:
• "MTTR was four hours — above our target. The delay was primarily in diagnosis, not recovery."
• "We're investing in structured logging to reduce time-to-diagnosis from hours to minutes."
• "Our MTTR improvement plan: feature flags deployed by Q2, automated rollback by Q3."
Key vocabulary:
• MTTR — Mean Time to Restore; average time from incident detection to full service recovery
• Drive MTTR down — systematically reduce average incident recovery time through engineering investments
• Observability — the ability to understand system internal state from external outputs (logs, metrics, traces)
• Kill switch — a feature flag that immediately disables a problematic feature without deployment
MTTR performance bands (DORA):
| Band | MTTR |
|---|---|
| Elite | Less than one hour |
| High | Less than one day |
| Medium | Less than one week |
| Low | More than one week |
"Drive MTTR down systematically" — key capabilities:
• Observability: structured logging, distributed tracing, dashboards — detect failures in seconds, not minutes
• Alert quality: actionable alerts with runbook links; eliminate alert fatigue from noise
• Runbook automation: scripted recovery steps that on-call engineers execute (or that run automatically)
• Feature flags / kill switches: disable a broken feature in seconds without a deployment
• Rollback automation: one-command rollback to previous known-good deployment
• Game days / chaos engineering: practice incident recovery before real incidents happen
Post-mortem and management language:
• "MTTR was four hours — above our target. The delay was primarily in diagnosis, not recovery."
• "We're investing in structured logging to reduce time-to-diagnosis from hours to minutes."
• "Our MTTR improvement plan: feature flags deployed by Q2, automated rollback by Q3."
Key vocabulary:
• MTTR — Mean Time to Restore; average time from incident detection to full service recovery
• Drive MTTR down — systematically reduce average incident recovery time through engineering investments
• Observability — the ability to understand system internal state from external outputs (logs, metrics, traces)
• Kill switch — a feature flag that immediately disables a problematic feature without deployment
4 / 41
A VP of Engineering presents to the board: "Our change failure rate has dropped from 23% to 8% over six months. This reflects our investment in automated testing and deployment practices, and it puts us firmly in the high performer band." What does change failure rate measure, and why is a reduction from 23% to 8% strategically significant?
Change failure rate directly measures the quality and stability of the deployment process — a high rate signals inadequate testing, poor release practices, or insufficient observability.
DORA performance bands for change failure rate:
Why 23% → 8% is strategically significant:
• At 23%: every 4th deployment requires emergency attention — on-call engineers are regularly pulled into unplanned incidents
• At 8%: roughly 1 in 12 deployments fails — on-call load significantly reduced; team can focus on features
• Each prevented failure avoids: incident response time, customer impact, post-mortem overhead, and reputational cost
What investments drive change failure rate down:
• Comprehensive automated test suites (unit, integration, end-to-end)
• Progressive delivery (canary deployments, feature flags) to limit blast radius
• Pre-production environments that accurately mirror production
• Static analysis and security scanning in the CI pipeline
Reporting language for management:
• "Our change failure rate improvement from 23% to 8% means our on-call engineers are responding to 3× fewer incidents."
• "We're now in the high performer band; our next focus is reducing MTTR to reach elite."
Key vocabulary:
• Change failure rate — the percentage of deployments that cause a production failure requiring remediation
• High performer band — a DORA classification for teams with strong but not yet elite delivery performance
• Blast radius — the scope of user and system impact when a deployment fails
• Progressive delivery — deploying changes gradually to a subset of users to limit failure blast radius
DORA performance bands for change failure rate:
| Band | Change failure rate |
|---|---|
| Elite | 0–15% |
| High | 0–15% (same range as elite; distinction is in other metrics) |
| Medium | 0–30% |
| Low | 16–30% or more |
Why 23% → 8% is strategically significant:
• At 23%: every 4th deployment requires emergency attention — on-call engineers are regularly pulled into unplanned incidents
• At 8%: roughly 1 in 12 deployments fails — on-call load significantly reduced; team can focus on features
• Each prevented failure avoids: incident response time, customer impact, post-mortem overhead, and reputational cost
What investments drive change failure rate down:
• Comprehensive automated test suites (unit, integration, end-to-end)
• Progressive delivery (canary deployments, feature flags) to limit blast radius
• Pre-production environments that accurately mirror production
• Static analysis and security scanning in the CI pipeline
Reporting language for management:
• "Our change failure rate improvement from 23% to 8% means our on-call engineers are responding to 3× fewer incidents."
• "We're now in the high performer band; our next focus is reducing MTTR to reach elite."
Key vocabulary:
• Change failure rate — the percentage of deployments that cause a production failure requiring remediation
• High performer band — a DORA classification for teams with strong but not yet elite delivery performance
• Blast radius — the scope of user and system impact when a deployment fails
• Progressive delivery — deploying changes gradually to a subset of users to limit failure blast radius
5 / 41
During a quarterly business review, the engineering manager presents: "We're tracking all four DORA metrics. We're elite on deployment frequency and lead time, but medium on MTTR and change failure rate. This tells us our delivery speed is outpacing our stability practices." What insight is the manager communicating, and what should the team prioritise?
"Delivery speed outpacing stability practices" is a common and important DORA insight — elite performers excel across all four metrics simultaneously, not just the throughput metrics.
DORA metrics as two paired dimensions:
The key DORA research finding:
Elite performers are high on both dimensions simultaneously — speed and stability are not a trade-off. Teams that sacrifice stability to gain speed end up spending more time on incidents, and net throughput decreases over time.
Priority investments to improve stability metrics:
• For change failure rate: increase test coverage, add canary deployments, run pre-production smoke tests
• For MTTR: implement structured observability (metrics, logs, traces), write and test runbooks, add automated rollback
Language for this strategic conversation:
• "We've built elite delivery speed — now we need to match it with elite stability."
• "The instability is actually limiting our speed advantage: each incident pulls engineers off features."
• "Our Q3 OKR is to reach the high performer band on both MTTR and change failure rate."
Key vocabulary:
• Delivery speed — how fast the team moves code from development to production (throughput metrics)
• Stability practices — engineering disciplines that ensure deployments are reliable and recoverable
• Outpacing — moving faster in one area than a related area can support or sustain
• Elite performer — the top DORA band; teams that excel on all four metrics simultaneously
DORA metrics as two paired dimensions:
| Dimension | Metrics | This team's position |
|---|---|---|
| Throughput (speed) | Deployment frequency + Lead time | Elite — strong |
| Stability (reliability) | MTTR + Change failure rate | Medium — needs work |
The key DORA research finding:
Elite performers are high on both dimensions simultaneously — speed and stability are not a trade-off. Teams that sacrifice stability to gain speed end up spending more time on incidents, and net throughput decreases over time.
Priority investments to improve stability metrics:
• For change failure rate: increase test coverage, add canary deployments, run pre-production smoke tests
• For MTTR: implement structured observability (metrics, logs, traces), write and test runbooks, add automated rollback
Language for this strategic conversation:
• "We've built elite delivery speed — now we need to match it with elite stability."
• "The instability is actually limiting our speed advantage: each incident pulls engineers off features."
• "Our Q3 OKR is to reach the high performer band on both MTTR and change failure rate."
Key vocabulary:
• Delivery speed — how fast the team moves code from development to production (throughput metrics)
• Stability practices — engineering disciplines that ensure deployments are reliable and recoverable
• Outpacing — moving faster in one area than a related area can support or sustain
• Elite performer — the top DORA band; teams that excel on all four metrics simultaneously
6 / 41
Sarah: "Hey team, I've been reviewing the recent PRs for the new authentication module. Some of them are quite long – averaging around 800 lines – and have a lot of commented-out code. It's making it difficult to quickly understand the changes."
Mark (a senior developer) replies: "I agree, Sarah. I'm going to focus on reducing the size of these PRs and removing dead code during my review. We should aim for smaller, more focused commits, right?"Mark's response demonstrates an understanding of a core principle behind DORA metrics – the size and complexity of code changes. Large PRs often correlate with higher lead times and increased change failure rates due to difficulties in review and testing. While smaller commits are generally desirable, simply aiming for them without considering *why* the PR is large or containing commented-out code misses the strategic connection to overall system stability and efficiency – both key elements of DORA.
7 / 41
During a Slack conversation about a recent PR for a new API endpoint, Liam (a junior developer) writes: 'I've spent the last hour just trying to understand this code. It's so complex and there aren't really any comments explaining what it does!'. David (a senior developer), responding, suggests adding a short description of the endpoint's purpose to the PR title. What is David primarily addressing when suggesting this change?
David is focusing on improving *code readability* and *developer comprehension*. While good documentation is valuable, the immediate issue is that the PR itself lacks a clear description – a concise title or summary would drastically improve understanding. The other options represent tangential concerns: complex tools don't solve unclear code, coding standards are important but secondary to clarity, and increasing complexity isn't a goal when dealing with new APIs. This exercise reinforces the idea that DORA metrics ultimately relate back to developer productivity and efficiency.
8 / 41
During a code review discussion about a recently merged feature, Alex (a developer) says to Ben (another developer), "I'm seeing a lot of duplicated logic in this module. We're repeating the same calculation multiple times in different places. This increases the risk of errors and makes future changes harder to manage.". Ben responds by saying, "That's a good point. Let's investigate if we can refactor this to eliminate that duplication." What key DORA metric is Alex implicitly raising concern about?
Alex's comment directly relates to 'Code Quality', specifically highlighting duplicated logic. Duplicated code is a significant contributor to increased technical debt and makes the codebase harder to understand, test, and maintain – all factors impacting the long-term health of the system. The other options—throughput, deployment frequency, and lead time—are not the primary focus of Alex's concern in this specific scenario.
9 / 41
Maria, a developer, sends this message in a Slack channel after reviewing a PR:
'The tests for this feature are quite brittle – they rely heavily on specific data setups that are hard to maintain. I'm concerned about the long-term stability of this code if these test environments change.'
Which DORA metric is Maria *most* implicitly highlighting a concern about, and what's the core issue she identifies?
Maria is primarily concerned about Change Failure Rate. Brittle tests, which are overly sensitive to specific conditions and difficult to maintain, directly contribute to a higher likelihood of issues being discovered in production after deployment. This increased failure rate ultimately impacts the overall stability of the system, aligning with the definition of change failure rate as the percentage of deployments that cause an incident or require rollback.
10 / 41
Sarah: "Hey team, I've been reviewing the recent PRs for the new authentication module. Some of them are quite long – averaging around 800 lines – and have a lot of commented-out code. It's making it difficult to quickly understand the changes."
Mark (a senior developer) replies: "I agree, Sarah. I'm going to focus on reducing the size of these PRs and removing dead code during my review. We should aim for smaller, more focused commits, right?"Mark's response demonstrates an understanding of a core principle behind DORA metrics – the size and complexity of code changes. Large PRs often correlate with higher lead times and increased change failure rates due to difficulties in review and testing. While smaller commits are generally desirable, simply aiming for them without considering *why* the PR is large or containing commented-out code misses the strategic connection to overall system stability and efficiency – both key elements of DORA.
11 / 41
During a Slack conversation about a recent PR for a new API endpoint, Liam (a junior developer) writes: 'I've spent the last hour just trying to understand this code. It's so complex and there aren't really any comments explaining what it does!'. David (a senior developer), responding, suggests adding a short description of the endpoint's purpose to the PR title. What is David primarily addressing when suggesting this change?
David is focusing on improving *code readability* and *developer comprehension*. While good documentation is valuable, the immediate issue is that the PR itself lacks a clear description – a concise title or summary would drastically improve understanding. The other options represent tangential concerns: complex tools don't solve unclear code, coding standards are important but secondary to clarity, and increasing complexity isn't a goal when dealing with new APIs. This exercise reinforces the idea that DORA metrics ultimately relate back to developer productivity and efficiency.
12 / 41
During a code review discussion about a recently merged feature, Alex (a developer) says to Ben (another developer), "I'm seeing a lot of duplicated logic in this module. We're repeating the same calculation multiple times in different places. This increases the risk of errors and makes future changes harder to manage.". Ben responds by saying, "That's a good point. Let's investigate if we can refactor this to eliminate that duplication." What key DORA metric is Alex implicitly raising concern about?
Alex's comment directly relates to 'Code Quality', specifically highlighting duplicated logic. Duplicated code is a significant contributor to increased technical debt and makes the codebase harder to understand, test, and maintain – all factors impacting the long-term health of the system. The other options—throughput, deployment frequency, and lead time—are not the primary focus of Alex's concern in this specific scenario.
13 / 41
Maria, a developer, sends this message in a Slack channel after reviewing a PR:
'The tests for this feature are quite brittle – they rely heavily on specific data setups that are hard to maintain. I'm concerned about the long-term stability of this code if these test environments change.'
Which DORA metric is Maria *most* implicitly highlighting a concern about, and what's the core issue she identifies?
Maria is primarily concerned about Change Failure Rate. Brittle tests, which are overly sensitive to specific conditions and difficult to maintain, directly contribute to a higher likelihood of issues being discovered in production after deployment. This increased failure rate ultimately impacts the overall stability of the system, aligning with the definition of change failure rate as the percentage of deployments that cause an incident or require rollback.
14 / 41
Sarah: "Hey team, I've been reviewing the recent PRs for the new authentication module. Some of them are quite long – averaging around 800 lines – and have a lot of commented-out code. It's making it difficult to quickly understand the changes."
Mark (a senior developer) replies: "I agree, Sarah. I'm going to focus on reducing the size of these PRs and removing dead code during my review. We should aim for smaller, more focused commits, right?"Mark's response demonstrates an understanding of a core principle behind DORA metrics – the size and complexity of code changes. Large PRs often correlate with higher lead times and increased change failure rates due to difficulties in review and testing. While smaller commits are generally desirable, simply aiming for them without considering *why* the PR is large or containing commented-out code misses the strategic connection to overall system stability and efficiency – both key elements of DORA.
15 / 41
During a Slack conversation about a recent PR for a new API endpoint, Liam (a junior developer) writes: 'I've spent the last hour just trying to understand this code. It's so complex and there aren't really any comments explaining what it does!'. David (a senior developer), responding, suggests adding a short description of the endpoint's purpose to the PR title. What is David primarily addressing when suggesting this change?
David is focusing on improving *code readability* and *developer comprehension*. While good documentation is valuable, the immediate issue is that the PR itself lacks a clear description – a concise title or summary would drastically improve understanding. The other options represent tangential concerns: complex tools don't solve unclear code, coding standards are important but secondary to clarity, and increasing complexity isn't a goal when dealing with new APIs. This exercise reinforces the idea that DORA metrics ultimately relate back to developer productivity and efficiency.
16 / 41
During a code review discussion about a recently merged feature, Alex (a developer) says to Ben (another developer), "I'm seeing a lot of duplicated logic in this module. We're repeating the same calculation multiple times in different places. This increases the risk of errors and makes future changes harder to manage.". Ben responds by saying, "That's a good point. Let's investigate if we can refactor this to eliminate that duplication." What key DORA metric is Alex implicitly raising concern about?
Alex's comment directly relates to 'Code Quality', specifically highlighting duplicated logic. Duplicated code is a significant contributor to increased technical debt and makes the codebase harder to understand, test, and maintain – all factors impacting the long-term health of the system. The other options—throughput, deployment frequency, and lead time—are not the primary focus of Alex's concern in this specific scenario.
17 / 41
Maria, a developer, sends this message in a Slack channel after reviewing a PR:
'The tests for this feature are quite brittle – they rely heavily on specific data setups that are hard to maintain. I'm concerned about the long-term stability of this code if these test environments change.'
Which DORA metric is Maria *most* implicitly highlighting a concern about, and what's the core issue she identifies?
Maria is primarily concerned about Change Failure Rate. Brittle tests, which are overly sensitive to specific conditions and difficult to maintain, directly contribute to a higher likelihood of issues being discovered in production after deployment. This increased failure rate ultimately impacts the overall stability of the system, aligning with the definition of change failure rate as the percentage of deployments that cause an incident or require rollback.
18 / 41
Sarah: "Hey team, I've been reviewing the recent PRs for the new authentication module. Some of them are quite long – averaging around 800 lines – and have a lot of commented-out code. It's making it difficult to quickly understand the changes."
Mark (a senior developer) replies: "I agree, Sarah. I'm going to focus on reducing the size of these PRs and removing dead code during my review. We should aim for smaller, more focused commits, right?"Mark's response demonstrates an understanding of a core principle behind DORA metrics – the size and complexity of code changes. Large PRs often correlate with higher lead times and increased change failure rates due to difficulties in review and testing. While smaller commits are generally desirable, simply aiming for them without considering *why* the PR is large or containing commented-out code misses the strategic connection to overall system stability and efficiency – both key elements of DORA.
19 / 41
During a Slack conversation about a recent PR for a new API endpoint, Liam (a junior developer) writes: 'I've spent the last hour just trying to understand this code. It's so complex and there aren't really any comments explaining what it does!'. David (a senior developer), responding, suggests adding a short description of the endpoint's purpose to the PR title. What is David primarily addressing when suggesting this change?
David is focusing on improving *code readability* and *developer comprehension*. While good documentation is valuable, the immediate issue is that the PR itself lacks a clear description – a concise title or summary would drastically improve understanding. The other options represent tangential concerns: complex tools don't solve unclear code, coding standards are important but secondary to clarity, and increasing complexity isn't a goal when dealing with new APIs. This exercise reinforces the idea that DORA metrics ultimately relate back to developer productivity and efficiency.
20 / 41
During a code review discussion about a recently merged feature, Alex (a developer) says to Ben (another developer), "I'm seeing a lot of duplicated logic in this module. We're repeating the same calculation multiple times in different places. This increases the risk of errors and makes future changes harder to manage.". Ben responds by saying, "That's a good point. Let's investigate if we can refactor this to eliminate that duplication." What key DORA metric is Alex implicitly raising concern about?
Alex's comment directly relates to 'Code Quality', specifically highlighting duplicated logic. Duplicated code is a significant contributor to increased technical debt and makes the codebase harder to understand, test, and maintain – all factors impacting the long-term health of the system. The other options—throughput, deployment frequency, and lead time—are not the primary focus of Alex's concern in this specific scenario.
21 / 41
Maria, a developer, sends this message in a Slack channel after reviewing a PR:
'The tests for this feature are quite brittle – they rely heavily on specific data setups that are hard to maintain. I'm concerned about the long-term stability of this code if these test environments change.'
Which DORA metric is Maria *most* implicitly highlighting a concern about, and what's the core issue she identifies?
Maria is primarily concerned about Change Failure Rate. Brittle tests, which are overly sensitive to specific conditions and difficult to maintain, directly contribute to a higher likelihood of issues being discovered in production after deployment. This increased failure rate ultimately impacts the overall stability of the system, aligning with the definition of change failure rate as the percentage of deployments that cause an incident or require rollback.
22 / 41
During a standup update, David says: "I've been working on the new user profile service. The code complexity is quite high, and I'm noticing repeated validation logic across several components. It's making refactoring difficult.", What is David primarily communicating regarding code quality in this scenario?
David is identifying a key aspect of code quality – technical debt. He's using the term 'duplicated logic' to indicate that the same validation checks are repeated in different parts of the system, which leads to increased maintenance effort and potential future issues. The incorrect options misinterpret his statement as simply reporting a bug or requesting resources; he's directly addressing a code quality problem.
23 / 41
Elena, the team lead, sends this message to the development team after reviewing a recent PR:
'The implementation of the API endpoint lacks proper error handling. We're seeing uncaught exceptions leading to service instability. Also, the logging is minimal, making debugging incredibly challenging.' What specific code quality issue is Elena raising when discussing this PR?
Elena is focusing on the critical aspect of robust code quality – error handling and logging. While naming conventions and performance could be concerns, her primary concern is that the code doesn't handle errors gracefully (uncaught exceptions) and lacks adequate logging to facilitate debugging. This directly impacts the reliability and maintainability of the service.
24 / 41
During a code review, Ben asks: 'I noticed this function has over 30 lines of code. Could we consider refactoring it to improve readability and reduce cognitive load?' Which metric is Ben implicitly referencing when suggesting this change?
Ben is referring to *cyclomatic complexity*, a measure of how many different execution paths exist within a piece of code. Higher complexity generally equates to more difficult-to-understand and maintain code. While LOC is a factor, Ben's focus is on the underlying structural complexity that impacts readability and debugging – this is what cyclomatic complexity measures.
25 / 41
After reviewing a PR for a new feature, Chloe writes in the PR description: 'This module uses several legacy patterns that are no longer supported by our architecture. It's crucial to migrate these patterns to align with our current best practices.' What is Chloe primarily addressing regarding code quality?
Chloe is directly addressing *technical debt* – specifically, the consequences of using legacy patterns. These patterns are no longer aligned with current architecture, creating a maintenance burden and increasing the risk of future problems. The other options represent potential issues, but not the core driver behind her concern about code quality.
26 / 41
Sarah is explaining a complex piece of code to a new team member. She says: 'This function directly manipulates the database schema – it's highly coupled and difficult to test in isolation.' What aspect of code quality does Sarah highlight?
Sarah is pointing out *coupling* – the extent to which different parts of a system depend on each other. High coupling makes code more difficult to understand, test, and change because modifications in one part can have unintended consequences in others. This directly impacts maintainability and resilience.
27 / 41
During a standup update, David says: "I've been working on the new user profile service. The code complexity is quite high, and I'm noticing repeated validation logic across several components. It's making refactoring difficult.", What is David primarily communicating regarding code quality in this scenario?
David is identifying a key aspect of code quality – technical debt. He's using the term 'duplicated logic' to indicate that the same validation checks are repeated in different parts of the system, which leads to increased maintenance effort and potential future issues. The incorrect options misinterpret his statement as simply reporting a bug or requesting resources; he's directly addressing a code quality problem.
28 / 41
Elena, the team lead, sends this message to the development team after reviewing a recent PR:
'The implementation of the API endpoint lacks proper error handling. We're seeing uncaught exceptions leading to service instability. Also, the logging is minimal, making debugging incredibly challenging.' What specific code quality issue is Elena raising when discussing this PR?
Elena is focusing on the critical aspect of robust code quality – error handling and logging. While naming conventions and performance could be concerns, her primary concern is that the code doesn't handle errors gracefully (uncaught exceptions) and lacks adequate logging to facilitate debugging. This directly impacts the reliability and maintainability of the service.
29 / 41
During a code review, Ben asks: 'I noticed this function has over 30 lines of code. Could we consider refactoring it to improve readability and reduce cognitive load?' Which metric is Ben implicitly referencing when suggesting this change?
Ben is referring to *cyclomatic complexity*, a measure of how many different execution paths exist within a piece of code. Higher complexity generally equates to more difficult-to-understand and maintain code. While LOC is a factor, Ben's focus is on the underlying structural complexity that impacts readability and debugging – this is what cyclomatic complexity measures.
30 / 41
After reviewing a PR for a new feature, Chloe writes in the PR description: 'This module uses several legacy patterns that are no longer supported by our architecture. It's crucial to migrate these patterns to align with our current best practices.' What is Chloe primarily addressing regarding code quality?
Chloe is directly addressing *technical debt* – specifically, the consequences of using legacy patterns. These patterns are no longer aligned with current architecture, creating a maintenance burden and increasing the risk of future problems. The other options represent potential issues, but not the core driver behind her concern about code quality.
31 / 41
Sarah is explaining a complex piece of code to a new team member. She says: 'This function directly manipulates the database schema – it's highly coupled and difficult to test in isolation.' What aspect of code quality does Sarah highlight?
Sarah is pointing out *coupling* – the extent to which different parts of a system depend on each other. High coupling makes code more difficult to understand, test, and change because modifications in one part can have unintended consequences in others. This directly impacts maintainability and resilience.
32 / 41
During a standup update, David says: "I've been working on the new user profile service. The code complexity is quite high, and I'm noticing repeated validation logic across several components. It's making refactoring difficult.", What is David primarily communicating regarding code quality in this scenario?
David is identifying a key aspect of code quality – technical debt. He's using the term 'duplicated logic' to indicate that the same validation checks are repeated in different parts of the system, which leads to increased maintenance effort and potential future issues. The incorrect options misinterpret his statement as simply reporting a bug or requesting resources; he's directly addressing a code quality problem.
33 / 41
Elena, the team lead, sends this message to the development team after reviewing a recent PR:
'The implementation of the API endpoint lacks proper error handling. We're seeing uncaught exceptions leading to service instability. Also, the logging is minimal, making debugging incredibly challenging.' What specific code quality issue is Elena raising when discussing this PR?
Elena is focusing on the critical aspect of robust code quality – error handling and logging. While naming conventions and performance could be concerns, her primary concern is that the code doesn't handle errors gracefully (uncaught exceptions) and lacks adequate logging to facilitate debugging. This directly impacts the reliability and maintainability of the service.
34 / 41
During a code review, Ben asks: 'I noticed this function has over 30 lines of code. Could we consider refactoring it to improve readability and reduce cognitive load?' Which metric is Ben implicitly referencing when suggesting this change?
Ben is referring to *cyclomatic complexity*, a measure of how many different execution paths exist within a piece of code. Higher complexity generally equates to more difficult-to-understand and maintain code. While LOC is a factor, Ben's focus is on the underlying structural complexity that impacts readability and debugging – this is what cyclomatic complexity measures.
35 / 41
After reviewing a PR for a new feature, Chloe writes in the PR description: 'This module uses several legacy patterns that are no longer supported by our architecture. It's crucial to migrate these patterns to align with our current best practices.' What is Chloe primarily addressing regarding code quality?
Chloe is directly addressing *technical debt* – specifically, the consequences of using legacy patterns. These patterns are no longer aligned with current architecture, creating a maintenance burden and increasing the risk of future problems. The other options represent potential issues, but not the core driver behind her concern about code quality.
36 / 41
Sarah is explaining a complex piece of code to a new team member. She says: 'This function directly manipulates the database schema – it's highly coupled and difficult to test in isolation.' What aspect of code quality does Sarah highlight?
Sarah is pointing out *coupling* – the extent to which different parts of a system depend on each other. High coupling makes code more difficult to understand, test, and change because modifications in one part can have unintended consequences in others. This directly impacts maintainability and resilience.
37 / 41
During a standup update, David says: "I've been working on the new user profile service. The code complexity is quite high, and I'm noticing repeated validation logic across several components. It's making refactoring difficult.", What is David primarily communicating regarding code quality in this scenario?
David is identifying a key aspect of code quality – technical debt. He's using the term 'duplicated logic' to indicate that the same validation checks are repeated in different parts of the system, which leads to increased maintenance effort and potential future issues. The incorrect options misinterpret his statement as simply reporting a bug or requesting resources; he's directly addressing a code quality problem.
38 / 41
Elena, the team lead, sends this message to the development team after reviewing a recent PR:
'The implementation of the API endpoint lacks proper error handling. We're seeing uncaught exceptions leading to service instability. Also, the logging is minimal, making debugging incredibly challenging.' What specific code quality issue is Elena raising when discussing this PR?
Elena is focusing on the critical aspect of robust code quality – error handling and logging. While naming conventions and performance could be concerns, her primary concern is that the code doesn't handle errors gracefully (uncaught exceptions) and lacks adequate logging to facilitate debugging. This directly impacts the reliability and maintainability of the service.
39 / 41
During a code review, Ben asks: 'I noticed this function has over 30 lines of code. Could we consider refactoring it to improve readability and reduce cognitive load?' Which metric is Ben implicitly referencing when suggesting this change?
Ben is referring to *cyclomatic complexity*, a measure of how many different execution paths exist within a piece of code. Higher complexity generally equates to more difficult-to-understand and maintain code. While LOC is a factor, Ben's focus is on the underlying structural complexity that impacts readability and debugging – this is what cyclomatic complexity measures.
40 / 41
After reviewing a PR for a new feature, Chloe writes in the PR description: 'This module uses several legacy patterns that are no longer supported by our architecture. It's crucial to migrate these patterns to align with our current best practices.' What is Chloe primarily addressing regarding code quality?
Chloe is directly addressing *technical debt* – specifically, the consequences of using legacy patterns. These patterns are no longer aligned with current architecture, creating a maintenance burden and increasing the risk of future problems. The other options represent potential issues, but not the core driver behind her concern about code quality.
41 / 41
Sarah is explaining a complex piece of code to a new team member. She says: 'This function directly manipulates the database schema – it's highly coupled and difficult to test in isolation.' What aspect of code quality does Sarah highlight?
Sarah is pointing out *coupling* – the extent to which different parts of a system depend on each other. High coupling makes code more difficult to understand, test, and change because modifications in one part can have unintended consequences in others. This directly impacts maintainability and resilience.
Frequently Asked Questions
What does the "DORA Metrics Communication" exercise practise?
Practice English vocabulary for discussing DORA metrics with management: deployment frequency, lead time, MTTR, change failure rate, and reporting language. 5 exercises.
How many questions are in this exercise?
This exercise has 41 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 "DORA Metrics Communication" 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.