🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧾 धडा 07 — Technical debt एक portfolio म्हणून: interest विरुद्ध principal

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 · मागे: lesson-06-prioritisation · पुढे: lesson-08-delivery-metrics

📦 या ब्रँचमध्ये काय आहे

धडा 06, आणि technical debt, पैशासारखी किंमत लावून: principal (दुरुस्त करायला लागणारे तास) आणि interest (ते दुरुस्त होईपर्यंत टीमला दर आठवड्याला लागणारे तास). ते कधी फेडायचे, कधी बाळगायचे, आणि तुम्ही तो code किती काळ ठेवणार यावर उत्तर का अवलंबून असते. lead/demo.py मधले debt(); lead/models.py मधले debt_plan().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

गणित विभागात काही जुन्या, गोंधळलेल्या गोष्टी आहेत: 🧹

Photocopier रोज अडकतो. प्रत्येकीचा दर आठवड्याला थोडा वेळ जातो. तो नीट दुरुस्त करायला एक दुपार लागते.
जुने अहवालांचे कपाट अस्ताव्यस्त आहे. पण कोणीही ते एका सत्रात एकदापेक्षा जास्त उघडत नाही. ते आवरायला एक आठवडा लागेल.

कतरिना प्रत्येक गोंधळाबद्दल दोन प्रश्न विचारते. "दुरुस्त करायला किती वेळ?" — ते म्हणजे principal. "आपण तसेच ठेवले तर दर आठवड्याला ते किती वेळ चोरते?" — ते म्हणजे interest. 💸

Photocopier: लहान principal, मोठे interest. ते आत्ता दुरुस्त करा — काही आठवड्यांत खर्च वसूल होतो. कपाट: मोठे principal, अगदी लहान interest. ते तसेच राहू द्या. ते आवरण्याचा खर्च त्यातून कधीही होणाऱ्या बचतीपेक्षा जास्त असेल — जोपर्यंत विभाग ते कपाट रोज वापरू लागत नाही.

प्रत्येक गोंधळ साफ करण्याजोगा नसतो. पण जो गोंधळ दर आठवड्याला वेळ चोरतो तो कोणी फेडायचे ठरवो वा न ठरवो, तुमचा खर्च करतच असतो.

🗺️ आकृती

flowchart LR
    d["🧾 debt items<br/>principal h · interest h/wk"] --> f["flaky test suite<br/>24 h · 6 h/wk<br/>pays back in 4 wk → pay"]
    d --> m["manual release steps<br/>40 h · 5 h/wk<br/>8 wk → pay"]
    d --> g["tangled gradebook core<br/>200 h · 4 h/wk · 50 wk<br/>26-wk horizon: carry · 104-wk: pay"]
    d --> o["old report module<br/>120 h · 1 h/wk<br/>120 wk → carry"]
    t["💸 total interest 16 h/wk<br/>= 10% of 160 h"] --> d

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l07

❓ काय

Technical debt — Ward Cunningham यांचे रूपक (1992): आता तुम्हाला जे माहीत आहे त्यासाठी अजून योग्य नसलेला code ship करणे म्हणजे पैसे उसने घेण्यासारखे आहे. तुम्ही ते परत फेडले तर हा चांगला व्यवहार ठरू शकतो. नंतरच्या वापरात हा शब्द बदल हळू करणाऱ्या कोणत्याही code किंवा system साठी रुंदावला. Martin Fowler यांचा debt quadrant deliberate आणि inadvertent, तसेच prudent आणि reckless debt वेगळे करतो.
Principal — ते नीट दुरुस्त करण्याचे श्रम (इथे तासांमध्ये).
Interest — ते तसेच राहिल्यावर लागणारे श्रम: हळू बदल, flaky tests, manual पायऱ्या, incidents, onboarding चा वेळ. Interest फक्त जिथे code ला हात लावला जातो तिथेच भरले जाते: कोणी बदलत नाही अशा code मधल्या debt ची किंमत जवळपास शून्य असते.
Payback period — principal ÷ दर आठवड्याचे interest: दुरुस्तीचा खर्च वसूल व्हायला किती आठवडे.
Horizon — हा code तुम्ही किती काळ बदलत राहणार आहात असे तुम्हाला वाटते. 50 आठवड्यांत वसूल होणारी दुरुस्ती system 26 आठवड्यांत बदलली जाणार असेल तर वाईट व्यवहार आहे, आणि तुम्ही ती दोन वर्षे ठेवणार असाल तर चांगला.
Flat-interest model — ही lab interest स्थिर ठेवते. खऱ्या systems मध्ये debt वर आणखी code बांधला जातो तसे interest अनेकदा वाढते; पसरणाऱ्या debt साठी lab मधले paybacks आशावादी समजा.

🤔 का

कारण "आम्हाला tech debt साठी वेळ हवा" हे भावना म्हणून सांगितले की प्रत्येक prioritisation meeting (धडा 06) मध्ये हरते. किंमत म्हणून सांगितले — "flaky test suite आपले दर आठवड्याला 6 तास घेतो; दुरुस्त करायला 24 तास लागतात" — की ते features शी बरोबरीने स्पर्धा करते. आणि किंमत लावल्याने कोणते debt तसेच सोडायचे हेही दिसते: कोणी हात लावत नाही असा code पुन्हा लिहिणे हा engineering चा वेळ वाया घालवण्याचा सर्वात नेहमीचा मार्ग आहे.

🔧 कसे (या repo मध्ये)

lead/models.py मधले debt_plan(items, horizon) (name, principal hours, interest hours/week) items घेते. प्रत्येकासाठी ते payback period (principal ÷ interest) आणि horizon वरील net तास (interest × horizon − principal) मोजते, आणि net positive असेल तर pay आणि नसेल तर carry सांगते; rows payback नुसार sorted परत येतात. lead/demo.py मधले debt() चार items ची 26 आणि 104 आठवड्यांसाठी किंमत लावते. Interest चे आकडे अंदाज आहेत: विचार करण्याचे साधन, माणसांसाठीचे सूत्र नाही — आणि code लिहिणाऱ्या कोणालाही दोष देण्याचा मार्ग तर कधीच नाही.

🧪 करून पाहा

python3 lead/demo.py debt
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import debt_plan
core = [("tangled gradebook core", 200, 4)]
for horizon in (13, 26, 50, 52, 104):
    name, p, i, payback, net, act = debt_plan(core, horizon)[0]
    print(f"gradebook core, horizon {horizon:>3} weeks → net {net:>+5} h → {act}")
for interest in (1, 4, 8):
    r = debt_plan([("core", 200, interest)], 26)[0]
    print(f"interest {interest} h/wk → pays back in {r[3]:>5.1f} weeks")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

debt असे print करते (26 आठवड्यांचा horizon, मग 104):

     flaky test suite         principal  24 h · interest 6 h/wk · pays back in   4.0 wk · net  +132 h → pay
     manual release steps     principal  40 h · interest 5 h/wk · pays back in   8.0 wk · net   +90 h → pay
     tangled gradebook core   principal 200 h · interest 4 h/wk · pays back in  50.0 wk · net   -96 h → carry
     old report module        principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net   -94 h → carry

     tangled gradebook core   principal 200 h · interest 4 h/wk · pays back in  50.0 wk · net  +216 h → pay
     old report module        principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net   -16 h → carry
   total interest 16 h/week out of a team's 160 h/week (10%) — paid every week, whether or not anyone decides to

तुमचा snippet असे print करतो:

gradebook core, horizon  13 weeks → net  -148 h → carry
gradebook core, horizon  26 weeks → net   -96 h → carry
gradebook core, horizon  50 weeks → net    +0 h → carry
gradebook core, horizon  52 weeks → net    +8 h → pay
gradebook core, horizon 104 weeks → net  +216 h → pay
interest 1 h/wk → pays back in 200.0 weeks
interest 4 h/wk → pays back in  50.0 weeks
interest 8 h/wk → pays back in  25.0 weeks

🏁 तुम्ही आत्ताच काय सिद्ध केले

Flaky test suite 4 आठवड्यांत वसूल होतो आणि अर्ध्या वर्षात 132 तास वाचवतो — तो आत्ता फेडा. Old report module दोन वर्षांतही कधी वसूल होत नाही — तो बाळगा. Tangled gradebook core हा रंजक आहे: 26 आठवड्यांत तो दुरुस्त केल्याने 96 तास जातात, 104 आठवड्यांत तो 216 वाचवतो; break-even नेमके 50 आठवडे आहे. म्हणजे योग्य उत्तर code किती कुरूप आहे यावर नाही, तर आराखड्यावर अवलंबून आहे. दरम्यान चारही items ची किंमत आठवड्याला 16 तास — टीमच्या 10% — आहे, कोणी ठरवो वा न ठरवो भरली जाणारी.

⚠️ नेहमीच्या चुका

काय, का, आणि त्यातून काय वाचेल याची यादी नसलेला "tech debt साठी एक sprint"
code महाग आहे म्हणून नव्हे, तर कुरूप आहे म्हणून तो पुन्हा लिहिणे
लवकरच delete किंवा replace होणार असलेल्या code वर principal भरणे
कधीच न फेडणे, जोपर्यंत एक दिवस interest हाच संपूर्ण आठवडा बनत नाही
फक्त मतांवरून interest चा अंदाज करणे — incidents, flaky runs, time-to-change पाहा
debt ला कोणाचा तरी दोष समजणे; बहुतेक debt त्या वेळी वाजवी व्यवहार होता

🏭 प्रत्यक्ष वापरात

Backlog शेजारी एक debt नोंदवही असते, त्याच पद्धतीने किंमत लावलेली:

| Debt item              | Principal | Interest/wk | Payback | Evidence                              | Decision (week 14) |
|------------------------|-----------|-------------|---------|---------------------------------------|--------------------|
| Flaky test suite       | 24 h      | 6 h         | 4 wk    | 31% of CI runs re-run last month      | pay now            |
| Manual release steps   | 40 h      | 5 h         | 8 wk    | 2.5 h per release × 2 releases/wk      | pay this quarter   |
| Tangled gradebook core | 200 h     | 4 h         | 50 wk   | changes take 2× longer than elsewhere | pay if kept 2 yrs  |
| Old report module      | 120 h     | 1 h         | 120 wk  | 3 changes this year                   | carry; revisit Q3  |

Interest चा पुरावा अनेकदा आधीच उपलब्ध असतो. खऱ्या repository वर, सर्वात जास्त वेळा बदलणाऱ्या files म्हणजे जिथे interest भरले जाते (ढोबळ संकेत — टीम काय म्हणते त्याच्यासोबत जोडून पाहा):

git log --since="6 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -15

अनेक टीम्स वेगळ्या "debt sprint" ऐवजी या कामासाठी क्षमतेचा स्थिर वाटा राखून ठेवतात (15–20% सारखे आकडे नेहमीचे आहेत). वाटा कितीही असो, तो कशावर खर्च करायचा हे नोंदवही ठरवते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे आहे: प्रत्येक debt item ची किंमत आठवड्याच्या तासांत लावा, लवकर वसूल होणारे आत्ता दुरुस्त करा, बाकीचे पुन्हा पाहण्याच्या तारखेसह जाणीवपूर्वक बाळगा — आणि planning मध्ये एकूण interest मोठ्याने सांगा, कारण ते आधीच भरले जात आहे.

⏭️ पुढे

विभाग सुधारतो आहे की बिघडतो आहे हे तुम्हाला कसे कळते? पुढे: delivery metrics — आणि एखादा आकडा target बनला की काय होते.

git checkout lesson-08-delivery-metrics

🧾 Lesson 07 — Technical debt as a portfolio: interest vs principal

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-prioritisation · Next: lesson-08-delivery-metrics

📦 What's in this branch

Lesson 06, plus technical debt, priced like money: the principal (hours it would take to fix) and the interest (hours it costs the team every week until it is fixed). When to pay it, when to carry it, and why the answer depends on how long you will keep the code. debt() in lead/demo.py; debt_plan() in lead/models.py.

🧒 Explain like I'm 5

The maths department has some old, messy things: 🧹

The photocopier jams every day. Everyone loses a bit of time, every week. Fixing it properly takes one afternoon.
The old report cupboard is a mess. But nobody opens it more than once a term. Tidying it would take a week.

Katrina asks two questions about each mess. "How long to fix it?" — that is the principal. "How much time does it steal every week while we leave it?" — that is the interest. 💸

The photocopier: small principal, big interest. Fix it now — it pays back in a few weeks. The cupboard: big principal, tiny interest. Leave it. Tidying it would cost more than it ever saves — unless the department starts using that cupboard every day.

Not all mess is worth cleaning. But the mess that steals time every week is costing you whether or not anyone decides to pay.

🗺️ Diagram

flowchart LR
    d["🧾 debt items<br/>principal h · interest h/wk"] --> f["flaky test suite<br/>24 h · 6 h/wk<br/>pays back in 4 wk → pay"]
    d --> m["manual release steps<br/>40 h · 5 h/wk<br/>8 wk → pay"]
    d --> g["tangled gradebook core<br/>200 h · 4 h/wk · 50 wk<br/>26-wk horizon: carry · 104-wk: pay"]
    d --> o["old report module<br/>120 h · 1 h/wk<br/>120 wk → carry"]
    t["💸 total interest 16 h/wk<br/>= 10% of 160 h"] --> d

🗺️ Drawn version + a lab: https://school-edh.pages.dev/engineering-leadership/lesson-diagrams.html#l07

❓ What

Technical debt — Ward Cunningham's metaphor (1992): shipping code that is not yet right for what you now know is like borrowing money. It can be a good trade, if you pay it back. Later usage widened the term to any code or system that slows change down. Martin Fowler's debt quadrant separates deliberate from inadvertent and prudent from reckless debt.
Principal — the effort to fix it properly (here in hours).
Interest — the effort it costs while it stays: slower changes, flaky tests, manual steps, incidents, onboarding time. Interest is paid only where the code is touched: debt in code nobody changes costs almost nothing.
Payback period — principal ÷ interest per week: how many weeks until the fix has paid for itself.
Horizon — how long you expect to keep changing this code. A fix that pays back in 50 weeks is a bad deal if the system will be replaced in 26, and a good one if you will keep it for two years.
A flat-interest model — this lab keeps interest constant. In real systems interest often grows, as more code is built on top of the debt; treat the lab's paybacks as optimistic for debt that spreads.

🤔 Why

Because "we need time for tech debt" loses every prioritisation meeting (lesson 06) when it is said as a feeling. Said as a price — "the flaky test suite costs us 6 hours every week; fixing it takes 24 hours" — it competes on equal terms with features. And pricing also shows which debt to leave alone: rewriting code nobody touches is one of the most common ways engineering time is wasted.

🔧 How (in this repo)

debt_plan(items, horizon) in lead/models.py takes (name, principal hours, interest hours/week) items. For each it computes the payback period (principal ÷ interest) and the net hours over the horizon (interest × horizon − principal), and says pay if the net is positive and carry if not; the rows come back sorted by payback. debt() in lead/demo.py prices four items at 26 and 104 weeks. The interest numbers are estimates: a thinking tool, not a formula for people — and never a way to blame whoever wrote the code.

🧪 Try it

python3 lead/demo.py debt
python3 - <<'EOF'
import sys; sys.path.insert(0, "lead"); from models import debt_plan
core = [("tangled gradebook core", 200, 4)]
for horizon in (13, 26, 50, 52, 104):
    name, p, i, payback, net, act = debt_plan(core, horizon)[0]
    print(f"gradebook core, horizon {horizon:>3} weeks → net {net:>+5} h → {act}")
for interest in (1, 4, 8):
    r = debt_plan([("core", 200, interest)], 26)[0]
    print(f"interest {interest} h/wk → pays back in {r[3]:>5.1f} weeks")
EOF

✅ Verify — what you should see

debt prints (26-week horizon, then 104):

     flaky test suite         principal  24 h · interest 6 h/wk · pays back in   4.0 wk · net  +132 h → pay
     manual release steps     principal  40 h · interest 5 h/wk · pays back in   8.0 wk · net   +90 h → pay
     tangled gradebook core   principal 200 h · interest 4 h/wk · pays back in  50.0 wk · net   -96 h → carry
     old report module        principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net   -94 h → carry

     tangled gradebook core   principal 200 h · interest 4 h/wk · pays back in  50.0 wk · net  +216 h → pay
     old report module        principal 120 h · interest 1 h/wk · pays back in 120.0 wk · net   -16 h → carry
   total interest 16 h/week out of a team's 160 h/week (10%) — paid every week, whether or not anyone decides to

Your snippet prints:

gradebook core, horizon  13 weeks → net  -148 h → carry
gradebook core, horizon  26 weeks → net   -96 h → carry
gradebook core, horizon  50 weeks → net    +0 h → carry
gradebook core, horizon  52 weeks → net    +8 h → pay
gradebook core, horizon 104 weeks → net  +216 h → pay
interest 1 h/wk → pays back in 200.0 weeks
interest 4 h/wk → pays back in  50.0 weeks
interest 8 h/wk → pays back in  25.0 weeks

🏁 What you just proved

The flaky test suite pays back in 4 weeks and saves 132 hours in half a year — pay it now. The old report module never pays back within two years — carry it. The tangled gradebook core is the interesting one: over 26 weeks fixing it loses 96 hours, over 104 weeks it saves 216; break-even is exactly 50 weeks. So the right answer depends on a plan, not on how ugly the code is. Meanwhile all four items cost 16 hours a week — 10% of the team — paid whether or not anyone decides to.

⚠️ Common mistakes

"a sprint for tech debt" with no list of what, why, and what it will save
rewriting code because it is ugly, not because it is expensive
paying principal on code that is about to be deleted or replaced
never paying, until one day the interest is the whole week
estimating interest from opinions only — look at incidents, flaky runs, time-to-change
treating debt as someone's fault; most debt was a reasonable trade at the time

🏭 In production

A debt register lives next to the backlog, priced the same way:

| Debt item              | Principal | Interest/wk | Payback | Evidence                              | Decision (week 14) |
|------------------------|-----------|-------------|---------|---------------------------------------|--------------------|
| Flaky test suite       | 24 h      | 6 h         | 4 wk    | 31% of CI runs re-run last month      | pay now            |
| Manual release steps   | 40 h      | 5 h         | 8 wk    | 2.5 h per release × 2 releases/wk      | pay this quarter   |
| Tangled gradebook core | 200 h     | 4 h         | 50 wk   | changes take 2× longer than elsewhere | pay if kept 2 yrs  |
| Old report module      | 120 h     | 1 h         | 120 wk  | 3 changes this year                   | carry; revisit Q3  |

Evidence for interest often already exists. On a real repository, the files that change most often are where interest is paid (a rough signal — pair it with what the team says):

git log --since="6 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -15

Many teams also reserve a steady share of capacity for this work (numbers like 15–20% are common) rather than a separate "debt sprint". Whatever the share, the register decides what it is spent on.

🏭 Why this matters in production: price each debt item in hours per week, fix the fast-payback ones now, carry the rest on purpose with a date to look again — and say the total interest out loud in planning, because it is already being paid.

⏭️ Next

How do you know the department is getting better, or worse? Next: delivery metrics — and what happens when a number becomes a target.

git checkout lesson-08-delivery-metrics

← Previousprioritisation Next →delivery metrics

This page is the lesson's README from the lesson-07-technical-debt branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.