Learn vocabulary for discussing technical debt: deliberate vs. accidental debt, debt registry, debt interest, and debt paydown.
0 / 10 completed
1 / 10
What is Ward Cunningham's original definition of 'technical debt'?
Ward Cunningham coined the technical debt metaphor: 'shipping first and refactoring later is like going into debt. A little debt speeds delivery so long as it is paid back promptly with a refactor.' The danger is letting debt accumulate — the interest (slowdown) eventually exceeds the original time saved.
2 / 10
What is the difference between 'deliberate' and 'inadvertent' technical debt?
Deliberate debt: 'We know this is a shortcut — we'll clean it up in Q3.' It is a conscious trade-off. Inadvertent debt: the team didn't know better at the time (e.g., learned a better pattern later). Deliberate debt is manageable when tracked; inadvertent debt is more dangerous because it is unrecognized.
3 / 10
What is 'debt interest' in technical debt vocabulary?
Debt interest is the productivity tax of existing technical debt. Every feature added to a poorly structured module costs more than it should. As debt grows, interest payments grow — eventually the team spends more time fighting the codebase than building features. This is the 'cruft' that slows development velocity.
4 / 10
What is a 'debt registry' in software engineering vocabulary?
A debt registry (debt backlog) makes technical debt explicit and managed: each item has a title, description of the problem, estimated cost to fix, business impact if not fixed, and an owner. This transforms 'vague technical debt' into managed work that can be prioritized like product features.
5 / 10
What does 'paying down technical debt' mean?
Paying down debt means investing time now to improve code quality, reducing future interest payments. Common approaches: allocate a fixed percentage of each sprint to debt paydown (20% rule), schedule dedicated refactoring sprints, or use opportunistic refactoring to improve code while doing feature work.
6 / 10
Code Review Comment: Sarah, the senior developer, left this comment on your recent PR:
`'This section uses a workaround instead of a proper abstraction. It's going to cause problems when we need to integrate with the new payment gateway.'`
Which best describes the *technical debt* being highlighted in this comment?
This comment identifies a situation where a solution was chosen for expediency rather than best practices. The key here is Sarah's phrasing – 'prioritize short-term gains over long-term maintainability' directly reflects the core concept of technical debt: a trade-off made today that will likely require more effort later. Option A misinterprets this as a minor stylistic issue, while options B and D focus on immediate fixes rather than the underlying problem.
7 / 10
Slack Message: You're in a Slack channel discussing a legacy feature. Mark says: 'I'm just patching this old API endpoint to keep it running. It's not ideal, but we don't have the time to rewrite it.' What type of technical debt is Mark describing?
Mark's statement explicitly mentions 'patching' and 'not ideal', indicating a conscious decision to take a shortcut. This aligns with 'Deliberate Technical Debt,' where the risks are acknowledged and accepted for immediate benefit. 'Inadvertent' debt is unplanned, while 'Legacy' is broader (related to old systems), and 'Strategic' implies a more formalized approach.
8 / 10
PR Description: You're writing the description for a PR that adds a new feature. You include this note: 'This uses a temporary data structure to avoid impacting existing users while we're testing.' What aspect of technical debt is being addressed here?
The description highlights a 'temporary data structure,' which is a common tactic to mitigate risk and avoid disrupting existing functionality. This represents 'Hidden Debt' because the potential issues associated with this temporary solution aren't immediately visible – they will likely become apparent as the feature matures and requires further changes. Options A, B & C represent related concepts but don't capture the *specific* element of using a workaround.
9 / 10
Standup Update: During your daily standup, you say: 'I spent some time refactoring the user authentication module. It was complex, but I'm confident it will improve performance and reduce future development effort.' What is this best described as in terms of technical debt?
Your statement describes a deliberate effort to improve the codebase, directly addressing the underlying issues contributing to technical debt. 'Debt Resolution' accurately reflects this proactive approach of systematically reducing complexity and cost. Options A and D are misleading; consolidation is a different process, and simply writing 'better code' doesn't necessarily equate to tackling accumulated debt.
10 / 10
API Response: You receive this error message from the backend system:
HTTP 406 – Not Acceptable. The response body includes a note: 'This endpoint uses an outdated data format and lacks proper documentation.' How does this relate to technical debt?
The error message points to outdated data formats and missing documentation – hallmarks of technical debt. This situation highlights the consequences of neglecting to maintain and evolve older systems. The response is demonstrating the *effects* of this debt (making future development harder), rather than a direct security issue or performance problem. Options A, C & D are related but misdiagnose the root cause.
What will I practice in "Technical Debt — Taxonomy and Communication"?
This is a Refactoring Language exercise set. It walks through 10 scenario-based multiple-choice questions built around real usage of refactoring language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 10 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the refactoring language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Refactoring Language exercises?
See the Refactoring Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — refactoring language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.