Step 18 of 23
why tech debt exists, how to manage it, making it visible, prioritizing by risk
Tech Debt ก็เหมือนค่าซ่อมอาคารที่เลื่อนออกไป — จ่ายน้อยหน่อยตอนนี้ หรือจ่ายหนักกว่าเดิมทีหลัง
Imagine you manage an office building. The air conditioning has been making a strange noise for months. It still works, so you keep putting off the repair. After all, there are more urgent things to spend money on.
Six months later, the entire system fails during the hottest week of the year. The repair that would have cost $5,000 now costs $50,000 because the damage spread. The office is unusable for a week. Employees are furious. The business loses productivity.
That is technical debt.
In software, tech debt is the accumulated cost of shortcuts taken earlier. A quick fix instead of a proper solution. A copy-paste instead of a shared component. A temporary workaround that became permanent. Each shortcut saves time now but creates a maintenance burden later.
Diagram: Vicious cycle where shortcuts speed up shipping initially but accumulate debt that slows future work, leading to more shortcuts.
Loading diagram...
The cycle is self-reinforcing. Debt slows you down, which creates pressure for more shortcuts, which creates more debt.
Diagram: Tech debt feedback loop — deadline pressure leads to shortcuts, faster shipping, harder-to-change code, slower features, and back to deadline pressure.
Loading diagram...
Tech debt is not always bad. Like financial debt, it is a tool:
Tech debt becomes a problem when it is invisible, unmeasured, and never addressed.
Make it visible. Maintain a list of known tech debt items. Each item describes the shortcut, the risk it creates, and the estimated effort to fix it.
Allocate time regularly. Dedicate a percentage of every sprint or work cycle to paying down debt. Industry practice: 15-20% of engineering time.
Prioritize by risk. Not all debt is equal. A shortcut in a rarely-used feature is low risk. A shortcut in your payment system is high risk.
Resist the "rewrite everything" temptation. Large rewrites are expensive, risky, and often fail. Pay down debt incrementally. Fix the worst parts first.
Engineers will tell you they need time to "pay down tech debt." Here is how to evaluate the request:
If the team cannot articulate the business impact, the request is not ready for prioritization.
Tech debt is a business cost, not an engineering complaint. It slows feature delivery, increases bugs, raises maintenance costs, and makes it harder to hire (good engineers dislike working in a mess).
The choice is not "pay down debt or build features." It is "pay a little now or pay a lot later." Like maintaining a building, regular upkeep prevents catastrophic failure.
