technical debt और नए features के बीच समय कैसे बांटते हैं, यह आप कैसे तय करते हैं?

debt को नैतिक मुद्दा नहीं, बिज़नेस की लागत मानिए। उसे नापिए: यह डिलीवरी कितनी धीमी करता है, कितने incidents पैदा करता है, और फेल हो गया तो क्या होगा। फिर उसे features वाली उसी बातचीत में फंड करें, या तो एक स्थायी हिस्से के रूप में (अक्सर पंद्रह से बीस प्रतिशत) या उस इलाके को छूने वाले roadmap के काम के साथ जोड़कर। वही debt चुकाएं जिस पर सच में ब्याज चढ़ रहा है, वह कोड नहीं जो आपको पसंद नहीं।

मैं इसे अलग नैतिक बहस की तरह चलाने से मना करता हूं, क्योंकि उसमें इंजीनियरिंग हमेशा हारती है। मैं इसे लागत की बातचीत बनाता हूं। हम एक debt register रखते हैं जिसमें हर आइटम की लागत का अनुमान होता है: यह सर्विस उसे छूने वाले हर feature में दो दिन जोड़ देती है, उसने पिछले दस incidents में से चार पैदा किए, यह dependency नौ महीने में सपोर्ट से बाहर हो रही है और एक compliance नवीनीकरण रोक देगी। फिर मैं कोड की बदसूरती नहीं, ब्याज दर के हिसाब से प्राथमिकता तय करता हूं, क्योंकि बहुत सारा भद्दा कोड स्थिर है, कोई उसे छूता नहीं, और वह हमेशा वैसा ही रह सकता है। फंडिंग पर मेरा डिफ़ॉल्ट है स्थायी बीस प्रतिशत और साथ में roadmap के काम से जुड़ी सफाई, ताकि अगर हम पहले से उसी इलाके में हैं तो वहीं ठीक कर दें। प्रोडक्ट को जो दलील समझ आती है वह हमेशा डिलीवरी वाली होती है। पिछली टीम में मैं दिखा सका कि हमारे incident का दो तिहाई समय एक ही legacy रास्ते से आता है, और जैसे ही यह इस तरह रखा गया कि इससे हमें महीने में एक हफ्ता गंवाना पड़ता है, छह हफ्ते का fix लड़ाई नहीं, आसान सौदा बन गया।