آپ تکنیکی ڈیٹ کو کیسے شناخت، ترجیح دیتے ہیں، اور ادا کرتے ہیں؟

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

ایک ٹھوس مثال

ایک نازک ماڈیول جو ہر release پر ٹوٹتا ہے اور ہفتے میں ٹیم کو روکتا ہے، اسے ٹھیک کرنے کے قابل ہے۔ ایک بدصورت لیکن مستحکم utility جس کو کوئی نہیں چھیڑتا ہے، چاہے یہ آپ کو ناراض کرے۔ اس کو refactor کرنا غرور ہے، قیمت نہیں۔