Technical debt وہ فاصلہ ہے جو کوڈ کے موجودہ حالت اور اس کی مطلوبہ حالت کے درمیان ہے، جو تیز رفتار حرکت کے لیے (جان بوجھ کر یا نہ کر کے) اٹھایا جاتا ہے۔ کچھ ڈیٹ ٹھیک ہے؛ کام یہ ہے کہ اسے منظم کریں، اسے ختم نہ کریں۔ اہم بات یہ ہے کہ اس ڈیٹ کو ترجیح دیں جو واقعی نقصان پہنچاتا ہے۔
اثر کے لحاظ سے ترجیح دیں، پریشانی کے لحاظ سے نہیں
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
