उबाऊ तकनीक चुनें (2015)

• नई तकनीकों को सीमित रखते हुए सिद्ध तकनीक (boring technology) को प्राथमिकता देना कंपनी की दीर्घकालिक सफलता के लिए अधिक लाभदायक है
• हर कंपनी के पास लगभग 3 innovation tokens ही होते हैं, और NodeJS·MongoDB·नए उभरते tools चुनने पर हर बार एक token खर्च होता है
• सिद्ध तकनीकों में capabilities और failure modes अच्छी तरह ज्ञात होते हैं, इसलिए नई तकनीकों के साथ आने वाले unknown unknowns का जोखिम कम होता है
• तकनीक का चयन पूरी टीम और संगठन को प्रभावित करता है, और operational burden तथा cognitive overhead के कारण "best tool for the job" से अधिक ऐसा tool जो कई समस्याओं पर समग्र रूप से ठीक बैठे अधिक उपयोगी होता है
• सावधानी से किया गया तकनीकी चयन इंजीनियरों को बड़ी समस्याओं पर ध्यान देने की अधिक स्वतंत्रता देता है, और केवल तकनीक के लिए तकनीक का कोई अर्थ नहीं है

---

उबाऊपन को अपनाना (Embrace Boredom)

• हर कंपनी के पास लगभग 3 innovation tokens होते हैं और उनकी आपूर्ति कुछ समय तक स्थिर रहती है — स्थिरता और परिपक्वता हासिल होने पर कुछ और मिल सकते हैं, लेकिन लोग आम तौर पर अपनी संख्या को बढ़ा-चढ़ाकर आँकते हैं
• NodeJS में वेबसाइट लिखना, MongoDB का उपयोग करना, या 1 साल से कम पुराने service discovery technology को अपनाना — इनमें से हर एक 1 innovation token खर्च करता है; अपना database खुद लिखना तो और भी बड़ी मुसीबत है
  • ऐसे चयन javascript consulting company या database company के लिए उचित हो सकते हैं, लेकिन अधिकांश कंपनियाँ global commerce को फिर से परिभाषित करने या web payments को नए सिरे से गढ़ने जैसे बड़े मिशन पर काम करती हैं — ssh जैसे क्षेत्र में innovation पर सीमित ध्यान खर्च करना असफलता या सफलता में देरी का शॉर्टकट है
• "उबाऊ (boring)" का अर्थ "खराब (bad)" नहीं है, और कुछ तकनीकें उबाऊ होने के साथ खराब भी हो सकती हैं — उबाऊ लेकिन पर्याप्त रूप से अच्छी तकनीकों के उदाहरण हैं MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• उबाऊ तकनीकों का लाभ सिर्फ उनकी capabilities में नहीं, बल्कि इस बात में भी है कि उनके failure modes भी अच्छी तरह समझे जा चुके होते हैं
• तकनीक चयन में known unknowns (जैसे: database CPU के 100% पर पहुँचने पर कैसे व्यवहार करेगा, यह अज्ञात होना) और unknown unknowns (जैसे: यह न पता होना कि stats logging GC pause पैदा करेगी) दोनों साथ मौजूद होते हैं, और नई तकनीकों में unknown unknowns का आकार कहीं बड़ा होता है

वैश्विक स्तर पर अनुकूलन करना (Optimize Globally)

• उबाऊ तकनीकों को प्राथमिकता देना एक अच्छा bias है, लेकिन यही एकमात्र विचारणीय बात नहीं है; तकनीक चयन का असर टीम, संगठन और पूरे system पर पड़ने वाला scope रखता है
• नई तकनीक जोड़ने की लागत होती है — अगर आप पहले से Ruby इस्तेमाल कर रहे हैं और फिर Python जोड़ते हैं, तो complexity का बोझ अक्सर marginal utility से अधिक हो जाता है; लेकिन Python vs Scala, MySQL vs Redis जैसी बहसों में लोग इन constraints को भूलकर "best tool for the job" का नारा लगाने लगते हैं
• काम का मूल स्वभाव business problem को software choices के solution space में map करना है, और यदि चयन पर कोई लागत न हो तो हर समस्या के लिए locally optimal tool चुना जा सकता है; लेकिन वास्तविक दुनिया में ऐसी लागत मौजूद होती है
  • यह लागत मुख्यतः operations है, और कुछ कम मात्रा में cognitive overhead — monitoring, unit tests, fixes के लिए ज़रूरी knowledge, init scripts जैसी चीज़ें बहुत जल्दी जमा हो जाती हैं
• "best tool for the job" सोच की समस्या यह है कि वह "best" और "job" दोनों को बहुत संकीर्ण रूप में देखती है — असली job कंपनी को टिकाए रखना है, और "best" tool वह है जो जितनी अधिक समस्याओं में संभव हो least worst स्थिति में रहे
• system को स्थिर बनाए रखने की long-term cost अक्सर build करते समय होने वाली असुविधा से कहीं अधिक भारी पड़ती है, और परिपक्व व उत्पादक developers इसे समझते हैं

कभी-कभी नई तकनीक चुनना (Choose New Technology, Sometimes)

• यदि ऊपर के तर्क को चरम तक ले जाएँ तो आप हर वेबसाइट Java से बनाने लगेंगे, जो अव्यावहारिक है — इसलिए toolbox में नए tools जोड़ने का कोई तरीका होना चाहिए
• नई तकनीक अंततः पूरे संगठन को प्रभावित करती है, इसलिए उसे जोड़ना company-wide visibility वाला निर्णय होना चाहिए — ऐसी सांस्कृतिक अपेक्षा बनानी चाहिए कि "यह वह मुद्दा है जिस पर हम सब मिलकर चर्चा करते हैं"
• सबसे उपयोगी अभ्यास यह है कि खुद से पूछें: नई तकनीक जोड़े बिना मौजूदा समस्या कैसे हल की जा सकती है? — इससे यह पहचानने में मदद मिलती है कि कहीं "समस्या" वास्तव में सिर्फ किसी की उस तकनीक को इस्तेमाल करने की इच्छा तो नहीं; और अगर ऐसा है, तो वहीं रुक जाना चाहिए
  • कम संख्या की तकनीकी पसंद के साथ भी बहुत दूर तक जाया जा सकता है, और वास्तविक उत्तर आम तौर पर "यह नहीं हो सकता" नहीं, बल्कि "यह हो तो सकता है, लेकिन बहुत कठिन है" होता है — यदि आपको लगे कि मौजूदा संसाधनों से लक्ष्य पाना असंभव है, तो संभव है कि आपने अभी पर्याप्त रचनात्मक ढंग से सोचा ही नहीं है
• यह स्पष्ट रूप से दर्ज करना मददगार होता है कि मौजूदा stack में उस समस्या को हल करना इतना महँगा और कठिन क्यों है
• नई तकनीक का चयन pure addition भी हो सकता है (जैसे: caching नहीं है, इसलिए memcached जोड़ा जाए), या वह किसी मौजूदा चीज़ से overlap या उसे replace भी कर सकता है — यदि वह replacement है, तो मौजूदा functionality की migration के लिए स्पष्ट अपेक्षाएँ तय करनी चाहिए; नीति अक्सर प्रस्तावित timeline के साथ "migration का वादा" करने के रूप में होती है
  • इसका उद्देश्य मलबे को प्रबंधनीय स्तर पर रखना और local optima वाले बिखरे समाधानों की भरमार को रोकना है
• यह प्रक्रिया बोझिल नहीं है: कुछ सवालों से भरा एक task और उस पर चर्चा करने के लिए एक meeting — यदि कोई नई तकनीक या नई service इस जाँच से आराम से गुजर जाए, तो उसे जोड़ना उचित है

बस ship करें (Just Ship)

• Polyglot programming को इस वादे के साथ बेचा जाता है कि यदि developers को tools चुनने की पूरी स्वतंत्रता दी जाए तो समस्या-समाधान अधिक प्रभावी हो जाएगा, लेकिन यह अधिक से अधिक भोली problem definition है, और बुरे से बुरे हाल में synchronized reasoning — रोज़मर्रा के operations का toil developers को दबा देता है
• सोच-समझकर की गई तकनीकी पसंद ही इंजीनियरों को बड़े सवालों पर विचार करने की स्वतंत्रता देती है, और केवल तकनीक के लिए तकनीक snake oil है

Etsy का उदाहरण (footnote)

• शुरुआती दिनों में Etsy ने इस समस्या से काफी कष्ट झेला — Python programmers की बड़ी संख्या में hiring करने के बाद, उनके लिए काम ढूँढ़ते-ढूँढ़ते एक अर्थहीन middle layer बना दी गई, और उसे हटाने में कई साल लग गए / इसी दौरान 90th percentile search latency लगभग 2 मिनट थी — Etsy विफल नहीं हुआ, लेकिन कई वर्षों तक कुछ ship न कर पाने के कारण उसकी सफलता में देरी हुई
• उबाऊ और खराब तकनीकों के प्रतिच्छेद को अक्सर "enterprise software" कहा जाता है, लेकिन यह हमेशा सटीक नहीं होता
• Etsy के activity feeds का उदाहरण — इसे उस समय बनाया गया जब अधिकांश चीज़ें PHP, MySQL, Memcached, Gearman के साथ एकीकृत की जा रही थीं / Redis जैसे tool की तुलना में इसे बनाना बहुत अधिक जटिल था, लेकिन उस stack के साथ भी इसे पर्याप्त रूप से बनाया जा सकता था
  • बाद के वर्षों में, जबकि ध्यान दूसरी जगह चला गया, activity feeds का उपयोग 20 गुना बढ़ गया, लेकिन shared platform की वजह से बिना किसी अलग बदलाव के भी यह सही तरह काम करता रहा — तकनीकी संयम के दीर्घकालिक लाभ का उदाहरण
  • फिर भी यह कोई पूर्णतावादी सिद्धांत नहीं है — memcached-आधारित activity feeds व्यावहारिक लगे, लेकिन faceted search सहित full-text search को शुद्ध PHP में बनाना उचित नहीं था, इसलिए Etsy ने Solr का उपयोग किया