आप Google नहीं हैं (You Are Not Google)
(blog.bradfieldcs.com)कई software engineers तकनीक चुनने में तर्कसंगत नहीं होते। नई तकनीक चुनते समय वे अक्सर वास्तविक ज़रूरत या समस्या की स्पष्ट परिभाषा के बिना, सिर्फ़ इस वजह से उसका अनुसरण करते हैं कि Google या Amazon जैसी big tech कंपनियाँ उसका उपयोग करती हैं। उदाहरण के लिए, MapReduce और Hadoop बड़े पैमाने पर data processing के लिए बनाए गए थे, लेकिन जिन कंपनियों के पास वास्तव में उतना data scale नहीं है, वे इन्हें अपनाकर उल्टा अनावश्यक I/O लागत और functionality loss झेलती हैं। यह बस एक तरह का "technology worship (cargo cult)" है.
लेख इस तरह की गैर-आलोचनात्मक नकल से बचने के लिए UNPHAT नाम का एक checklist प्रस्तुत करता है:
Understand – समस्या को पूरी तरह समझें।
eNumerate – अलग-अलग विकल्पों की सूची बनाएं।
Paper – उस तकनीक के आधारभूत paper या whitepaper पढ़ें।
Historical context – उसके विकास के ऐतिहासिक संदर्भ को देखें।
Advantages – फायदे और नुकसान की संतुलित तुलना करें।
Think – खुद सोचें कि क्या यह तकनीक वास्तव में आपकी समस्या के लिए उपयुक्त है।
लेख में Cassandra, Kafka, SOA(Service-Oriented Architecture) जैसी तकनीकों के ऐसे उदाहरण दिए गए हैं जिन्हें वास्तविक उपयोग-परिदृश्य से मेल न खाने पर भी बिना सोचे-समझे अपनाया गया। मसलन, Kafka को LinkedIn के लिए बनाया गया था जहाँ प्रति सेकंड लाखों messages process होते थे, लेकिन कभी-कभी इसे उन छोटी कंपनियों में भी इस्तेमाल किया जाता है जहाँ दिन भर में कुछ दर्जन transactions ही होते हैं।
लेखक यह भी रेखांकित करते हैं कि जब Google ने खुद यह तय किया कि MapReduce अब उपयुक्त नहीं है, तो उसने उसका उपयोग बंद कर दिया। अंततः महत्वपूर्ण चीज़ तकनीक खुद नहीं, बल्कि यह है कि आप जिस समस्या को हल करना चाहते हैं उसे ठीक-ठीक समझें और उसके अनुरूप तकनीक चुनें।
अंत में लेखक उल्लेख करते हैं कि Pólya, Hamming, Rich Hickey जैसे लोग भी यही संदेश बार-बार दोहराते आए हैं, और मूल बात बहुत सरल है:
“सोचिए। और असली समस्या को समझिए।”
15 टिप्पणियां
मैं Google की recommendations में संयोग से यह देखकर अंदर आया, लेकिन यह लेख बहुत ज़्यादा Geek नज़रिए से लिखा गया है। व्यावसायिक नज़रिए से यह बिल्कुल सही बात नहीं है। ऐसा क्यों है?
Big Tech जिन बड़े tools का इस्तेमाल करती है, उनके experts ढूँढना आसान होता है।
Big Tech में नौकरी पाने के लिए इन्हें सीखने वाले लोग भी बहुत होते हैं, और बहुत से लोग सिर्फ इसलिए भी इन्हें पढ़ते हैं क्योंकि Big Tech ने इन्हें चुना है। इसलिए स्वाभाविक रूप से इस बारे में जानने वाले लोगों को ढूँढना आसान होता है, और experienced लोगों या experts को ढूँढना भी अपेक्षाकृत सरल होता है। लेकिन अगर tool बिल्कुल नया हो, जिसे पहली बार देखा जा रहा हो, तो क्या होगा? ऐसा नहीं है कि किसी ने इसे गहराई से नहीं खंगाला होगा, लेकिन ऐसे लोगों को ढूँढना Big Tech के tools के experts की तुलना में कहीं अधिक कठिन होगा।
Big Tech द्वारा इस्तेमाल किए जाने वाले बड़े tools के लिए references और materials भरपूर होते हैं
जिन बड़े tools का बहुत से लोग इस्तेमाल करते हैं, उनके लिए समस्या हल करने की सामग्री और Google search results भरपूर मिलते हैं। ज़्यादातर समस्याएँ ऐसी होती हैं जिनका सामना पहले भी किसी और ने किया होता है, और साधारण search से ही समस्या को आसानी से समझा जा सकता है। लेकिन किसी अनजान tool में समस्या आने पर references ढूँढना मुश्किल होता है, और अगर कोई समस्या हो जाए तो उसके कारण को समझने में काफ़ी समय लगने की संभावना होती है। और यह सब आखिर पैसा ही तो है। यह समस्या क्या नए अपनाए गए छोटे tool की वजह से है? या फिर कहीं और की समस्या को गलत समझा जा रहा है?
उल्टा, Big Tech के लिए ऐसी चीज़ों को बदलना ज़्यादा आसान होता है। बहुत बड़े data processing scale की वजह से, I/O में थोड़ा-सा फ़ायदा भी उनके लिए बड़ा लाभ बन सकता है। और सिर्फ इसलिए भी बहुत से लोग इन्हें पढ़ना चाहते हैं क्योंकि Big Tech ने इन्हें अपनाया है। लेकिन छोटे और मध्यम आकार की कंपनियों में, अपेक्षाकृत छोटे data scale के कारण I/O में थोड़ा-सा लाभ इतना बड़ा लाभ नहीं बनता, जबकि ऊपर बताई गई समस्याएँ बहुत गंभीर होती हैं। और छोटे-मध्यम आकार की कंपनियों द्वारा अपनाए गए solutions को सीखना चाहने वाले लोग भी कम होते हैं। इसलिए अगर आप छोटे या मध्यम आकार के उद्यमी हैं, तो Geek की तरह इन बातों को बारीकी से तौलने के बजाय, Big Tech के tools का अनुसरण करना कई मामलों में अधिक आर्थिक निष्कर्ष साबित होता है।
मूल लेख पढ़कर पता चला कि यह 2017 में लिखा गया था.
उसके बाद 8 साल बीत चुके हैं, फिर भी यह सामग्री आज भी लागू होती है, यह हैरान करने वाली बात है.
मैं ऊपर की बातों से काफी हद तक सहमत हूँ!
लेकिन मेरा मानना है कि छोटी कंपनियों में overengineering होने का एक कारण यह भी है कि बड़ी कंपनियों को लक्ष्य बनाने वाले लोग छोटी कंपनियों में उन tools का अनुभव जमा करना चाहते हैं.
बेशक, CEO को यह खास पसंद नहीं आएगा haha
क्या यही 80% वजह नहीं है कि बड़ी कंपनियों की ज़रूरतों के हिसाब से बने tools छोटे व्यवसायों में भी वैसे ही इस्तेमाल होने लगते हैं। इसे नियंत्रित करना CTO का काम होना चाहिए, लेकिन कई बार CTO खुद ही बड़ी कंपनी में नौकरी बदलने के बारे में सोच रहा होता है।
अगर करने के लिए ज़्यादा काम न हो, तो बेकार की चीज़ें करने लगते हैं, हा हा
आसान समस्या को भी मुश्किल बनाकर हल करना पड़े, तभी लगता है कि कुछ किया है और दिखावा भी किया जा सकता है। और अगर आसानी से कर दें, तो बहुत से लोग समझते हैं कि वह आसान ही था.. हा हा हा हा
बाद में छोटे बनाए गए सिस्टम को बड़ा करके ठीक करना मुश्किल होगा, इस डर से कई बार लोग शुरुआत से ही चीज़ों को बड़े पैमाने पर बनाते हैं...
मुझे लगता है कि यह K8s पर भी लागू होने वाली बात है। "मेंटेन करना मुश्किल हो ऐसी कोडिंग कैसे करें" वाली किताब याद आ गई। हा हा
आख़िरकार, यह समझना ज़रूरी है कि तकनीकें किस समस्या को हल करने की कोशिश कर रही हैं, और वह तकनीक किस संदर्भ में सामने आई। लेख में दिए गए उदाहरण कुछ इस प्रकार हैं।
मेरा मानना है कि हमें ध्यान से देखना चाहिए कि वे जिस समस्या को हल करना चाहते हैं, क्या वह उस समस्या के साथ align करती है जिसे मैं हल करना चाहता हूँ?
ओह, इससे पूरी तरह सहमत हूं। यह पढ़कर याद आया कि जब मैं university students/juniors को mentor करता था, तो मैं अक्सर उन्हें technology के इतिहास को समझने की सलाह देता था।
ऐसा लगता है कि काफ़ी लोग कभी-कभी यह भूल जाते हैं कि तकनीक एक tool है, लक्ष्य नहीं।
क्योंकि वह Big Tech में validate हो चुकी है, क्योंकि आजकल उसका बहुत इस्तेमाल हो रहा है... जैसे ही ऐसी बातें तकनीक चुनने की मुख्य शर्त बन जाती हैं, वैसे ही अनावश्यक लागत बढ़ना स्वाभाविक रूप से साथ आता है।
कोरिया में Spring cargo cult काफ़ी मज़बूत है।
Spring के लिए लोगों को भर्ती करना आसान है...
कोरिया में spring पूजा से ज़्यादा...
यह सरकार की अक्षमता और डेवलपर्स की झंझट से बचने की प्रवृत्ति का ज़्यादा मिला-जुला नतीजा है..
इससे बहुत सहमति है। आखिरकार Spring भी समस्याएँ हल करने का एक tool ही है।
ब्रेनस्टॉर्मिंग, माइंडमैप, डीप लर्निंग, रिसर्च वर्क-अप समय कम हो गया, और लंबे समय में यह प्रभावी है