4.5.20
Intuition Core picture kya haiSocho tumne paise borrow kiye koi cheez abhi kharidne ke liye, wait karne ki bajaye. Cheez jaldi mil gayi, lekin har mahine interest dete raho jab tak principal wapas nahi karte. Technical debt bilkul wohi trade hai: tum code/design mein shortcut lete ho abhi taaki jaldi ship karo, aur baad mein "interest pay karte ho" — har baar jab us messy code ko touch karte ho, extra effort lagta hai.
YE metaphor kyun important hai: Ward Cunningham (1992) ne ise coin kiya tha, taaki engineers non-functional problems ko business logon ko money terms mein explain kar sakein — "hum abhi jaldi ship karte hain, lekin agli quarter mein hamari velocity 20% drop ho jaayegi."
Definition Technical debtTechnical debt woh implied future cost hai rework ki, jo is wajah se aati hai ki humne ek aasaan/limited solution abhi choose kiya, ek behtar approach ki jagah jo zyada time leti. Iske do parts hain:
Principal = shortcut ko actually fix karne ki cost (usse properly refactor karna).Interest = recurring extra effort — har baar jab tum us unfixed shortcut ke upar kuch build karte ho.
Key distinction: debt aur bug ek jaisi cheez NAHI hai. Bug = galat behaviour. Debt = aisa code jo kaam karta hai lekin change karna, samajhna, ya extend karna mushkil hai.
Software mein ek quantity hoti hai jise understandability/changeability kehte hain. Har shortcut use kam karta hai. Maano:
C C 0 i fractional slowdown),n
Toh shortcut ki wajah se jo total extra cost pay hoti hai woh accumulated interest hai:
Martin Fowler debt ko do axes pe classify karta hai: kya yeh deliberate tha ya inadvertent , aur reckless tha ya prudent ?
Reckless Prudent
Deliberate "Hamare paas design ke liye time nahi hai."
"Hume abhi ship karna hai aur consequences deal karne honge (aur hum jaante hain woh kya hain)."
Inadvertent "Layering kya hoti hai?" (pata hi nahi tha)
"Ab hume pata hai ki hume kaise karna chahiye tha."
Intuition Sirf ek quadrant "good debt" haiDeliberate + Prudent healthy debt hai — ek conscious, tracked loan. Baaki teen usually trouble hain: reckless debt ka koi plan nahi, inadvertent debt toh tumhe notice bhi nahi hua ki li hai.
Common practical categories:
Code debt — duplication, dead code, bura naming, koi tests nahi.Design/architecture debt — galat abstractions, tight coupling, layering violations.Test debt — missing/flaky tests ⇒ code change karne ka darr.Documentation debt — purane ya missing docs.Dependency debt — outdated libraries, unpatched versions ("software rot").Infrastructure/build debt — slow CI, manual deploys.
Definition Technical debt manage karna = usevisible , prioritised , aur paid down banana
Kabhi zero debt nahi ho sakti (kuch debt optimal hoti hai). Goal control hai, elimination nahi.
Workflow:
Visible banao — ek debt register/backlog rakho, // TODO/FIXME tags lagao, static analysis use karo (SonarQube), ek debt ratio track karo = remediation cost / development cost.Quantify karo — principal P i , n Prioritise karo — us code mein debt pehle fix karo jise tum aksar change karte ho (high n Pay down karo — strategies:
Boy Scout Rule : "code ko waisa chhodo jaise paya tha usse zyada clean" (continuous choti choti repayment).Dedicated % : har sprint ka e.g. 20% refactoring ke liye reserve karo.Refactor-before-feature : jis area ko extend karne wale ho, pehle usse clean karo.
Prevent karo — code review, definition-of-done, automated tests, linters.
Worked example Worked example 1 — kya hume refactor karna chahiye?Ek payment module "spaghetti" hai. Clean change cost C 0 = 2 i = 0.5 n = 10 P = 6
Step: future interest = n C 0 i = 10 × 2 × 0.5 = 10 Yeh step kyun? Yeh woh extra time hai jo hum waste karenge agar hum fix NAHI karte.Step: compare karo P = 6 < 10 Kyun? Ek baar repay karna (6) interest carry karne (10) se sasta hai. ⇒ Abhi Refactor karo. Net saving ≈ 4 din.
Worked example Worked example 2 — debt RAKHNE ka faisla kab kareinEk reporting script saal mein ek baar chalti hai, shayad delete ho jaaye. n ≈ 1 C 0 = 1 i = 0.5 P = 4
Future interest = 1 × 1 × 0.5 = 0.5
P = 4 > 0.5 refactor mat karo. Kyun? Fix karne ki cost kahin zyada hai us interest se jo tum kabhi pay karoge. Yeh prudent debt hai jise rakhna theek hai.
Worked example Worked example 3 — classify karnaTeam jaanbujhkar tests likhna skip karti hai demo deadline hit karne ke liye, aur agli sprint mein tests add karne ka ticket log karti hai.
Deliberate? Haan (jaanbujhkar choose kiya). Reckless? Nahi (tracked hai, plan hai). ⇒ Deliberate–Prudent : acceptable, managed debt. Yeh kyun matter karta hai: ticket hi ise reckless ki jagah prudent banata hai.
Common mistake "Hume SAARI technical debt eliminate kar deni chahiye."Kyun sahi lagta hai: clean code accha hai, toh zyada clean zyada accha hona chahiye. Flaw: refactoring ki cost hoti hai (P P > n C 0 i paisa kho dena hai. Fix: optimal debt level ka aim karo — sirf wahan repay karo jahan future interest fix cost se zyada ho.
Common mistake "Technical debt = bugs / bura code."Kyun sahi lagta hai: dono "code mein problems" hain. Flaw: debt aisa code mein ho sakti hai jo perfectly kaam karta ho; yeh changeability ke baare mein hai, correctness ke baare mein nahi. Fix: debt ko future-rework cost ke roop mein define karo; ek clever-lekin-jaldi-mein-bana feature jisme koi tests nahi hai, woh debt hai chahe aaj zero bugs hon.
Common mistake "'Baad mein' jab time milega tab pay down kar lenge."Kyun sahi lagta hai: features zyada urgent lagte hain. Flaw: interest compound hota hai — debt tumhe slow karta hai, toh 'baad mein' kabhi aata hi nahi (ek debt spiral). Fix: repayment ko scheduled banao (Boy Scout rule / reserved sprint %), "agar time mila toh" wali soch nahi.
Recall Feynman: ek 12-saal ke bachche ko samjhaoApna kamra imagine karo. Tum jaldi mein ho toh saari cheezein bed ke neeche dha dete ho rakhne ki jagah. Ab kamra theek lagta hai aur tum jaldi finish ho gaye — yeh shortcut hai. Lekin har baar jab moze chahiye, poore dher mein khodna padta hai (yeh interest hai — har baar extra effort). Agar roz moze chahiye, toh abhi theek se safai karna worth it hai (yeh principal pay karna hai). Agar kal ghar badal rahe ho aur sab phenk doge, toh dher aise hi chhod do! Acche programmers apna kamra perfect nahi rakhte — woh jo cheez zyada use hoti hai use tidy rakhte hain, aur baaki chhod dete hain.
Mnemonic Management loop yaad karo:V-Q-P-P-P
V isible → Q uantify → P rioritise → P ay-down → P revent.
Aur trade yaad karo: "P rincipal pay karo pehle ki i nterest tumhare n changes kha jaaye."
Technical debt ke do financial parts kya hain? Principal (shortcut fix karne ki cost) aur Interest (unfixed code pe kaam karte waqt har baar recurring extra effort).
"Technical debt" metaphor kisne coin kiya? Ward Cunningham (1992).
Debt repay karne ka rule of thumb kya hai? Repay karo jab P < n C 0 i n
Kya technical debt aur bug ek hi cheez hai? Nahi. Bug = galat behaviour. Debt = aisa working code jo change/samajhna/extend karna costly ho.
Fowler's technical-debt quadrant ke do axes kya hain? Deliberate vs Inadvertent, aur Reckless vs Prudent.
Kaunsa quadrant "healthy" debt hai? Deliberate + Prudent (ek conscious, tracked, planned loan).
Boy Scout Rule kya hai? "Code ko hamesha waisa chhodo jaise paya tha usse zyada clean" — debt ki continuous choti choti repayment.
Technical debt ke char types batao. Code, design/architecture, test, documentation (aur dependency, infrastructure bhi).
"Saari debt eliminate karo" kyun galat hai? Refactoring mein principal + opportunity cost lagti hai; rarely-touched code ke liye fix cost interest saved se zyada hoti hai, isliye kuch debt optimal hoti hai.
Static analysis mein debt ka size kaunsa metric measure karta hai? Debt ratio = remediation cost / development cost.
Debt ignore karne se "debt spiral" kyun hoti hai? Interest future kaam ko slow karta hai, jisse repay karne ka time aur kam milta hai, toh debt aur slowdown dono compound hote rehte hain.
Refactoring — principal pay down karne ka primary tool.Code Smells — observable symptoms jo debt signal karte hain.Unit Testing / Test Driven Development — test debt kam karta hai aur refactoring ko safe banata hai.Software Maintainability — debt ek maintainability cost hai.Agile Sprint Planning — yahan tum repayment ke liye % capacity reserve karte ho.Coupling and Cohesion — high coupling design debt ka ek major source hai.Continuous Integration — infrastructure debt yahan rehti hai.
Interest recurring effort
