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