Skip to content

Technical Debt

Status: 🌱

Context

In legacy-heavy systems, business rules usually evolve faster than architecture. Over time, incremental fixes and local optimizations increase structural complexity, even when delivery looks stable in the short term. The main impact is operational: higher cognitive load, less predictable changes, and more fragile releases.

Starting Points

  • Treat technical debt as delivery risk, not optional cleanup.
  • Make complexity visible with explicit tags (tech-debt, risk, hotspot, complexity) in backlog and incidents.
  • Reserve fixed capacity for structural work in every cycle (for example, 15-25%).
  • Keep a simple policy: at least 1 structural task for every 3-5 feature tasks.
  • Maintain a Top 10 technical risk list with owner, impact, and mitigation status.
  • Add post-incident structural review to convert incidents into architecture improvements.
  • Revisit hotspots quarterly with Product to re-prioritize structural backlog.
  • Prefer simplification that reduces cognitive load in high-change modules.

Practical References