One Pager Cheat Sheet

• technical debt compounds silently and, while it can accelerate delivery if managed with a pay-down plan, unmanaged debt slows teams, increases outage risk, and must be seen, priced, prioritized, and paid down to avoid blocking the roadmap.
• Martin Fowler’s Technical Debt Quadrant classifies debt by intent (deliberate vs. inadvertent) and judgment (prudent vs. reckless), helping teams explain why shortcuts happened and pick remedies — e.g., knowingly hardcoding config is deliberate/prudent if there’s a follow-up ticket and owner, otherwise reckless.
• The Technical Debt Quadrant classifies technical debt along the orthogonal dimensions of intent (either deliberate or inadvertent) and judgment (either prudent or reckless), so every debt instance can be labeled to explain why it exists and guide appropriate remedies, ownership, and prioritization.
• principal is the one-time work to remediate debt, interest is the recurring extra work you pay every time you touch the area, interest rate is how quickly that extra work grows, and a debt item is a trackable unit describing location, impact, and remediation.
• In the software-debt analogy, interest is the recurring extra work you pay every time you touch the area, distinct from the one-time work to remediate the debt (principal); the interest rate measures how that per-touch cost grows and a debt item tracks where principal and interest live so you can decide whether to pay them down.
• Technical debt is not just “ugly code”; it’s any design or implementation shortcut that increases future change cost—for example missing tests, unclear ownership, outdated libraries, “temporarily” bypassed checks, or accidental complexity in architecture—and while bugs ≠ debt, a pattern of quick fixes that bypass root causes is debt.
• Software debt commonly arises from deliberate pressures like deadlines and feature demands, inadvertent causes such as knowledge gaps or changing requirements, architecture drift as systems evolve, and tooling/infra lag (e.g. versions, build pipelines), and SEI emphasizes it often comes from process and context, not just code.
• False — Not all technical debt is intentional: technical debt includes deliberate trade-offs (e.g., TODO, prototype, hack promoted to production) and inadvertent issues from changing requirements, knowledge gaps, and process/context, and should be handled differently—document and schedule intentional debt; root-cause fix inadvertent debt—because interest still accrues and you should track it in issues and budget time to pay it down.
• Technical debt raises toil, on-call pages, and change-failure rates, so SREs should use error budgets and risk tradeoffs to justify refactors that reduce alert volume and improve MTTR, aligning with reliability goals.
• Make debt visible by recording technical debt in your shared backlog alongside features and bugs—tagged and prioritized per Atlassian—while capturing location, symptoms (interest), owners, proposed fix, size, risk, and a definition of done so tradeoffs are transparent.
• Making technical debt visible in the shared backlog with impact fields (e.g., interest, size, risk, owners, proposed fix, definition of done) creates transparency, enables data-driven prioritization, assigns ownership, reduces rework, and lowers risk by turning hidden debt items into actionable, reportable work.
• Estimate Principal as person-days to implement the fix and Interest as the extra hours per sprint caused by the debt (e.g., test flakiness ≈ 2h/wk), track both and review monthly — Fowler frames this extra effort as the interest you pay.
• Use a simple score — Priority = (Interest × Frequency × Risk) ÷ (Principal), where Interest is extra effort per touch, Frequency is how often the area changes, Risk is outage/compliance/security exposure, and Principal is estimated remediation effort — to compare debt items and order the debt column in your backlog alongside product value.
• Combine Debt Budget (Tax) — reserve a fixed 10–20% of each sprint for debt — with Refactor Fridays/20% Time — scheduled cleanup cadence — plus Opportunistic Refactor (the Boy Scout Rule) — leave any file you touch in better shape — and Thematic Cleanup — focus on one cross-cutting issue per quarter.
• Architecture debt stems from design shortcuts like shared DBs, tight coupling, and ambiguous boundaries, creating systemic drag that can be mitigated by domain decomposition and clear contracts to reduce “spiderweb” dependencies, and — as SEI notes — the debt spans artifacts beyond code.
• Automated tests and fast CI lower the interest rate by making changes safer and cheaper; SRE monitoring of the golden signals—latency, traffic, errors, saturation—reveals debt that harms reliability you can use to justify investment, and adding static analysis, coverage gates, and upgrade bots helps stop new debt from sneaking in.
• Follow the sequence capture (make the debt visible and assign an owner) → quantify (estimate principal and interest using logs/metrics) → prioritize (score by impact, ROI and risk with frameworks like RICE/WSJF) → schedule into a sprint, because this traceable, data‑driven flow turns qualitative problems into measurable tradeoffs and ensures fixes are timeboxed and actually reduce the organization's effective interest rate.
• Tailor updates: show Engineers before/after cycle time and defect trends; explain to PMs how cleanup affects roadmap velocity (e.g., "feature X ships 2 sprints sooner"); and brief Execs in risk/cost terms (e.g., N engineer-days/quarter, payback ≤2 quarters), using concise artifacts like RFCs, risk registers, and decision memos.
• Implement Definition of Done that requires tests, monitoring, and docs, enforce architecture reviews for cross-team impacts, adopt version policies (e.g., N-1 for frameworks) with scheduled upgrade windows, and gate changes with CI lint/type checks to prevent avoidable debt.
• Track before/after using lead time for changes, change failure rate, incident counts/MTTR, flaky tests, CI duration, and deploy frequency as your core throughput/reliability metrics to validate returns on debt work (see SRE monitoring chapters for guidance on signals).
• Prefer incremental refactors with steady business value; only undertake a rewrite when the interest on technical debt far exceeds the principal, the architecture is fatally misaligned with product direction, and you can run old and new in parallel via the strangler pattern, keeping milestones small and reversible.