4.5 تکنیکی قرض کی پیمائش

جائزہ اور محرک

تکنیکی قرض (technical debt)، جو Ward Cunningham کی وضع کردہ استعارہ ہے، ماضی کے شارٹ کٹس کی جمع شدہ لاگت بیان کرتا ہے، فوری فیصلے جنہوں نے کچھ جلد بھیجا مگر بعد میں کوڈ بیس کو بدلنا مشکل چھوڑ دیا، بالکل اس طرح جیسے مالیاتی قرض آپ کو بعد میں سود کی قیمت پر ابھی خرچ کرنے دیتا ہے۔ ہر کوڈ بیس کچھ تکنیکی قرض اٹھاتا ہے، اور یہ خودکار طور پر ناکامی نہیں؛ استعارے کی حقیقی قدر یہ ہے کہ یہ قرض کو شرمناک راز یا ناگزیر، مستقل بوجھ کے بجائے قابلِ انتظام سمجھوتے کے طور پر پیش کرتا ہے۔ یہ موضوع اس سمجھوتے کو پیمائش کے ذریعے نظر آنے والا اور قابلِ انتظام بنانے کے بارے میں ہے، اسے مبہم، مستقل طور پر کم ترجیح والی فکر کے طور پر چھوڑنے کے بجائے جسے ہر انجینئر محسوس کرتا ہے مگر کوئی ثبوت کے ساتھ اس پر عمل نہیں کر سکتا۔

اس سے پہلے کے موضوعات، پیچیدگی (4.1)، کوریج (4.2)، churn اور hotspots (4.3)، اور static analysis (4.4)، ہر ایک تکنیکی قرض کا ایک پہلو سامنے لاتا ہے۔ اس موضوع کا کام تالیف ہے: ان الگ اشاروں کو، ان آئٹمز کے ساتھ جو کسی خودکار اسکین میں کبھی ظاہر نہیں ہوتے (غیر دستاویزی فن تعمیر کا شارٹ کٹ، دانستہ طور پر مؤخر کی گئی مائیگریشن)، ایک واحد، ترجیح پر مبنی، نظر آنے والے بیک لاگ میں بدلنا جو فیچر کے کام کے مقابل سرمایہ کاری کے لیے منصفانہ طور پر مقابلہ کرتا ہے، اس مقابلے کو ڈیفالٹ طور پر محض اس لیے ہارنے کے بجائے کہ اس کے ساتھ کوئی میٹرک نہیں جڑا اور منصوبہ بندی کے اجلاسوں میں کوئی وکیل نہیں۔

بڑی ٹیموں کے لیے غیر منظم تکنیکی قرض ایسے طریقے سے مرکب ہوتا ہے جو حقیقتاً خطرناک اور کم اندازہ لگانا آسان ہے: ہر نیا شارٹ کٹ اگلی تبدیلی کو ذرا مشکل کر دیتا ہے، جو مزید شارٹ کٹس کا دباؤ پیدا کرتا ہے، جو مزید مرکب ہوتا ہے۔ کئی سال نظام چلانے والے بڑے اور حکومتی ادارے اس مرکب اثر کے خاص طور پر شکار ہیں، اور اس موضوع کی مرکزی سفارش، نظر آنے والا، مقداری، ترجیح پر مبنی قرض کا بیک لاگ، وہ میکانزم ہے جو ادارے کو بحران میں بھٹکنے کے بجائے اس سمجھوتے کو حقیقتاً دانستہ منظم کرنے دیتا ہے۔

بنیادی اصول

تکنیکی قرض قابلِ انتظام سمجھوتے کا دانستہ استعارہ ہے، شرمناک راز نہیں۔ کچھ قرض، جان بوجھ کر لیا گیا، معقول کاروباری فیصلہ ہے۔
غیر ناپا گیا قرض فیچر کے کام کے خلاف ترجیح کا مقابلہ ڈیفالٹ طور پر ہار جاتا ہے، اس لیے نہیں کہ وہ کم اہم ہے بلکہ اس لیے کہ اس کا کوئی نظر آنے والا وکیل نہیں۔
قرض کو ان اصطلاحات میں مقدار میں لائیں جنہیں فیصلہ ساز تول سکیں: ٹھیک کرنے کی لاگت بمقابلہ اسے اٹھائے رکھنے کی لاگت۔ مبہم “کوڈ بے ترتیب ہے” کا دعویٰ شاذ و نادر ٹھوس فیچر کی درخواست کے مقابل اچھا مقابلہ کرتا ہے۔
قرض مرکب ہوتا ہے۔ ہر نیا شارٹ کٹ مستقبل کی تبدیلیوں کو معمولی طور پر مشکل کر دیتا ہے، اور وہ اثر بغیر انتظام کے تیز ہوتا ہے۔
تمام قرض اتارنا ضروری نہیں۔ کچھ کو غیر معینہ مدت تک اٹھائے رکھنا قابلِ قدر ہے اگر اسے ٹھیک کرنے کی لاگت اس کے ساتھ جینے کی لاگت سے زیادہ ہو۔

سفارشات

نظر آنے والا، واحد تکنیکی قرض کا بیک لاگ بنائیں

اس حصے کے پچھلے موضوعات کے اشارے، پیچیدگی کے غیر معمولی اعداد، کم میوٹیشن کِل ریٹ والے علاقے، hotspots، غیر حل شدہ static analysis کی دریافتیں، ان قرض کے آئٹمز کے ساتھ جنہیں صرف انسان پہچان سکتا ہے (فن تعمیر کا شارٹ کٹ، مؤخر کیا گیا انحصار کی اپ گریڈ، غیر دستاویزی عارضی حل) ایک نظر آنے والے بیک لاگ میں یکجا کریں، جسے اپنے فیچر بیک لاگ جیسی سختی اور نظر پذیری سے ٹریک کیا جائے۔ جو قرض صرف انفرادی انجینئروں کی یادداشت یا بکھرے کوڈ کے تبصروں میں رہتا ہے وہ ترجیح کے مقاصد کے لیے عملاً موجود ہی نہیں۔

ہر قرض کے آئٹم کی لاگت اور اسے اٹھائے رکھنے کی لاگت مقدار میں لائیں

ہر آئٹم کے لیے دو اعداد کا اندازہ لگائیں: اسے ٹھیک کرنے کی لاگت (انجینئرنگ کا وقت، خود اصلاح کا خطرہ) اور اسے بغیر ٹھیک کیے اٹھائے رکھنے کی لاگت (متعلقہ کام کتنا سست ہوتا ہے، اس سے کتنا اضافی نقص کا خطرہ جڑا ہے، یہ دوسرے کام کو کتنا روکتا ہے)۔ یہ فریمنگ، جو براہِ راست مالیاتی قرض کے استعارے کی اپنی منطق سے لی گئی ہے، فیصلہ سازوں کو فیچر کے کام کی لاگت اور متوقع قدر کے مقابل موازنے کی حقیقی بنیاد دیتی ہے، تجریدی، غیر مقداری شکایت کے بجائے۔

عمر یا سب سے بلند وکیل سے نہیں، اثر سے ترجیح دیں

قرض کے آئٹمز کی درجہ بندی ان کی اٹھانے کی لاگت اور متاثرہ کوڈ کتنی بار چھوا جاتا ہے (موضوع 4.3 کا churn کا ڈیٹا یہاں براہِ راست مفید ہے) کے مجموعے سے کریں: کوڈ بیس کے شاذ و نادر بدلنے والے کونے میں کوئی آئٹم، چاہے کتنا ہی ناگوار ہو، آپ کی سب سے فعال ڈویلپمنٹ کے راستے میں براہِ راست بیٹھے آئٹم سے کہیں کم اہم ہے۔ اس بنیاد پر ترجیح دینے کا مقابلہ کریں کہ کون سا آئٹم بیک لاگ میں سب سے زیادہ دیر سے ہے یا کون سا انجینئر اس کی سب سے زیادہ استقامت سے وکالت کرتا ہے، جن میں سے کوئی بھی قابلِ اعتماد طور پر اصل کاروباری اثر سے ہم رشتہ نہیں۔

قرض کی اصلاح کے لیے مخصوص، محفوظ صلاحیت مختص کریں

وہ قرض کا بیک لاگ جسے ہر منصوبہ بندی کے چکر میں ہر آنے والی فیچر کی درخواست کے خلاف آئٹم بہ آئٹم مقابلہ کرنا پڑے مسلسل ہارنے کا رجحان رکھتا ہے، کیونکہ فیچر کے کام کا عموماً زیادہ واضح، زیادہ فوری کاروباری وکیل ہوتا ہے۔ انجینئرنگ کی صلاحیت کا محفوظ فیصد مختص کریں، عام نمونہ 10 اور 20 فیصد کے درمیان کہیں ہے، خاص طور پر قرض کی اصلاح کے لیے، پہلے سے طے شدہ بجائے ہر اسپرنٹ نئے سرے سے مذاکرات کیے جانے کے، تاکہ قرض کی ادائیگی معمول کے طور پر ہو، صرف بحران کے بعد نہیں۔

کچھ قرض کو مستقل قبول کریں، اور صریح طور پر کہیں

ہر آئٹم فعال اصلاح کے منصوبے کا حصہ نہیں۔ جہاں ٹھیک کرنے کی لاگت حقیقتاً کسی آئٹم کو غیر معینہ مدت تک اٹھانے کی لاگت سے بڑھ جائے، خاص طور پر مستحکم، شاذ و نادر چھوئے جانے والے، جلد ریٹائر ہونے والے نظام کے کوڈ کے لیے، اس فیصلے کو صریح طور پر دستاویز کریں اور آئٹم کو دانستہ طور پر کم ترجیح والے زمرے میں منتقل کریں، بجائے اسے غیر معینہ مدت تک فعال بیک لاگ پر پڑا رہنے دینے کے جہاں اس کی مسلسل موجودگی خاموشی سے ایسے کام کا اشارہ دیتی ہے جو دراصل کبھی نہیں ہوگا۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
کوئی رسمی قرض کی ٹریکنگ نہیں	کوئی بوجھ نہیں	قرض ڈیفالٹ طور پر ترجیح کا مقابلہ ہارتا ہے؛ غیر مرئی طور پر مرکب ہوتا ہے
غیر رسمی، وقتی قرض کی آگاہی	کم بوجھ، کچھ نظر پذیری	غیر یکساں؛ انفرادی یادداشت اور وکالت پر منحصر
رسمی، مقداری قرض کا بیک لاگ	سرمایہ کاری کے لیے منصفانہ مقابلہ کرتا ہے؛ باخبر سمجھوتے ممکن بناتا ہے	جاری دیکھ بھال اور مقدار میں لانے کا نظم درکار
محفوظ، مخصوص اصلاح کی صلاحیت	یقینی بناتی ہے کہ ادائیگی یکساں طور پر ہو، صرف ردِعمل میں نہیں	مختصر مدت میں فیچر کے کام کے لیے دستیاب صلاحیت گھٹاتی ہے

مرکزی کشمکش فوری ڈیلیوری کا دباؤ بمقابلہ طویل مدتی برقرار رکھنے کی صلاحیت ہے۔ فیچر کے کام کا تقریباً ہمیشہ قرض کی اصلاح سے زیادہ واضح، زیادہ فوری کاروباری وکیل ہوتا ہے، جو ساختی دباؤ پیدا کرتا ہے کہ قرض ہر انفرادی ترجیح کے فیصلے میں ہارے، چاہے اس کی مجموعی لاگت زیادہ ہو۔ اس کشمکش کو یوں حل کریں کہ قرض کی اصلاح کو محفوظ، پہلے سے مختص صلاحیت کے ذریعے آئٹم بہ آئٹم مقابلے سے مکمل ہٹا دیں، تاکہ سمجھوتے کا فیصلہ ہر منصوبہ بندی کے چکر میں دوبارہ بحث اور اکثر ہارنے کے بجائے دانستہ اور پہلے سے ہو۔

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات

کیا ہمارے پاس واحد، نظر آنے والا تکنیکی قرض کا بیک لاگ ہے، یا قرض کی آگاہی زیادہ تر انفرادی انجینئروں کے ذہنوں میں رہتی ہے؟ اگر ایماندار جواب بعد والا ہے تو یہ وہ واحد سب سے بڑا خلا ہے جسے یہ موضوع سب سے پہلے بند کرنے کی سفارش کرتا ہے۔
اپنے اوپر کے قرض کے آئٹم کے لیے، کیا ہم اس کی ٹھیک کرنے کی لاگت اور اٹھانے کی لاگت فیچر کی درخواست سے منصفانہ موازنے کے لیے کافی مخصوص اصطلاحات میں بتا سکتے ہیں؟ اگر نہیں، تو حقیقی، موجودہ آئٹم کا استعمال کرتے ہوئے گروہی مشق کے طور پر مل کر یہ مقدار بندی مشق کریں۔
ہماری انجینئرنگ کی صلاحیت کا کتنا فیصد دراصل قرض کی اصلاح پر جاتا ہے، اور کیا وہ فیصد دانستہ طے ہوا یا بس وہی ہے جو فیچر کے کام کی تقسیم کے بعد بچ جاتا ہے؟ تاثر پر انحصار کرنے کے بجائے اپنی حالیہ اسپرنٹس دیکھیں اور اصل عدد حساب کریں۔
کیا ہمارا قرض کا بیک لاگ حقیقی کاروباری اثر کے لحاظ سے ترجیح دیا جاتا ہے، یا اس آئٹم کی بنیاد پر جو سب سے استقامت سے اٹھایا گیا یا سب سے زیادہ دیر سے پڑا ہے؟ اپنی موجودہ ترجیح کو churn کے ڈیٹا (موضوع 4.3) سے ملائیں اور دیکھیں کہ دونوں ہم آہنگ ہیں یا نہیں۔
کون سے قرض کے آئٹمز کو ہمیں صریح طور پر مستقل قبول کرنا چاہیے، بجائے اسے فعال بیک لاگ پر غیر معینہ مدت تک پڑا رہنے دینے کے؟ کم از کم ایک حقیقی آئٹم کی نشاندہی کریں جہاں ٹھیک کرنے کی لاگت حقیقتاً اٹھانے کی لاگت سے بڑھ جائے اور اسے صریح طور پر کم ترجیح والی حیثیت میں منتقل کرنے پر بحث کریں۔
پچھلے سال میں ہمارا قرض کا بیک لاگ کیسے بدلا ہے، بڑھا، سکڑا، یا چپٹا رہا، اور کیا وہ رجحان ہمارے وجدان سے ملتا ہے؟ اسے وقت کے ساتھ ٹریک کریں بجائے صرف کبھی اکیلے اسنیپ شاٹ دیکھنے کے؛ رجحان اکثر کسی بھی لمحے مطلق سائز سے زیادہ معلوماتی ہوتا ہے۔

شعبے کا زاویہ

اسٹارٹ اپ۔ دانستہ، باخبر قرض اس مرحلے پر اکثر معقول حکمتِ عملی ہے: مفروضے کی توثیق کے لیے تیزی سے بھیجنا، اگر پروڈکٹ کامیاب ہو تو مخصوص شارٹ کٹس پر دوبارہ جانے کے واضح منصوبے کے ساتھ، جائز سودا ہے، ناکامی نہیں۔ خطرہ یہ ہے کہ کون سے شارٹ کٹ دانستہ اور قابلِ واپسی تھے بمقابلہ کون سے خاموشی سے مستقل، غیر جانچی ذمہ داریاں بن گئے جب کوڈ بیس بڑھتا ہے اس کا حساب ہاتھ سے نکل جائے۔

چھوٹا کاروبار۔ سادہ، مشترکہ فہرست، غیر رسمی بھی، جو آپ کے معلوم شارٹ کٹس اور ان کے ٹھیک کرنے کی تقریباً لاگت کا نام لے، اس پیمانے پر عموماً کافی ہے۔ جس بنیادی نظم کو اپنانا قابلِ قدر ہے وہ اس فہرست پر دورانیہ وار دوبارہ جانا ہے، اسے خاموشی سے جمع ہو کر واقفیت کی وجہ سے غیر مرئی بننے دینے کے بجائے۔

بڑا ادارہ۔ محفوظ، پہلے سے مختص اصلاح کی صلاحیت یہاں سب سے زیادہ اہم ہے، کیونکہ قرض اور فیچر کے کام کے درمیان انفرادی ترجیح کا مقابلہ ساختی جوابی وزن کے بغیر درجنوں ٹیموں میں بیک وقت قابلِ اعتماد طور پر فیچرز کے حق میں ہوتا ہے۔ قرض کی مقدار بندی کی مشق کو پورے ادارے میں معیاری بنائیں تاکہ پورٹ فولیو کی سطح کے سرمایہ کاری کے فیصلوں کے لیے ٹیموں میں قرض کے آئٹمز کا منصفانہ موازنہ ہو سکے۔

حکومت۔ طویل عرصے سے چلنے والے نظام برسوں یا دہائیوں کی بتدریج، انفرادی طور پر معقول ضروریات کی تبدیلیوں سے قرض جمع کرتے ہیں، اکثر بحران کے مسئلہ پر مجبور کرنے تک کسی رسمی قرض کی ٹریکنگ کے بغیر۔ نظر آنے والا، مقداری قرض کا بیک لاگ نگران اداروں کے سامنے جدید کاری کے بجٹ کا جواز دینے کا حقیقتاً قائل کرنے والا ٹول ہے، کیونکہ یہ مبہم “نظام پرانا ہے” کے دعوے کو سرمایہ کاری کے مخصوص، لاگت والے مقدمے میں بدل دیتا ہے۔

مثالیں

بڑا ادارہ۔ ایک ٹیلی کمیونیکیشنز کمپنی کے بلنگ پلیٹ فارم نے دہائی بھر غیر رسمی طور پر تسلیم شدہ مگر کبھی رسمی ٹریک نہ کیا گیا تکنیکی قرض جمع کر لیا تھا، انجینئر معمول کے مطابق ریٹروسپیکٹوز میں بغیر کسی فالو تھرو کے “بلنگ انجن بے ترتیب ہے” کا حوالہ دیتے تھے۔ انجینئرنگ کے نئے ڈائریکٹر نے ہر ٹیم سے مقداری قرض کا بیک لاگ بنانے کا تقاضا کیا، ہر آئٹم کی ٹھیک کرنے کی لاگت اور اٹھانے کی لاگت کا اندازہ لگاتے ہوئے، اور آئندہ کے لیے انجینئرنگ کی صلاحیت کا مقررہ 15 فیصد قرض کی اصلاح کے لیے مختص کیا۔ ایک سال کے اندر اوپر کے پانچ سب سے زیادہ اٹھانے کی لاگت والے آئٹمز، جو گنتی کے لحاظ سے کل بیک لاگ کے چھوٹے حصے کی نمائندگی کرتے تھے، حل ہو گئے، اور بلنگ سے متعلق ڈیپلائز کے لیے تبدیلی کی ناکامی کی شرح (موضوع 2.10) ناپنے کے قابل طور پر بہتر ہوئی، بیک لاگ کو من مانی ترتیب میں نمٹانے کے بجائے سب سے زیادہ اٹھانے کی لاگت والے آئٹمز کو پہلے ہدف بنانے کا غیر متناسب اثر دکھاتے ہوئے۔

حکومت۔ ایک قومی شماریات ایجنسی کا بنیادی ڈیٹا پروسیسنگ سسٹم، جو بیس سال پہلے بنایا گیا تھا، عملے میں وسیع غیر رسمی اعتراف کے باوجود کہ اس کے نمایاں حصے نازک اور کم سمجھے گئے ہیں، رسمی قرض کا جائزہ کبھی نہیں رکھتا تھا۔ ساختہ قرض کے جائزے نے، static analysis کی دریافتیں، hotspot کا ڈیٹا، اور ان چند باقی انجینئروں کے انٹرویو ملا کر جو سب سے پرانے اجزا سمجھتے تھے، مقداری، ترجیحی بیک لاگ پیدا کیا جس نے براہِ راست کئی سالہ جدید کاری کی بجٹ کی درخواست کی حمایت کی۔ اہم طور پر، جائزے نے کئی مستحکم، شاذ و نادر چھوئے جانے والے پرانے اجزا کی صریح طور پر نشاندہی بھی کی جنہیں بغیر بدلے چھوڑنا معقول تھا، بلا ضرورت وسیع اور مہنگے مکمل نظام کو دوبارہ لکھنے سے بچتے ہوئے ان مخصوص علاقوں میں ہدف والی سرمایہ کاری کے حق میں جن کے بارے میں ڈیٹا نے دکھایا کہ سب سے زیادہ جاری لاگت اٹھاتے ہیں۔

کاروباری جواز: محرکات، ROI، اور TCO

تکنیکی قرض کو دانستہ منظم کرنے کا منافع مرکب ہوتی لاگت سے بچنا ہے: ہر غیر حل شدہ شارٹ کٹ مستقبل کی تبدیلیوں کو معمولی طور پر مشکل کرتا ہے، اور وہ اثر مداخلت کے بغیر تیز ہوتا ہے، آخرکار اتنا نازک کوڈ بیس پیدا کرتا ہے کہ سادہ تبدیلیاں بھی سست اور خطرناک ہو جاتی ہیں۔ اوپر کی ٹیلی کمیونیکیشنز کی مثال منافع کو ٹھوس طور پر دکھاتی ہے: سب سے زیادہ اٹھانے کی لاگت والے آئٹمز کی چھوٹی تعداد کو ہدف بنانے نے ڈیلیوری اور معیار میں ناپنے کے قابل بہتری پیدا کی، ان آئٹمز کے نمائندہ کل بیک لاگ کے معمولی حصے کے غیر متناسب۔

ملکیت کی کل لاگت اصلاح کے لیے مختص محفوظ صلاحیت ہے، عموماً انجینئرنگ کے وقت کا 10 سے 20 فیصد، جو حقیقی، نظر آنے والی لاگت ہے جو مختصر مدت میں فیچر کی رفتار کے ساتھ مقابلہ کرتی ہے۔ وہ لاگت ادا کرنا قابلِ قدر ہے کیونکہ متبادل، غیر منظم، مرکب ہوتا قرض، آخرکار پورے کوڈ بیس میں سست ڈیلیوری اور بڑھی ہوئی نقص کی شرحوں میں کہیں زیادہ لاگت اٹھاتا ہے، صرف وہ مخصوص آئٹمز نہیں جو غیر حل شدہ چھوڑے گئے۔

منفی نمونے اور خطرات

کوئی نظر آنے والا، ٹریک شدہ قرض کا بیک لاگ نہیں: قرض ڈیفالٹ طور پر ترجیح کا مقابلہ ہارتا ہے اور غیر مرئی طور پر مرکب ہوتا ہے۔
مبہم، غیر مقداری قرض کے دعوے: منصوبہ بندی میں ٹھوس، مقداری فیچر کی درخواستوں کے مقابل شاذ و نادر اچھا مقابلہ کرتے ہیں۔
اثر کے بجائے عمر یا وکالت کی بلندی سے قرض کو ترجیح دینا: محدود اصلاح کی صلاحیت کو غلط سمت میں لے جاتا ہے۔
اصلاح کے لیے کوئی محفوظ صلاحیت نہیں: قرض کی ادائیگی صرف ردِعمل میں، بحران کے بعد ہوتی ہے، معمول کی، دانستہ مشق کے طور پر نہیں۔
تمام قرض کو برابر ٹھیک کرنے کے قابل سمجھنا: کم اثر کے آئٹمز پر کوشش ضائع کرتا ہے جبکہ زیادہ اٹھانے کی لاگت والے آئٹمز غیر حل شدہ رہتے ہیں۔
قرض کو فعال بیک لاگ پر غیر معینہ مدت تک پڑا رہنے دینا بغیر کبھی فیصلہ کیے کہ وہ مستقل ہے: ایسے مستقبل کے کام کا اشارہ دیتا ہے جو دراصل کبھی نہیں ہوگا اور حقیقی ترجیح کو بے ترتیب کرتا ہے۔

پختگی کا نمونہ

درجہ 1، آغاز (Initiate): تکنیکی قرض پر غیر رسمی طور پر بات ہوتی ہے، نہ ٹریک شدہ بیک لاگ نہ مقدار بندی؛ وہ مسلسل فیچر کے کام سے ہارتا ہے۔
درجہ 2، ترقی (Develop): کچھ ٹیمیں قرض کو غیر رسمی طور پر ٹریک کرتی ہیں، لیکن کوئی یکساں مقدار بندی، ٹیموں کے آر پار نظر پذیری، یا محفوظ اصلاح کی صلاحیت نہیں۔
درجہ 3، معیار بندی (Standardize): ادارے بھر میں نظر آنے والا، مقداری قرض کا بیک لاگ ہے، محفوظ اصلاح کی صلاحیت یکساں مختص کے ساتھ۔
درجہ 4، انتظام (Manage): قرض کے آئٹمز کو ناپے گئے اثر (اٹھانے کی لاگت کو churn کے ساتھ ملا کر) سے ترجیح دی جاتی ہے، اور مستقل طور پر قبول کیا گیا قرض مبہم چھوڑے جانے کے بجائے صریح طور پر دستاویزی ہے۔
درجہ 5، ہم آہنگی (Orchestrate): ادارہ ہدف والی قرض کی اصلاح سے منسوب مخصوص، ناپنے کے قابل ڈیلیوری یا معیار کی بہتریوں کی نشاندہی کر سکتا ہے، اور قرض کا انتظام فیچر کے کام کے ساتھ انجینئرنگ سرمایہ کاری کے فیصلوں کا معمول کا، قابلِ اعتماد ان پٹ ہے۔

بحث کے لیے خیالات

ہمارا اس وقت سب سے زیادہ اٹھانے کی لاگت والا قرض کا آئٹم کون سا ہے، اور کیا ہم اسے مقدار میں لا سکتے ہیں؟
ہماری صلاحیت کا کتنا فیصد آج دراصل قرض کی اصلاح پر جاتا ہے؟
ہمیں اپنے بیک لاگ پر مبہم چھوڑنے کے بجائے کون سا قرض کا آئٹم صریح طور پر مستقل قبول کرنا چاہیے؟
کیا پچھلے سال میں ہمارا قرض کا بیک لاگ بڑھا، سکڑا، یا چپٹا رہا؟
مقداری قرض کا جائزہ ایسا کیا ظاہر کرے گا جو ہماری موجودہ غیر رسمی آگاہی چھوڑ رہی ہے؟

اہم نکات

تکنیکی قرض قابلِ انتظام سمجھوتہ ہے، شرمناک راز نہیں؛ اسے مبہم، مستقل طور پر کم ترجیح والی فکر کے طور پر چھوڑنے کے بجائے مقدار میں لائیں۔
ہر آئٹم کے لیے ٹھیک کرنے کی لاگت بمقابلہ اٹھانے کی لاگت مقدار میں لائیں تاکہ وہ فیچر کے کام کے مقابل منصفانہ مقابلہ کرے۔
اثر سے ترجیح دیں (اٹھانے کی لاگت کو churn کے ساتھ ملا کر)، عمر یا وکالت کی بلندی سے نہیں۔
محفوظ، مخصوص اصلاح کی صلاحیت مختص کریں، پہلے سے طے شدہ، کیونکہ بصورتِ دیگر قرض آئٹم بہ آئٹم فیچر کے کام کے مقابلے میں قابلِ اعتماد طور پر ہارتا ہے۔
جہاں ٹھیک کرنے کی لاگت اٹھانے کی لاگت سے بڑھ جائے وہاں کچھ قرض کو صریح طور پر مستقل قبول کریں، اسے فعال بیک لاگ پر مبہم طور پر چھوڑنے کے بجائے۔

حوالہ جات اور مزید مطالعہ

Cunningham, Ward, “The WyCash Portfolio Management System” (OOPSLA experience report, 1992): تکنیکی قرض کے استعارے کا ماخذ۔
Managing Technical Debt: Reducing Friction in Software Development, by Philippe Kruchten, Robert Nord, and Ipek Ozkaya (تکنیکی قرض کی پیمائش اور انتظام کا جامع علاج)۔
Refactoring: Improving the Design of Existing Code, by Martin Fowler (اصلاح کی تکنیکیں جن پر قرض کا بیک لاگ آخرکار انحصار کرتا ہے)۔
Your Code as a Crime Scene, by Adam Tornhill (قرض کی ترجیح کے لیے ان پٹ کے طور پر hotspot کا تجزیہ، موضوع 4.3)۔