तकनीकी ऋण

सॉफ़्टवेयर विकास में तकनीकी ऋण (डिज़ाइन ऋण या कोड ऋण के रूप में भी जाना जाता है एक बेहतर दृष्टिकोण के अतिरिक्त एक आसान लेकिन सीमित समाधान का चयन करते समय आवश्यक भावी पुनर्विक्रय की निहित लागत है जिसमें अधिक समय लग सकता है।

मौद्रिक ऋण के अनुरूप यदि तकनीकी ऋण का भुगतान नहीं किया जाता है, तो यह "ब्याज" जमा कर सकता है, जिससे परिवर्तनों को लागू करना कठिन हो जाता है। अनएड्रेस्ड टेक्निकल डेट सॉफ्टवेयर एन्ट्रापी और आगे के रीवर्क की लागत को बढ़ाता है। इसी तरह मौद्रिक ऋण के लिए, तकनीकी ऋण एक बुरी चीज नहीं है, और कभी-कभी (उदाहरण के लिए अवधारणा के प्रमाण के रूप में) परियोजनाओं को आगे बढ़ाने की आवश्यकता होती है। दूसरी ओर, कुछ विशेषज्ञों का दावा है कि "तकनीकी ऋण" रूपक प्रभाव को कम करता है, जिसके परिणामस्वरूप इसे ठीक करने के लिए आवश्यक कार्य की अपर्याप्त प्राथमिकता होती है।

जैसे ही एक कोडबेस पर बदलाव शुरू किया जाता है, कोडबेस या दस्तावेज़ीकरण के अन्य भागों में प्रायः अन्य समन्वित परिवर्तन करने की आवश्यकता होती है। आवश्यक परिवर्तन जो पूरे नहीं हुए हैं, उन्हें ऋण माना जाता है, और जब तक भुगतान नहीं किया जाता है, तब तक ब्याज के ऊपर ब्याज लगेगा, जिससे परियोजना का निर्माण बोझिल हो जाएगा। हालाँकि यह शब्द मुख्य रूप से सॉफ्टवेयर विकास में उपयोग किया जाता है, इसे अन्य व्यवसायों पर भी लागू किया जा सकता है।

2016 में आयोजित एक डगस्टुहल संगोष्ठी में, तकनीकी ऋण को विषय के अकादमिक और औद्योगिक विशेषज्ञों द्वारा निम्नानुसार परिभाषित किया गया था: "सॉफ्टवेयर-गहन प्रणालियों में, तकनीकी ऋण डिजाइन या कार्यान्वयन निर्माणों का एक संग्रह है जो अल्पावधि में समीचीन है, लेकिन निर्धारित है एक तकनीकी संदर्भ जो भविष्य के परिवर्तनों को अधिक महंगा या असंभव बना सकता है। तकनीकी ऋण एक वास्तविक या आकस्मिक दायित्व प्रस्तुत करता है जिसका प्रभाव आंतरिक प्रणाली गुणों, मुख्य रूप से संरक्षण और अस्थिरता तक सीमित है।

कारण
तकनीकी ऋण के सामान्य कारणों में सम्मिलित हैं:
 * चल रहे विकास, समय के साथ परियोजना संवर्द्धन की लंबी श्रृंखला पुराने समाधानों को उप-इष्टतम बना देती है।
 * अपर्याप्त अप-फ्रंट परिभाषा, जहां विकास के दौरान आवश्यकताओं को अभी भी परिभाषित किया जा रहा है, किसी भी डिजाइन के होने से पहले विकास शुरू हो जाता है। यह समय बचाने के लिए किया जाता है लेकिन प्रायः बाद में इसे फिर से काम करना पड़ता है।
 * व्यावसायिक दबाव, जहां आवश्यक परिवर्तन पूर्ण होने से पहले व्यवसाय जल्द ही कुछ जारी करने पर विचार करता है, उन अधूरे परिवर्तनों को सम्मिलित करते हुए तकनीकी ऋण का निर्माण करता है।
 * प्रक्रिया या समझ का अभाव, जहां व्यवसाय तकनीकी ऋण की अवधारणा के प्रति अंधे होते हैं, और निहितार्थों पर विचार किए बिना निर्णय लेते हैं।
 * युग्मन (कंप्यूटर प्रोग्रामिंग), जहां कार्य मॉड्यूलर प्रोग्रामिंग नहीं हैं, सॉफ्टवेयर इतना लचीला नहीं है कि वह व्यावसायिक जरूरतों में बदलाव के अनुकूल हो सके।
 * एक परीक्षण सूट का अभाव, जो त्वरित और जोखिम भरा बैंड-ऐड (कम्प्यूटिंग) | बैंड-ऐड बग फिक्स को प्रोत्साहित करता है।
 * सॉफ़्टवेयर दस्तावेज़ों का अभाव, जहाँ दस्तावेज़ों का समर्थन किए बिना कोड बनाया जाता है। दस्तावेज़ बनाने का कार्य ऋण का प्रतिनिधित्व करता है।
 * सहयोग का अभाव, जहां ज्ञान को संगठन के आसपास साझा नहीं किया जाता है और व्यावसायिक दक्षता प्रभावित होती है, या जूनियर डेवलपर्स को ठीक से सलाह नहीं दी जाती है।
 * एक स्रोत आधार में परिवर्तनों को मर्ज करने के लिए आवश्यक कार्य के कारण कई शाखाओं पर समानांतर विकास तकनीकी ऋण अर्जित करता है। अलगाव में जितने अधिक परिवर्तन किए जाते हैं, उतना अधिक ऋण।
 * आस्थगित कोड रीफैक्टरिंग; जैसे-जैसे किसी परियोजना के लिए आवश्यकताएँ विकसित होती हैं, यह स्पष्ट हो सकता है कि कोड के भाग अक्षम या संपादित करने में कठिन हो गए हैं और भविष्य की आवश्यकताओं का समर्थन करने के लिए उन्हें फिर से तैयार किया जाना चाहिए। जितनी लंबी रिफैक्टरिंग में देरी होगी, और जितना अधिक कोड जोड़ा जाएगा, उतना ही बड़ा कर्ज होगा।
 * मानकों के संरेखण की कमी, जहां उद्योग मानक सुविधाओं, सॉफ्टवेयर ढांचे और प्रौद्योगिकियों की अनदेखी की जाती है। आखिरकार मानकों के साथ एकीकरण आ जाएगा और ऐसा करने में जल्द ही कम खर्च आएगा (विलंबित रीफैक्टरिंग के समान)।
 * ज्ञान की कमी, जब डेवलपर को यह नहीं पता होता है कि सुरुचिपूर्ण कोड कैसे लिखना है।
 * स्वामित्व की कमी, जब आउटसोर्स किए गए सॉफ़्टवेयर प्रयासों के परिणामस्वरूप इन-हाउस इंजीनियरिंग को कोड रिफैक्टरिंग या कोड पुनर्लेखन आउटसोर्स कोड की आवश्यकता होती है।
 * खराब तकनीकी नेतृत्व, जहां खराब तरीके से सोची गई कमानों को कमान की शृंखला सौंपी जाती है।
 * अंतिम मिनट विनिर्देश परिवर्तन। इनमें एक परियोजना के दौरान रिसने की क्षमता है, लेकिन परिवर्तनों का दस्तावेजीकरण और परीक्षण करने के लिए अपर्याप्त समय या बजट है।

सेवा या तकनीकी ऋण चुकाना
केनी रुबिन निम्नलिखित स्थिति श्रेणियों का उपयोग करता है:
 * हुआ-तकनीकी ऋण-ऋण कि विकास दल अनजान था जब तक कि उत्पाद पर काम करने के सामान्य पाठ्यक्रम के दौरान इसका खुलासा नहीं हुआ। उदाहरण के लिए, टीम उत्पाद में एक नई सुविधा जोड़ रही है और ऐसा करने पर यह महसूस होता है कि किसी ऐसे व्यक्ति द्वारा कोड वर्षों पहले वर्क-अराउंड बनाया गया था जो लंबे समय से विदा हो चुका है।
 * ज्ञात तकनीकी ऋण—ऋण जो विकास दल को ज्ञात है और कई दृष्टिकोणों में से एक का उपयोग करके दृश्यमान बनाया गया है।
 * लक्षित तकनीकी ऋण—ऋण जो ज्ञात है और विकास दल द्वारा सर्विसिंग के लिए लक्षित किया गया है।

परिणाम
"ब्याज भुगतान" आवश्यक स्थानीय संरक्षण और परियोजना के अन्य उपयोगकर्ताओं द्वारा संरक्षण की अनुपस्थिति दोनों के कारण होता है। अपस्ट्रीम परियोजना में चल रहे विकास से भविष्य में "ऋण चुकाने" की लागत बढ़ सकती है। केवल अपूर्ण कार्य को पूरा करके ऋण का भुगतान किया जा सकता है।

तकनीकी ऋण का निर्माण परियोजनाओं की समय सीमा से चूकने का एक प्रमुख कारण है। यह अनुमान लगाना मुश्किल है कि ऋण का भुगतान करने के लिए कितना काम आवश्यक है। प्रत्येक परिवर्तन के लिए जो शुरू किया गया है, परियोजना के लिए अपूर्ण कार्य की अनिश्चित राशि प्रतिबद्ध है। समय सीमा समाप्त हो जाती है जब परियोजना को पता चलता है कि इसे पूरा करने के लिए समय की तुलना में अधिक अपूर्ण कार्य (ऋण) है। पूर्वानुमेय रिलीज शेड्यूल के लिए एक विकास टीम को अपूर्ण की मात्रा को बनाए रखने के लिए कार्य की मात्रा को सीमित करना चाहिए। काम (या कर्ज) हर समय छोटा।

यदि एक परियोजना पर पर्याप्त काम पूरा हो जाता है जो प्रस्तुत करने में बाधा उत्पन्न नहीं करता है, तो एक परियोजना जारी की जाएगी जो अभी भी पर्याप्त मात्रा में तकनीकी ऋण वहन करती है। यदि यह सॉफ्टवेयर उत्पादन तक पहुंचता है, तो तकनीकी ऋण को संबोधित करने वाले किसी भी भविष्य के रिफ्लेक्टर को लागू करने का जोखिम नाटकीय रूप से बढ़ जाता है। यदि अनुबंधों में सेवा-स्तरीय समझौते (SLA) सम्मिलित हैं, तो उत्पादन कोड को संशोधित करने से आउटेज, वास्तविक वित्तीय नुकसान और संभवतः कानूनी नतीजों का जोखिम होता है। इस कारण से हम तकनीकी ऋण को उत्पादन तक ले जाने को लगभग इस तरह देख सकते हैं जैसे कि यह ब्याज दर में वृद्धि थी और केवल एक बार यह घटता है जब तैनाती को ठुकरा दिया जाता है और सेवानिवृत्त कर दिया जाता है।

जबकि मीर मैनी लेहमन के कानून ने पहले ही संकेत दिया था कि विकसित कार्यक्रम लगातार उनकी जटिलता और बिगड़ती संरचना को जोड़ते हैं जब तक कि उन्हें बनाए रखने के लिए काम नहीं किया जाता है, वार्ड कनिंघम ने पहली बार 1992 की अनुभव रिपोर्ट में तकनीकी जटिलता और ऋण के बीच तुलना की:

अपने 2004 के पाठ में, रिफैक्टरिंग टू पैटर्न्स, जोशुआ केरिवेस्की वास्तु लापरवाही से जुड़ी लागतों के संबंध में एक तुलनीय तर्क प्रस्तुत करता है, जिसे वह "डिजाइन ऋण" के रूप में वर्णित करता है।

जिन गतिविधियों को स्थगित किया जा सकता है उनमें दस्तावेज़ीकरण, परीक्षण स्वचालन, टीओडीओ टिप्पणियों पर ध्यान देना और संकलक और स्थैतिक कोड विश्लेषण चेतावनियों से निपटना सम्मिलित है। तकनीकी ऋण के अन्य उदाहरणों में ज्ञान सम्मिलित है जो संगठन के आसपास साझा नहीं किया जाता है और कोड जो आसानी से संशोधित करने के लिए बहुत भ्रामक है।

2014 में PHP के विकास के बारे में लिखते हुए, जुनादे अली ने कहा:

ग्रेडी बूच ने तुलना की है कि कैसे विकसित होते शहर सॉफ्टवेयर-गहन प्रणालियों के विकास के समान हैं और रिफैक्टरिंग की कमी कैसे तकनीकी ऋण का कारण बन सकती है।

ओपन सोर्स सॉफ़्टवेयर में, अपस्ट्रीम प्रोजेक्ट में स्थानीय परिवर्तन भेजना स्थगित करना तकनीकी ऋण का एक रूप है।

यह भी देखें

 * कोड गंध (अवर कोड गुणवत्ता के लक्षण जो तकनीकी ऋण में योगदान दे सकते हैं।)
 * मिट्टी का बड़ा गोला
 * बस कारक
 * प्रतिबद्धता की वृद्धि
 * मनुवाद
 * अति अभियांत्रिकी
 * शॉटगन सर्जरी
 * सॉफ्टवेयर एन्ट्रापी
 * सॉफ्टवेयर अपक्षय
 * स्पेगेटी कोड
 * स्केल
 * विफल लागत
 * टीओडीओ, फिक्समे, एक्सएक्सएक्स (प्रोग्रामिंग भाषा)

बाहरी संबंध

 * Ward Explains Debt Metaphor, video from Ward Cunningham
 * OnTechnicalDebt The online community for discussing technical debt
 * Experts interviews on Technical Debt: Ward Cunningham, Philippe KRUCHTEN, Ipek OZKAYA, Jean-Louis LETOUZEY
 * Steve McConnell discusses technical debt
 * TechnicalDebt from Martin Fowler Bliki
 * Averting a "Technical Debt" Crisis by Doug Knesek
 * "Get out of Technical Debt Now!", a talk by Andy Lester
 * Lehman's Law
 * Managing Technical Debt Webinar by Steve McConnell
 * Boundy, David, Software cancer: the seven early warning signs or here, ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, New York, US
 * Technical debt: investeer en voorkom faillissement by Colin Spoel
 * Technical debts: Everything you need to know
 * What is technical debt? from DeepSource blog