अच्छा सॉफ़्टवेयर बनने में समय लगता है

Flask को 1.0 वर्ज़न तक पहुँचने में आठ साल लगे। SQLite 2000 से सक्रिय रूप से विकसित हो रहा है और आज भी उसमें उल्लेखनीय सुधार आते हैं। Linux kernel तीन दशक से भी पुराना है और कहा जा सकता है कि वह उम्र के साथ बेहतर होता जा रहा है। इसी बीच, VC-backed स्टार्टअप से औसतन उम्मीद की जाती है कि वह 18 महीनों में traction दिखाए, वरना बताए कि क्यों नहीं।

अच्छा सॉफ़्टवेयर बनाने में असल में कितना समय लगता है और हम उससे कितनी उम्मीद रखते हैं, इन दोनों के बीच एक बढ़ती हुई खाई है। जल्दी शिप करने का दबाव अपने आप में गलत नहीं है, लेकिन इससे ऐसी संस्कृति बनती है जहाँ धैर्य को महत्वाकांक्षा की कमी समझा जाता है, और जो प्रोजेक्ट टिकते हैं, वे उन सालों में “धीमे” कहकर खारिज कर दिए जाते हैं जब वे चुपचाप सब कुछ सही कर रहे होते हैं।

“ओवरनाइट सक्सेस” का मिथक

सॉफ़्टवेयर में लगभग हर “ओवरनाइट सक्सेस” के पीछे एक लंबी कहानी होती है। React को Facebook पर ओपन-सोर्स किए जाने से पहले एक साल से ज़्यादा समय तक आंतरिक रूप से इस्तेमाल किया गया था। Rust 1.0 तक पहुँचने से पहले सात साल विकास में रहा। PostgreSQL 1986 में एक रिसर्च प्रोजेक्ट के रूप में शुरू हुआ और 2010 के दशक तक ही प्रोडक्शन के लिए पसंदीदा डेटाबेस बना। यानी लगभग 30 साल का शांत, स्थिर सुधार।

जो अचानक उभरता हुआ दिखता है, वह आम तौर पर उन छोटे-छोटे सुधारों का नतीजा होता है जो जमा होते-होते एक दृश्यता की सीमा पार कर जाते हैं। सॉफ़्टवेयर पूरे समय बेहतर हो रहा था। लोग बस तब तक ध्यान नहीं दे रहे थे जब तक वह काफ़ी अच्छा नहीं हो गया कि उसे नज़रअंदाज़ करना मुश्किल हो।

Flask के निर्माता Armin Ronacher ने इसी विषय पर सीधे लिखा है। Flask 2010 में एक अप्रैल फूल मज़ाक के तौर पर शुरू हुआ था। लगभग संयोग से वह एक गंभीर प्रोजेक्ट बन गया। सालों के छोटे-छोटे काम, जैसे edge cases ठीक करना, documentation सुधारना और APIs को फिर से सोचना, ने उसे सबसे लोकप्रिय Python web frameworks में से एक बना दिया। उन सालों में से एक भी बेकार नहीं गया। हर साल ने नींव को और मज़बूत किया।

सॉफ़्टवेयर में समय का एक अपरिहार्य हिस्सा क्यों है

कुछ समस्याएँ केवल ज़्यादा लोगों को जोड़ने या ज़्यादा मेहनत करने से तेज़ी से हल नहीं होतीं। Fred Brooks ने 1975 में The Mythical Man-Month में यह बात पहचानी थी, और इसका मूल विचार आज भी वैसा ही है: सॉफ़्टवेयर डेवलपमेंट के कुछ पहलू क्रमिक होते हैं, उन्हें समानांतर नहीं किया जा सकता।

• समस्या के डोमेन को समझना। किसी समस्या-क्षेत्र को तब तक पूरी तरह नहीं समझा जा सकता जब तक आप उसमें कुछ समय न बिताएँ। किसी भी सॉफ़्टवेयर का पहला वर्ज़न आपकी शुरुआती धारणाओं को दर्शाता है। दूसरा वर्ज़न पहले से सीखी गई बातों को समेटता है। असली समझ इटरेशन से आती है, और इटरेशन में समय लगता है।
• API डिज़ाइन और स्थिरता। अच्छे API उपयोग से निकलते हैं। आप खाली कमरे में बैठकर परफेक्ट API नहीं बना सकते, इसके लिए असली उपयोगकर्ताओं और असली edge cases की ज़रूरत पड़ती है। जो लाइब्रेरी जल्दबाज़ी में 1.0 घोषित कर देती हैं, वे अपने शुरुआती डिज़ाइन फ़ैसलों पर सालों तक पछताती हैं।
• Edge cases और मज़बूती। किसी फीचर का पहला 80% काम 20% समय में हो जाता है। बाकी edge cases, error handling और platform की बारीकियाँ बाकी 80% समय ले लेती हैं। यह अनुपात आलस्य नहीं है, यह भरोसेमंद सॉफ़्टवेयर बनाने की मूल प्रकृति है।
• समुदाय और इकोसिस्टम। कोई टूल तब तक सच में उपयोगी नहीं होता जब तक उसके पास documentation, tutorials, plugins और ऐसा समुदाय न हो जो सवालों के जवाब दे। यह इकोसिस्टम बनाया नहीं जा सकता; यह समय के साथ अपने-आप उगता है।

कृत्रिम जल्दबाज़ी का नुकसान

“Move fast and break things” एक सोशल नेटवर्क के लिए, जो product-market fit ढूँढ रहा था, एक समझदार नारा हो सकता था। लेकिन infrastructure, developer tools, databases या ऐसी किसी भी चीज़ के लिए यह बहुत बुरा दर्शन है जिस पर दूसरों के सिस्टम निर्भर हों। जब आप बुनियादी सॉफ़्टवेयर को जल्दबाज़ी में बनाते हैं, तो उसकी खराबियाँ जमा होती जाती हैं।

मैंने कई होनहार ओपन सोर्स प्रोजेक्ट्स को ढहते देखा है, क्योंकि उन्होंने अपनी नींव के सहारे से तेज़ बढ़ने की कोशिश की। पैटर्न पहले से तय होता है: प्रोजेक्ट लोकप्रिय होता है, maintainers पर जल्दी फीचर शिप करने का दबाव आता है, क्वालिटी गिरती है, contributors थक जाते हैं, और उपयोगकर्ता किसी ज़्यादा स्थिर चीज़ की ओर चले जाते हैं। विडंबना यह है कि अगर वे धीमे चलते, तो ज़्यादा दूर तक पहुँचते।

जो प्रोजेक्ट टिकते हैं, वे सबसे तेज़ शिप करने वाले नहीं होते। वे वही होते हैं जिन्होंने शुरुआत में ही अच्छे फ़ैसले ले लिए, ताकि बाद में सब कुछ दोबारा न लिखना पड़े।

Technical debt सिर्फ गंदे कोड का नाम नहीं है। यह उन फ़ैसलों का नाम है जो समय के दबाव में लिए गए और जो आगे की संभावनाओं को सीमित कर देते हैं। जल्दी शिप करने के लिए लिया गया हर शॉर्टकट भविष्य के हर बदलाव पर एक टैक्स है। कुछ शॉर्टकट लेने लायक होते हैं, लेकिन उन्हें सोच-समझकर लेना चाहिए, इसलिए नहीं कि किसी ने मनमाने ढंग से तय कर दिया कि डेडलाइन अगले मंगलवार है।

व्यवहार में धैर्य कैसा दिखता है

सॉफ़्टवेयर डेवलपमेंट में धैर्य का मतलब बेवजह धीमे चलना नहीं है। इसका मतलब है यह तय करने में सोच-समझकर रहना कि आप क्या बना रहे हैं, और यह ईमानदारी से मानना कि चीज़ों में कितना समय लगता है। कुछ पैटर्न जो मैंने अच्छे काम करते देखे हैं:

• जल्दी शिप करें, पर धीरे कमिट करें। फीडबैक पाने के लिए अपना सॉफ़्टवेयर जल्दी उपयोगकर्ताओं तक पहुँचाएँ, लेकिन स्थिर API के रूप में किसी चीज़ का वादा करने में बहुत सावधान रहें। 0.x वर्ज़निंग खुले मन से इस्तेमाल करें। साफ़ रखें कि चीज़ें बदल सकती हैं।
• फीचर्स को ना कहें। हर फीचर जो आप जोड़ते हैं, उसे आपको हमेशा के लिए संभालना पड़ता है। सबसे अच्छे प्रोजेक्ट अपने दायरे को लेकर स्पष्ट राय रखते हैं। SQLite साफ़ तौर पर बताता है कि वह कौन-से काम कभी नहीं करेगा, और यही अनुशासन उसे दुनिया का सबसे ज़्यादा deploy होने वाला डेटाबेस बनाता है।
• बुनियादी चीज़ों में निवेश करें। Documentation, testing, error messages, performance, ये सुनने में आकर्षक नहीं लगते, लेकिन इनका असर जमा होता है। अच्छी documentation और मज़बूत test suite वाला प्रोजेक्ट तीसरे साल में उतनी तेज़ी से आगे बढ़ सकता है, जितनी तेज़ी से खराब documentation वाला प्रोजेक्ट पहले साल में नहीं बढ़ पाता।
• Maintainer की ऊर्जा की रक्षा करें। Burnout ओपन सोर्स प्रोजेक्ट्स का सबसे बड़ा दुश्मन है। टिकाऊ रफ़्तार, sprint velocity से ज़्यादा मायने रखती है। जो maintainer पाँच साल तक हफ़्ते में 20 केंद्रित घंटे काम करता है, वह उस maintainer से ज़्यादा शिप करता है जो छह महीने तक हफ़्ते में 80 घंटे काम करके फिर गायब हो जाता है।

स्टार्टअप की रफ़्तार वाला जाल

स्टार्टअप्स के सामने एक वाजिब खिंचाव होता है: उन्हें बचे रहने के लिए तेज़ चलना पड़ता है, लेकिन बहुत तेज़ चलने से नाज़ुक सिस्टम बन जाते हैं जो स्केल होते ही बोझ बन जाते हैं। जो कंपनियाँ इसे अच्छे से संभालती हैं, वे दो तरह की रफ़्तार में फ़र्क करती हैं।

इटरेशन की रफ़्तार — आप कितनी जल्दी विचारों को परख सकते हैं, उपयोगकर्ताओं से फीडबैक ले सकते हैं और दिशा बदल सकते हैं। इसे अधिकतम होना चाहिए। छोटे चक्र, तेज़ प्रोटोटाइपिंग, और चीज़ों को फेंक देने की तैयारी।

कमिटमेंट की रफ़्तार — आप कितनी जल्दी आर्किटेक्चर के फ़ैसले, सार्वजनिक API और डेटा मॉडल पर ताला लगा देते हैं। इसे न्यूनतम होना चाहिए। चीज़ों को जितना हो सके उलटा जा सकने लायक रखें। जितनी देर आप अपरिवर्तनीय फ़ैसले टाल सकते हैं, उतनी ज़्यादा जानकारी आपके पास होगी जब आप आखिरकार उन्हें लेंगे।

ज़्यादातर स्टार्टअप्स की गलती यह है कि वे इन दोनों को एक मान लेते हैं। वे फीचर्स पर जितनी तेज़ी से इटरेट करते हैं, उतनी ही तेज़ी से आर्किटेक्चर पर कमिट भी कर देते हैं, और फिर अगले दो साल समय से पहले लिए फ़ैसलों का टैक्स चुकाते रहते हैं।

उन प्रोजेक्ट्स से सीख जो टिके रहे

जिन सॉफ़्टवेयर प्रोजेक्ट्स पर हम सबसे ज़्यादा निर्भर हैं, उनमें एक समानता है: किसी न किसी समय उन्हें “धीमा” माना गया था। PostgreSQL उस समय “बोरिंग” विकल्प था जब MySQL तेज़ और लापरवाह विकल्प माना जाता था। Python को “बहुत धीमा” कहा जाता था, जबकि Perl व्यावहारिक विकल्प था। Git को आम इंसानों के इस्तेमाल लायक बनने में सालों लगे।

इन प्रोजेक्ट्स के पास जो चीज़ थी, वह था समय: गलतियाँ करने का, उनसे सीखने का, और कुछ ठोस बनाने का। पहले साल में वे सबके लिए सब कुछ बनने की कोशिश नहीं कर रहे थे। वे अपने मूल उद्देश्य में उत्कृष्ट बनने की कोशिश कर रहे थे, और उन्होंने उस उत्कृष्टता को जितना समय चाहिए था, उतना लेने दिया।

अगली बार जब कोई प्रोजेक्ट “बहुत समय ले रहा है” सुनकर आपको झुंझलाहट हो, तो यह सोचें कि जिन चीज़ों पर आप सबसे ज़्यादा भरोसा करते हैं, जैसे आपका operating system, आपका डेटाबेस, आपका language runtime और आपका version control, उन सबको भी किसी की उम्मीद से ज़्यादा समय लगा। और यही वजह है कि वे काम करते हैं।

कुछ चीज़ों में बस समय लगता है। सबसे अच्छी प्रतिक्रिया इस सच्चाई से लड़ना नहीं है, बल्कि ऐसे सिस्टम, टीमें और अपेक्षाएँ बनाना है जो इसे ध्यान में रखें।