Build fluency in the language of tracking and communicating technical debt.
0 / 5 completed
1 / 5
At standup, a dev flags that a shortcut taken to hit a deadline will require future rework to do properly. What is this shortcut commonly called?
Technical debt describes the implied future cost of choosing an expedient, short-term solution now instead of a more thorough, correct approach, drawing an analogy to financial debt that accrues interest over time. It is often a deliberate, reasonable tradeoff, not inherently a mistake. Naming it explicitly helps teams track and later address it.
2 / 5
During a design review, the team decides to accept a known shortcut deliberately to hit a deadline, planning to fix it later. What is this decision called?
Deliberate technical debt is taken on knowingly and with a plan to address it later, distinct from debt that accumulates unintentionally through neglect or lack of awareness. Being explicit about the tradeoff, and documenting it, makes it more likely to actually get paid down. This intentionality is what separates a reasonable pragmatic tradeoff from silent decay.
3 / 5
In a code review, a dev notices a workaround from months ago was never revisited and now blocks a new feature. What is this consequence often called?
When unaddressed technical debt makes future changes progressively harder or riskier, this compounding cost is often described as interest accruing on the original debt, continuing the financial metaphor. Left unpaid long enough, this interest can make even simple changes expensive. This escalating cost is the core argument for eventually paying debt down rather than letting it accumulate indefinitely.
4 / 5
An incident report traces an outage back to a known workaround the team never had time to properly fix. What process gap does this reveal?
An outage traced to a known but unaddressed workaround usually reveals that technical debt was identified but never prioritized for remediation. Tracking debt items alongside feature work, and periodically allocating time to address the highest-risk ones, prevents this kind of silent accumulation into an incident. This is a common postmortem finding when debt goes unmanaged.
5 / 5
During a PR review, a teammate asks whether taking on technical debt for this deadline is acceptable. What is the key consideration?
The key consideration isn't whether to ever take on technical debt, since that's sometimes a reasonable tradeoff, but whether it's an explicit, tracked decision with a realistic plan for eventually addressing it. Debt taken on silently and forgotten is far riskier than debt taken on deliberately and revisited. This distinction shapes healthy engineering culture around pragmatic tradeoffs.