5 exercises on technical debt and refactoring vocabulary.
0 / 5 completed
1 / 5
In Fowler's technical debt quadrant, what is prudent inadvertent debt?
Inadvertent + Prudent: "Now we know what we should have done." You learned by building. The original design seemed correct. Use discovered a better approach. This is normal and expected. Fowler quadrant: Deliberate+Prudent ("ship now, fix later — we have a plan"), Deliberate+Reckless ("no time for design"), Inadvertent+Prudent ("now we know better"), Inadvertent+Reckless ("what is layering?"). Most dangerous: Deliberate+Reckless (knowingly creates mess) and Inadvertent+Reckless (pure ignorance). Best managed: Deliberate+Prudent (if you actually pay it back).
2 / 5
What is the strangler fig pattern for migrating legacy systems?
Strangler fig (Fowler 2004): key elements: routing façade (API gateway, reverse proxy, feature flag), new system built incrementally alongside the old, traffic gradually shifted one domain at a time, old system decommissioned when traffic reaches zero. Why better than big-bang rewrite: each migration ships to production (validates correctness continuously), business features continue shipping during migration, rollback is possible at any point, team learns the domain by migrating it. Related: Branch by abstraction (create abstraction layer, swap implementation behind it), Parallel change/expand-contract (for API/schema changes).
3 / 5
What is refactoring in the strict sense?
Refactoring (Martin Fowler): behavior-preserving. The external behavior does not change — only the internal structure. Critical: tests must pass throughout. Never refactor without tests (or add tests first — "don't change code without tests" is the golden rule). Common refactorings: Extract Method, Move Method, Rename, Inline, Extract Class, Replace Conditional with Polymorphism, Introduce Parameter Object. Refactoring vs rewriting: refactoring is incremental and safe (tests verify); rewriting is risky (big-bang, behavior often changes). Code smells: structural patterns indicating refactoring opportunities (Long Method, God Class, Feature Envy, Primitive Obsession).
4 / 5
What is a debt register?
Debt register: treats debt as a balance sheet liability. Per-item fields: ID, description, area of codebase, type (design/test/infrastructure/documentation), principal (fix cost in story points), interest rate (slowdown hours/sprint), total interest to date, owner, priority (interest rate / principal = ROI). High ratio = pay this first. Executive communication: "This authentication refactor costs 2 sprints to fix. It costs us 4 hours/sprint in slowdown. At fully loaded engineer cost, it pays back in 12 sprints." Vague backlogs fail because items compete with features on no objective basis and are never prioritized. Debt register makes ROI explicit.
5 / 5
What is a deprecation path for an internal API?
Deprecation path elements: Announcement: early, multi-channel (email, Slack, docs update). Include: what, why, replacement, timeline. Machine-readable signals: HTTP Deprecation header (RFC 8594) with sunset date. Compiler warnings in SDKs. Usage dashboard: logs showing which callers still use the deprecated endpoint — without this you can't know when it's safe to remove. Migration guide: code examples of before/after. Graduated pressure: warnings → throttling → hard removal. Firm sunset date: soft deadlines extend forever. External API deprecation: longer notice periods (6-12+ months), stricter SLAs. Internal deprecation can be faster with complete caller visibility.
These modules build the same on-the-job skills as Technical Debt and Refactoring
— work through them together for a fuller vocabulary set.
Code Refactoring— useful for Technical debt communication (Solution Architect)
Frequently Asked Questions
What does the "Technical Debt and Refactoring" vocabulary exercise cover?
This exercise tests real IT vocabulary related to technical debt and refactoring through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.