Kefiw

Archived noindex page. Kefiw's public focus is Property decision help.

Archived page

This older Kefiw page is kept for reference, marked noindex, and removed from the primary sitemap. The current Kefiw experience is focused on property decisions: cost, quotes, damage, buying, selling, owning, and packets.

Go to Property
▸ SOP · Finance & Business

What Tech Debt Interest Calculates

The hours it will take to fix a shortcut in 6, 12, or 18 months — compounded by everything built on top of it.

Tech Debt Interest answers one question: how much more will this shortcut cost to fix if I wait?

Tech debt compounds. Each feature built on a hack multiplies the fix cost. Current cognitive load: load unmeasured. This tool attaches a number to "we'll fix it later" so debt repayment stops losing to feature pressure by default.

▸ Deterministic Formula
effective_growth = base_growth × (1 + velocity_factor)
payoff_hours = initial_fix × (1 + effective_growth)^months
if payoff_hours < 2 × initial_fix → STABLE
if payoff_hours < 4 × initial_fix → GUARDED
else → CRITICAL (red-band, rewrite territory)
▸ Logical Gates
  1. Set honest growth: 1-3%/mo dead code, 5-10%/mo active, not 15-20%.
  2. Input code velocity — features landing on the hack per month.
  3. Compute payoff_hours at current wait and at wait + 6 months.
  4. If ratio ≥ 4× initial_fix, schedule refactor this quarter.
  5. Attach payoff number to the ticket. Load: load unmeasured.

Quick answer

Tech Debt Interest answers one question: how much more will this shortcut cost to fix if I wait?

What you are trying to do
The hours it will take to fix a shortcut in 6, 12, or 18 months — compounded by everything built on top of it.
Best next step
Tech Debt Interest
Limit to remember
Treat this as a practical aid for the task, not a replacement for professional judgment.

▸ Key Specs

  • Formula: payoff_hours = initial_fix × (1 + effective_growth) ^ months.
  • Effective growth compounds with code velocity — 5%/mo stable code, 8-12%/mo actively-developed modules.
  • Code velocity multiplies the drag. Load on the team: load unmeasured. High-churn modules hit red-band within a year.
  • Heatmap bands: green (manageable), yellow (watch), red (rewrite territory).
  • Order-of-magnitude tool. Forces scheduling conversation, does not predict the fix to the hour.

▸ Worked Examples

  • 6hr fix, 8%/mo growth, velocity 5, wait 18 months
    Payoff ≈ 22 hours — almost 4× original. Heatmap goes red past month 12. Cognitive load on the team: load unmeasured.
  • 4hr fix, 5%/mo growth, velocity 2, wait 12 months
    Payoff ≈ 7 hours. Stable code plus low velocity keeps debt manageable. Repay opportunistically.
  • 10hr fix, 12%/mo growth, velocity 8, wait 24 months
    Payoff ≈ 152 hours. The classic "we'll never fix it" outcome. Eventually rewritten under duress.

When to use which tool

▸ Operational Thresholds
  • CYAN · STABLEPayoff under 2x the initial fix — pay it now, compounding still manageable.
  • GOLD · GUARDEDPayoff 2-4x initial — schedule a repayment sprint within the next quarter.
  • MAGENTA · CRITICALPayoff above 4x initial — red-band territory, every new feature multiplies it.
▸ READ NEXT
Revenue per Head
Divide the debt cost by headcount to make it concrete.

Related

Frequently asked questions

Is compounding at 8%/month realistic? Trust & accuracy

For active modules, yes. Each feature assumes the shortcut, increasing entanglement. Stable utility code compounds much slower — use 1-3%/mo.

What if we rewrite the whole module later?

Rewrite cost is usually 3-5× the compounded payoff at rewrite time. The longer you wait, the more you pay — either via compounded patches or a bigger rewrite.

Does this apply to non-code debt?

Yes, loosely. Documentation, test coverage, and process debt compound similarly — each new item built on a bad foundation adds cleanup cost.

How should I use a decision framework in real life? How-to

Use a decision framework to expose the tradeoff, not to outsource the decision. Write down the inputs, compare the output with your constraints, then ask what would change the answer. The strongest use is scenario testing: base case, conservative case, and failure case.

Is this financial, legal, or tax advice? Trust & accuracy

No, this is not legal, financial, tax, medical, or professional advice unless the page explicitly says that use case is supported. It organizes assumptions so you can inspect them. Verify high-stakes choices with qualified people who can review facts, contracts, regulations, and downside risk.