Technical Debt को समझना

Wikipedia से: “Technical debt (जिसे design debt या code debt भी कहा जाता है) “programming में एक अवधारणा है जो उस अतिरिक्त development कार्य को दर्शाती है जो तब उत्पन्न होती है जब short run में लागू करने में आसान code का उपयोग सर्वोत्तम समग्र समाधान लागू करने के बजाय किया जाता है”।

Technical debt की तुलना मौद्रिक ऋण से की जा सकती है। यदि technical debt चुकाई नहीं जाती, तो यह ‘ब्याज’ जमा कर सकती है, जिससे बाद में बदलाव लागू करना और कठिन हो जाता है। अनसुलझी technical debt software entropy को बढ़ाती है। Technical debt जरूरी नहीं कि बुरी चीज हो, और कभी-कभी (जैसे proof-of-concept के रूप में) technical debt projects को आगे बढ़ाने के लिए जरूरी होती है। दूसरी ओर, कुछ विशेषज्ञों का दावा है कि “technical debt” रूपक इसके प्रभाव को कम करके आंकता है, जिसके परिणामस्वरूप इसे सुधारने के लिए आवश्यक कार्य को पर्याप्त प्राथमिकता नहीं मिलती।”

Technical debt की अवधारणा software engineering की दुनिया से आती है, लेकिन यह IT और business infrastructure की दुनिया पर भी उतनी ही लागू होती है। Software engineering की तरह, हम अपने सिस्टम और networks को design करते हैं, और अपने designs में shortcuts लेना — जिसमें कम-से-आदर्श designs के साथ काम करना, मौजूदा hardware को शामिल करना और अन्य खराब design practices शामिल हैं — technical debt उत्पन्न करता है। इसका एक अधिक महत्वपूर्ण रूप “भविष्य” के बजाय “अतीत” में निवेश करने से आता है और अक्सर sunk cost fallacy (यानी बुरे पर अच्छा पैसा फेंकना) के कारण उत्पन्न होता है।

यह रोज़ाना businesses में होते देखना आसान है। भविष्य के लिए नई योजनाएं बनाई जाती हैं, लेकिन उन्हें लागू करने से पहले एक पुराने सिस्टम design को चालू रखने, बेहतर काम करने, विस्तार करने या किसी अन्य उद्देश्य के लिए निवेश किया जाता है। यह निवेश फिर या तो लगभग तुरंत वित्तीय नुकसान में बदल जाता है या, अधिक बार, भविष्य के designs में उतनी जल्दी, उतनी गहराई से, या संभवतः बिल्कुल भी निवेश न करने का प्रोत्साहन बन जाता है। अतीत में निवेश सबसे बुरे मामलों में पंगु बना देने वाला हो सकता है।

यह कई तरीकों से होता है और आम तौर पर अनजाने में होता है। अक्सर किसी मौजूदा सिस्टम को ठीक से चलाए रखने के लिए निवेश की जरूरत होती है और सामान्य परिस्थितियों में इसे बस किया जाएगा। लेकिन ऐसी स्थिति में जहाँ भविष्य में बदलाव की जरूरत है या संभावित रूप से योजना बनाई गई है, यह निवेश समस्याग्रस्त हो सकता है। हालांकि, बेहतर cost analysis और triage planning कई मामलों में इसका समाधान कर सकती है।

एक गैर-तकनीकी उदाहरण में, कल्पना करें कि आपके पास एक पुरानी कार है जिसने अच्छी सेवा दी है लेकिन तीन महीनों में सेवानिवृत्ति के लिए तैयार है। तीन महीनों में आप एक नई कार में निवेश करने की योजना बनाते हैं क्योंकि पुरानी कार निरंतर maintenance की जरूरतों, कम दक्षता आदि के कारण अब cost-effective नहीं है। लेकिन नई कार खरीदने की अपनी तीन महीने की योजना आने से पहले, पुरानी कार में एक छोटी खराबी आ जाती है और अब उसे चालू रखने के लिए एक महत्वपूर्ण निवेश की आवश्यकता है। पुरानी कार में पैसा लगाना technical debt में नया निवेश होगा। कुछ महीनों के लिए पुरानी कार को चलाने के लिए बड़ी राशि खर्च करने के बजाय, नई कार खरीदने की समय-सारणी को आगे बढ़ाना स्पष्ट रूप से वित्तीय दृष्टि से कहीं अधिक उचित है। कारों के साथ, हम यह आसानी से देखते हैं (अधिकांश मामलों में।) हम पैसे बचाते हैं, संभावित रूप से काफी, जल्दी से नई कार खरीदकर। यदि हम पुरानी में भारी निवेश करते हैं, तो हम या तो कुछ महीनों में वह निवेश खो देते हैं या हम नई कार की खरीद के लिए पहले से बनाई गई अपनी ठोस वित्तीय योजना को बदलने का जोखिम उठाते हैं। दोनों मामले वित्तीय दृष्टि से बुरे हैं।

IT भी इसी तरह काम करती है। एक planned hosted email system में migration से छह महीने पहले एक पुराने email system को बनाए रखने पर बड़ी राशि खर्च करना बहुत मूर्खतापूर्ण होगा। निवेश या तो पुराने सिस्टम को decommission करने पर लगभग तुरंत खो जाता है या यह हमारी अच्छी planning प्रक्रियाओं को कमजोर करता है और हमें योजनानुसार migrate न करने तथा हमारे businesses के लिए घटिया काम करने की ओर ले जाता है, क्योंकि हमने technical debt को उचित planning के बजाय हमारे निर्णय को चलाने दिया।

अक्सर एक खराब triage operation या triage players को अनुचित authority ही वह कारक हो सकती है जो भविष्य की ओर देखने वाले त्वरित निवेशों के बजाय आपातकालीन technical debt निवेशों का कारण बनती है। यह केवल एक क्षेत्र है जहाँ बड़े सुधार से समस्याओं का समाधान हो सकता है, लेकिन यह एक प्रमुख क्षेत्र है। इसे कुछ मामलों में “what if” planning के माध्यम से भी कम किया जा सकता है — सामान्य या अपेक्षित आपात स्थितियों पर निर्भर निवेश योजनाएं तैयार रखना जो उत्पन्न हो सकती हैं, जो उतनी सरल हो सकती है जितनी system planning शुरू होने से पहले विकास के कारण capacity expansion की जरूरत।

Common technical debt का एक और अच्छा उदाहरण server storage capacity expansion है। यह एक ऐसा परिदृश्य है जो मैं कुछ आवृत्ति के साथ देखता हूं और technical debt को अच्छी तरह से प्रदर्शित करता है। किसी company के लिए ऐसे servers खरीदना सामान्य है जिनमें बड़ी internal storage capacity की कमी हो। या तो तुरंत या कुछ समय बाद अधिक capacity की जरूरत पड़ती है। यदि यह तुरंत होता है तो हम देख सकते हैं कि खरीदा गया server अनुचित design में technical debt का एक रूप था और स्पष्ट रूप से planning और purchasing प्रक्रिया में एक दोष को दर्शाता है।

लेकिन एक अधिक सामान्य उदाहरण server खरीदे जाने के दो या तीन साल बाद storage expand करने की जरूरत है। सामान्य expansion choices में server से attach करने के लिए external storage array जोड़ना या अधिक local storage स्वीकार करने के लिए server को modify करना शामिल है। इन दोनों दृष्टिकोणों में पहले से पुराने server में बड़ा निवेश होता है — एक server जो आसानी से अपने उपयोगी lifespan का चालीस प्रतिशत या उससे अधिक पार कर चुका है। कई मामलों में पूरी तरह नए server में समान या थोड़ा अधिक निवेश के परिणामस्वरूप नया hardware, तेज़ CPUs, अधिक RAM, जरूरी storage, उद्देश्य-designed और निर्मित, aligned और refreshed support lifespan, छोटा datacenter footprint, कम बिजली खपत, नई technologies और features, बेहतर vendor relationships और बहुत कुछ मिल सकता है — साथ ही मूल server को reuse, retire या resell करने के लिए बनाए रखा जा सकता है। एक तरीका अतीत को support करने में पैसा खर्च करता है, दूसरा अक्सर तुलनीय राशि भविष्य पर खर्च कर सकता है।

Technical debt कई businesses के लिए एक पंगु बना देने वाला कारक है। यह IT की लागत बढ़ाती है, कभी-कभी महत्वपूर्ण रूप से, और planning की कमी तथा अधिकांश खर्च आपातकालीन आधार पर होने के माध्यम से उच्च स्तर के जोखिम को जन्म दे सकती है।