- इस आम धारणा के विपरीत कि बाज़ार अपने-आप अक्षमताओं को हटा देता है, consumer goods, B2B software, logistics और organizational decision-making में स्पष्ट अक्षमता लंबे समय तक बनी रह सकती है
- उपभोक्ताओं के लिए किसी प्रोडक्ट या सेवा की वास्तविक गुणवत्ता का आकलन करना कठिन होता है, और expert, brand, या price भी हमेशा भरोसेमंद संकेत नहीं होते, इसलिए marketing और PR अक्सर चुनाव तय कर देते हैं
- enterprise खरीद में भी, “buy vs build” की अपेक्षा के विपरीत, leading vendor के प्रोडक्ट design के कारण काम ही नहीं करते या support contract धीमे और महंगे होते हैं, इसलिए इन-हाउस बनाना अधिक तर्कसंगत हो सकता है
- अगर बाहरी सेवाओं पर भरोसा करना मुश्किल हो, तो delivery, semiconductor processing, EDA tools, infrastructure software जैसे non-core क्षेत्रों को भी खुद संभालना पड़ सकता है, जिससे छोटी कंपनियों पर productivity का बोझ बढ़ता है
- information asymmetry, कम trust, और cultural inertia की वजह से प्रोडक्ट को सच में बेहतर बनाने का दबाव कमज़ोर रहता है; Kyle Kingsbury की Jepsen या Volvo जैसे दुर्लभ उदाहरण न हों तो correctness और safety से आगे marketing निकल सकती है
बाज़ार अपने-आप अच्छे प्रोडक्ट क्यों नहीं चुनता
- “बाज़ार efficiency लागू करता है, इसलिए बड़ी अक्षमता वाली कंपनी टिक नहीं सकती” जैसी efficient market hypothesis की व्याख्या कई वास्तविक उदाहरणों से टकराती है
- tech hiring market की अक्षमता दशकों तक बनी रही, और भले कुछ कंपनियाँ गलत कीमत पर उपलब्ध labor का लाभ उठा लें, वे पूरी pricing बदल देने लायक पर्याप्त demand नहीं बना पातीं
- capital markets में गलत कीमत वाली assets खरीदकर या derivatives के जरिए मुनाफ़ा कमाया जा सकता है, लेकिन consumer goods या service quality की गड़बड़ियों को सीधे पैसे में बदलना आमतौर पर आसान नहीं होता
- product और service markets में अक्सर ऐसा स्पष्ट mechanism ही नहीं होता, जिसमें अक्षमता पहचानने वाला व्यक्ति उसे हटाकर तुरंत उससे कमाई कर सके
व्यक्तिगत उपभोक्ता के लिए गुणवत्ता समझना कठिन है
- घर की मरम्मत या accounting जैसी सेवाएँ लेने के बाद जिन लोगों ने परिणाम को खुद जांचा, उन्होंने अक्सर गंभीर गलतियाँ पाई हैं
- non-expert के लिए पहले से यह समझना मुश्किल होता है कि कौन खराब काम करेगा, और महंगी कंपनी चुनना भी गुणवत्ता की गारंटी नहीं देता
- ऐसे उदाहरण हैं जहाँ बड़ी branded accounting firm को ज़्यादा पैसा देने के बावजूद error rate, छोटे local accountant से भी अधिक था
- अच्छे accountant आम तौर पर कुछ हद तक महंगे होते हैं, लेकिन सबसे ज़्यादा fees लेने वाले ही अच्छे हों, ऐसा सामान्य नहीं है; और महंगे accountants में भी अच्छे लोग कम होते हैं
- जब उपभोक्ता के पास पर्याप्त जानकारी नहीं होती, तो वह अच्छा प्रोडक्ट तो दूर, “चलने लायक ठीक-ठाक प्रोडक्ट” भी अलग नहीं कर पाता
- iPhone से Android की ओर हुए दो बड़े रुझान Apple की PR गलतियों के कारण पैदा हुए, और इन्हें ऐसे उदाहरण के रूप में पेश किया गया जहाँ लोगों ने सोचा कि iPhone किसी पहलू में खराब है, जबकि वास्तव में वह Android से बेहतर था
- कुछ users को अंततः अपने लिए अधिक उपयुक्त Android device मिला, लेकिन यह पहले Apple PR की वजह से iPhone इस्तेमाल करने की गलती के संतुलित हो जाने जैसा था
- अगर प्रोडक्ट का चुनाव मुख्यतः marketing और PR से तय हो और अच्छी जानकारी कम हो, तो यह मानना कठिन है कि बेहतर या सख्ती से श्रेष्ठ प्रोडक्ट ज़रूर जीतेगा
expert और brand भी हमेशा जवाब नहीं होते
- गुणवत्ता का आकलन कठिन होने के कारण अक्सर expert या qualified व्यक्ति से पूछने की सलाह दी जाती है, लेकिन यह तरीका भी विफल हो सकता है
- एक व्यक्ति जो window AC के शोर की वजह से सो नहीं पाता था, उसने AC के जानकार दोस्त से पूछा कि क्या नए मॉडल से सुधार होगा; जवाब मिला, “AC तो मूलतः सब एक जैसे ही होते हैं”
- लेकिन motor वाले consumer products की तुलना करने पर दिखता है कि समान power और cost की शर्तों में भी engineers अब पहले से अधिक quiet device बना सकते हैं
- नया और कम शोर वाला AC खरीदने के बाद उसकी नींद की समस्या दूर हो गई, लेकिन सलाह देने वाला उस क्षेत्र में काम करता है, इस भरोसे के कारण वह समस्या ज़्यादा समय तक झेलता रहा
- अगर सलाह को परखने जितनी expertise पहले से होती, तो सलाह की ज़रूरत ही नहीं पड़ती; इसलिए experts पर निर्भरता information asymmetry की समस्या को पूरी तरह हल नहीं करती
enterprise खरीद बाज़ार और भी छोटा व अपारदर्शी है
- enterprise market में personal consumer market की तुलना में प्रोडक्ट कम होते हैं, और pricing अक्सर “contact us” जैसी opaque होती है, इसलिए समस्या और गंभीर हो सकती है
- “core competency पर ध्यान दो और बाकी outsource करो” जैसी सलाह के विपरीत, mid-sized tech company को भी kernel जैसे क्षेत्रों में इन-हाउस expertise की ज़रूरत पड़ सकती है
- kernel expertise को consultant या support contract के ज़रिए outsource करने के मामलों में, dedicated engineer रखने की तुलना में परिणाम खराब रहे
- जिस समस्या को अच्छा engineer कुछ दिनों में ठीक कर सकता है, वही support contract के तहत हफ्तों या महीनों तक संतोषजनक रूप से हल नहीं होती
- बड़े support contract engineer से अधिक महंगे होते हुए भी service में बदतर हो सकते हैं
- Wave के CTO Ben Kuhn को बाद में लगा कि vendor selection में कहीं अधिक मेहनत न लगाना और कई systems को पहले ही in-house implementation में न ले जाना उनकी बड़ी गलतियों में से था
- industry leader की flagship product और “सर्वसम्मत best choice” चुन लेने पर भी, वह प्रोडक्ट वास्तव में काम न करे या design के हिसाब से काम कर ही न सके, ऐसा हो सकता है
Postgres-Snowflake sync product का मामला
- Postgres से Snowflake में data sync करने वाली एक leading data sync company का मुख्य प्रोडक्ट इस्तेमाल किया गया, लेकिन उसमें data loss, duplication और corruption हुआ
- यह प्रोडक्ट इस धारणा पर design किया गया था कि data source change log में पीछे जा सकता है, जबकि Postgres change log consume होने के बाद उसे हटा देता है, इसलिए यह संभव ही नहीं था
- यह प्रक्रिया विफल होने पर sync “रुक जाती” थी, और फिर vendor operator की manual intervention या data loss की ज़रूरत पड़ती थी
- क्योंकि original data Postgres में रहता था, full resync से recovery संभव थी, लेकिन product की resync speed केवल 5MB/s थी, इसलिए बहुत बड़ा न होने वाला database भी कई दिनों में sync होता
- resync भी चुपचाप data miss या corrupt कर सकता था, इसलिए full resync और data integrity checks कई बार दोहराने पड़ते, और recovery में कई हफ्ते लग सकते थे
- बहुत सिफारिश किया गया और market-leading प्रोडक्ट भी बड़े design flaw की वजह से व्यवहार में काम न करने लायक हो सकता है
Jepsen, Mongo, और correctness का दबाव
- Mongo सहित कुछ प्रोडक्ट ऐसे उदाहरण रहे हैं जिनमें गंभीर data loss कराने वाले मूलभूत design flaws थे
- कई क्षेत्रों में Kyle Kingsbury जैसा व्यक्ति नहीं होता, जो सालों तक प्रोडक्ट testing सार्वजनिक करे, correctness पर गलत प्रतिवादों का जवाब दे, और PR backlash के बावजूद कंपनियों को correctness गंभीरता से लेने पर मजबूर करे
- ऐसे दबाव के बिना बहुत से software products ठीक से काम नहीं करते
- प्रोडक्ट को वास्तव में काम करने लायक बनाने की incentive कमज़ोर हो सकती है
- “fog of war” और गलत काम करने के दावों के बावजूद भी, वास्तविक working product बेचने जैसा sales effect मिल सकता है
- और Kyle Kingsbury जैसे लोगों के सामने आने से पहले इसकी लागत और भी कम होती है
- vendor अच्छा प्रोडक्ट बनाना भी चाहे, तब भी consumer feedback सीमित होता है: कभी-कभार और biased direct contact, revenue trends, और sales channels के noise से वास्तविक समस्याएँ समझना मुश्किल होता है
जब “Build” तर्कसंगत होता है
- Wave के पैमाने पर CPU जैसी चीज़ें खुद बनाना संभव नहीं, लेकिन जिन कई क्षेत्रों को परंपरागत रूप से “खरीदना चाहिए” माना जाता है, उनमें खुद बनाना तर्कसंगत हो सकता है
- 15 साल पहले तक high-performance CPU ऐसा प्रमुख उदाहरण था जिसे बड़ी software companies भी खुद बनाना मुश्किल समझती थीं, लेकिन Apple और Amazon अपने optimization के स्तर पर world-class CPU बना सके
- हालांकि इसका मतलब यह नहीं कि Apple या Amazon की CPU teams स्वतंत्र कंपनी के रूप में भी उतनी सफल होतीं
- Apple ने PA Semi की core team को अपेक्षाकृत सस्ते में हासिल किया, जो पहले DEC और SiByte से गुज़री थी; PA Semi स्वतंत्र business के रूप में लगभग असफल रही
- Amazon की शुरुआती silicon talent भी Annapurna और Smooth Stone जैसी कंपनियों से आई, जिनके लिए स्वतंत्र रूप से टिके रहना कठिन था
- network effects, high fixed costs, upfront capital expenditure, और incumbents का market dominance ऐसे कारक हैं जो स्पष्ट अवसर होने पर भी independent startup को उसे पकड़ने से रोक सकते हैं
logistics में भी भरोसेमंद बाहरी सेवा की कमी
- जिन कंपनियों को ग्राहकों तक सामान भेजना होता है, उन्हें या तो delivery खुद संभालनी पड़ती है या अविश्वसनीय shipping के नतीजे स्वीकार करने पड़ते हैं
- single-family home में parcel देर से सही, आम तौर पर पहुँच जाता था; लेकिन apartment building में कुछ delivery services कोशिश ही नहीं करती थीं
- ऐसे मामले थे जहाँ UPS और FedEx ने actual delivery attempt किए बिना building door पर missed-delivery notice चिपका दिया, और notice में गलत लिखा कि घर पर कोई नहीं था, इसलिए pickup location पर जाना होगा
- जब Amazon ने एक समय same-day delivery की last mile third-party commercial delivery services को दी, तब कई दिनों तक बिना डिलीवर हुए packages को “delivered” दिखाने की समस्या थी
- Amazon support script कहती थी कि delivered status आने के 3 दिन बाद फिर संपर्क करें
- Amazon को पता था कि carrier वास्तव में तुरंत डिलीवर नहीं करता, और short-term mitigation यह था कि ग्राहक “delivered” status पर तुरंत भरोसा न करें
- Amazon ने अंततः अपनी delivery workforce बनाकर या बहुत महंगी commercial services लेकर यह समस्या हल की
- अगर commercial services बड़े पैमाने पर विश्वसनीय delivery attempt ही नहीं करतीं, तो वास्तव में काम करने वाली service के लिए खुद बनाना पड़ता है
- एक local grocery store ने DoorDash को delivery outsource की, लेकिन 3 में से केवल 2 बार ही groceries पहुँचीं; यह दिखाता है कि छोटी कंपनियों के लिए reliable delivery खरीदना कठिन है
semiconductor startup में in-house processing और tools
- एक छोटे chip startup का उदाहरण है जिसने fab को छोड़कर end-to-end chip processing capability in-house रखी
- जब नए design का पहला wafer निकलता, तो उसे हवाई जहाज़ से कंपनी तक भेजा जाता, और in-house wafer saw से individual chips काटकर जितनी जल्दी हो सके testing शुरू की जाती
- wafer saw और उससे जुड़ी expertise 99% से ज़्यादा समय idle रहती, इसलिए वह outsourcing के लिए उपयुक्त लग सकती थी, लेकिन कम volume पर भी in-house processing की लागत कम और turnaround तेज़ था
- जिन कंपनियों ने इसी तरह का काम outsource किया, उन्हें धीमी और कम reliable service ज़्यादा कीमत पर मिली
- chip software tools भी आम तौर पर बड़े EDA vendors पर छोड़े जाते थे, लेकिन custom tools का बड़ा असर था
- एक व्यक्ति द्वारा maintain किया गया custom simulator अधिकांश simulator cycles संभालता था
- उस समय standard simulators की कीमत प्रति license सालाना हज़ारों डॉलर थी, और लगभग 1,000 simulation machines का farm चलने के कारण सालाना कई million dollar की बचत होती थी
- भले ही एक व्यक्ति कंपनी के लिए सालाना कई million dollar मूल्य का tool बना या maintain कर सकता था, competitors अपने-आप वही चुनाव नहीं करते थे
core competency का नारा और organizational culture
- Joel Spolsky का “dependencies खोजो और हटाओ” वाला वाक्य external code और external organizations पर गहरे अविश्वास को दिखाता है
- एक कंपनी ने “core competency पर focus” करने के leadership decision के तहत infrastructure के custom software को छोड़कर SaaS और open source software पर बड़े migration किए
- भले leadership ने individual teams पर इसे force नहीं किया या negative consequences नहीं लगाए, फिर भी कई लोगों ने इस नारे को अपना लिया और specific context से अलग होकर migration को justify किया
- कुछ मामलों में नया system साफ़ तौर पर कम efficient था, फिर भी “cost savings” के नाम पर open source की ओर migration हुआ
- plan यह था कि team size घटाकर लागत कम होगी, लेकिन operational cost में बढ़ोतरी team cost change से अधिक निकली
- operational complexity की वजह से team size घटने के बजाय बढ़ गया
- कुछ migrations वास्तव में उचित थे, लेकिन उनके लिए दिए गए कारण असली valid reasons से असंबंधित थे या उनसे बहुत कम जुड़े थे
- तकनीकी विचार के बिना जितने अधिक tech decisions लिए जाते हैं, उतना ही कंपनियों पर अच्छे products बनाने का selection pressure कमज़ोर होता है
अच्छे प्रोडक्ट बनाने वाले दुर्लभ व्यक्ति और कंपनियाँ
- ऐसे व्यक्ति जो “अतार्किक हद तक जिद्दी” लगें, वे कंपनी के अंदर और बाहर बड़ा असर डाल सकते हैं
- Kyle Kingsbury ने Jepsen के जरिए कई products की correctness verify की, और लंबे समय तक market rate से कम compensation तथा uncertainty सहते हुए आलोचनाओं का जवाब दिया
- अगर successful companies को correctness marketing के बजाय वास्तविक correctness पर मेहनत करने के लिए ऐसे लोगों की ज़रूरत पड़ती है, तो बहुत से products वास्तविक correctness से अधिक correctness marketing में मज़बूत बने रहेंगे
- corporate स्तर पर भी वास्तव में महान product बनाने के लिए कभी-कभी दुर्लभ “अतार्किक” कंपनी की ज़रूरत हो सकती है
- Volvo को ऐसे automaker के रूप में लिया गया है जो IIHS tests से सिद्ध न्यूनतम स्तर से आगे बढ़कर structural safety बनाना चाहता था
- जबकि car crashes मौत और life expectancy loss का बड़ा कारण थीं, safety ऐसा factor नहीं था जिस पर consumers बहुत मज़बूती से ध्यान देते हों
- Volvo व्यवसायिक कठिनाइयों के कारण luxury niche car company की ओर खिसक गया और स्वतंत्र कंपनी के रूप में टिक नहीं सका
- Ford द्वारा अधिग्रहण के बाद कुछ Volvo models Ford C1 platform पर चले गए, और वह platform crash tests में विशेष रूप से अच्छा नहीं था
- Geely के अधिग्रहण के बाद Volvo वास्तविक road crash data आधारित safety design जारी रखेगा या नहीं, यह अब भी पूरी तरह स्पष्ट नहीं है
- कई markets में तो Volvo जैसी कंपनी शुरू से थी ही नहीं, इसलिए वहाँ consumer standard tests से बाहर की quality differences पहचान नहीं पाता और बाज़ार lemons market के अधिक करीब होता है
culture, trust, और in-house बनाना
- यह रवैया कि जिसके साथ अन्याय हुआ उसने हर संभावना के लिए पहले से तैयारी नहीं की, इसलिए वही ज़िम्मेदार है, अमेरिकी समाज में अक्सर दिखता है
- cafe में थोड़ी देर नज़र हटने पर laptop चोरी हो जाए तो पीड़ित को दोष देना
- terms change छूट जाने पर कहना कि हर terms update न पढ़ना उसी की गलती है
- ऐसे traffic accident में फँसे व्यक्ति को खराब driver कहना, जिसे टालना मुश्किल था
- Google Maps की ambiguous directions की आलोचना करने वाले से कहना कि उसे हर route पहले से याद होना चाहिए था
- जो चीज़ें North America में “दुनिया ऐसे ही चलती है” जैसी लगती हैं, वे दूसरी cultures में मनमानी हो सकती हैं
- उदाहरण के तौर पर, दक्षिण कोरिया के cafe में bag और laptop छोड़कर घंटों बाद लौटने पर भी उनके वहीं होने की संभावना अधिक बताई गई
- जापान के बारे में भी ऐसा ही कहा गया
- अमेरिका में भी, public place में चीज़ें छोड़ने से अलग, खाली घर में घुसकर चोरी करना तकनीकी रूप से बहुत कठिन नहीं है; फिर भी अधिकांश इलाकों में यह आम नहीं है, और पीड़ित को उसी तरह दोषी नहीं ठहराया जाता
- Avery Pennarun का दक्षिण कोरिया में online order का अनुभव अमेरिकी multi-barcode, box, और return process से अलग बताया गया: बिना label वाले box या bag में delivery, और app में return बताकर उसे दरवाज़े पर छोड़ देना, फिर pickup हो जाना
- ऐसे अंतर दिखाते हैं कि organizations और दूसरे लोग कैसे काम कर सकते हैं, इस बारे में shared expectations संस्कृति के अनुसार अलग होती हैं
COVID का मामला और self-fulfilling expectations
- Vietnam और Taiwan जैसे कुछ एशियाई देशों में रहने वाले लोग शुरुआती variants से पहले तक बहुत कम COVID rates के बीच लगभग सामान्य जीवन जी सके
- कई पश्चिमी देशों में यह राय थी कि lockdown बेकार हैं और COVID spread को रोका नहीं जा सकता; और lockdown लगने के बाद भी उन्हें जल्द से जल्द हटाने का दबाव था
- बाद में कुछ लोगों का रुख यह हो गया कि “वैसे भी COVID endemic बनना ही था, इसलिए lockdown हमेशा मूर्खतापूर्ण थे और उन्होंने सिर्फ आर्थिक नुकसान किया”
- in-person retail sales या restaurant data से यह दिख सकता है कि pandemic के पहले साल, जब virus व्यापक था, लोग lockdown से पहले और बाद दोनों समय स्वेच्छा से अपनी गतिविधि घटा रहे थे
- Taiwan और Vietnam जैसे कुछ एशियाई देशों में lockdown लागू होने पर लोग सामान्यतः उनका पालन करते थे, और अधिक contagious variants तथा vaccination के बाद बढ़ी risk tolerance आने से पहले तक outbreaks दबाए जा सकते थे
- क्योंकि दूसरे देश COVID को दबा नहीं सके, इसलिए जिन्होंने उसे दबा लिया था, उन देशों में भी COVID बार-बार बाहर से लौटता रहा
कंपनियों के बीच और कंपनियों के भीतर trust की कमी की लागत
- जहाँ यह मान लिया जाता हो कि दूसरी कंपनी contract wording की अंतिम सीमा तक धकेलेगी, वहाँ in-house टीम की आधी क्षमता जितनी service guarantee कराने वाला contract negotiate करना भी अक्सर मूल्यहीन हो जाता है
- contracts में ऐसे clauses जोड़ने की कोशिश हो सकती है जो अर्थ को कमज़ोर कर दें, और उन्हें हटाने पर भी legal enforcement की लागत ऊँची होती है
- support SLA violation के मामलों में भी legal action की जगह contract terminate करना चुना गया
- अगर external companies पर भरोसा नहीं किया जा सकता, तो जिस क्षेत्र में चीज़ें सचमुच सही चलानी हों, उसे खुद संभालने के अलावा विकल्प कम रह जाते हैं
- trust की यही कमी कंपनी के भीतर भी लागत पैदा करती है
- एक कंपनी में trust इतना कम था कि VP के verbal promise पर प्रतिक्रिया यह होती थी कि contract न हो तो वह promise ही नहीं है
- चूँकि कर्मचारी हर promise को contract में नहीं बदल सकते, teams और organizations अपने दायरे से बाहर भरोसा नहीं कर पातीं और empire-building जैसी दिशा में बढ़ सकती हैं
- internal distrust के लिए inter-company distrust की तुलना में mitigation के साधन अधिक हैं, फिर भी इसकी लागत बड़ी है
- Intel में Andy Grove के समय और Google में Eric Schmidt के समय leadership ने reliability और honesty को मज़बूती से लागू किया, और गवाही है कि यही सफलता का एक बड़ा कारण था
- अगर top leadership बदल जाए और honesty enforce न करे, तो बड़े enterprises की upper layers में आम political culture अंदर घुस सकती है; लेकिन यह अपरिहार्य नहीं है
“Build” की सीमाएँ
- खुद बनाने से हमेशा अच्छा परिणाम नहीं मिलता
- in-house design भी इस लेख के data sync product की तरह मूल रूप से टूटा हुआ हो सकता है, और design stage में कई लोगों के यह समझाने के बावजूद कि यह काम नहीं करेगा, उन्हें नज़रअंदाज़ किया जा सकता है
- “Build”, “Buy” की तुलना में ज़्यादा control और design पर influence देता है, इसलिए working product बनने की संभावना बढ़ती है; लेकिन dysfunctional teams और organizations आसानी से non-working product भी बना सकती हैं
- Steve Jobs की IBM और Xerox पर टिप्पणियों की तरह, monopoly जैसी स्थिति में बेहतर product बनाने वाले लोग कंपनी की सफलता के लिए कम महत्वपूर्ण हो जाते हैं, और sales व marketing वाले decision-making पर हावी होकर product sense मिटा सकते हैं
- अगर बड़ी कंपनी duplicated effort से बचने के नाम पर मिलते-जुलते projects बंद कर दे और एक team को monopoly दे दे, तो वही समस्या company के अंदर teams और organizations के स्तर पर भी आ सकती है
- कुछ teams ने non-working dependency से बचने के लिए parallel stack फिर से implement किया, लेकिन यह सिर्फ इसलिए संभव हुआ क्योंकि leadership प्रभावी control नहीं कर पा रही थी
- अच्छे plan वाली leadership की effective top-down direction के फायदे हो सकते हैं, लेकिन इस मामले में वह विकल्प मौजूद नहीं था, और leadership का execute न कर पाना कंपनी के लिए बेहतर साबित हुआ
1 टिप्पणियां
Hacker News की राय
इस लेख में जो बात खास तौर पर दिलचस्प है, वह है खुद बनाने और खरीदने के बीच का स्पेक्ट्रम
जैसा Dan बताते हैं, बहुत-सा software बस अच्छी quality का नहीं होता। या तो वे अपनी खामियों को ईमानदारी से नहीं दिखाते (जैसे Postgres → Snowflake tool), या उनका scope बहुत ज्यादा चौड़ा होता है, या abstraction कमजोर होती है। खरीदना या open source चुनकर इस्तेमाल करना भी उम्मीद से कहीं ज्यादा समय खा सकता है
मैं JS ecosystem को थोड़ा-थोड़ा आज़मा रहा हूँ, और बार-बार महसूस होता है कि star count या download count जैसे कम दिमाग लगाकर देखे जाने वाले quality signal असली quality के बारे में लगभग कुछ नहीं बताते। कई बार लगता है कि winner लगभग random तरीके से तय हो जाता है, और अंत में code पढ़ने और खुद integrate करके देखने के अलावा कोई रास्ता नहीं बचता
मुझे तो यह भी लगता है कि ecosystem या market जितना बड़ा होता है, कुल मिलाकर उस पर भरोसा करना उतना ही मुश्किल हो जाता है। क्योंकि scale बढ़ता है और प्रभाव या पैसे के पीछे भागने वाले लोग इकट्ठा हो जाते हैं। जिन home appliances की जरूरत सबको होती है, उनके साथ भी कुछ ऐसा ही है
लेकिन साथ ही यह काफी rational व्यवहार भी है। क्योंकि market जिस एकमात्र तरीके की इजाजत देता है, उसी से वह “इस्तेमाल करके देखें तो क्या होता है” वाली hypothesis को test कर रहा होता है। इंसान अपनी future needs और behavior का सही अनुमान नहीं लगा पाता, और product कई features का bundle होते हैं, इसलिए high-dimensional future situations में कौन-सा feature महत्वपूर्ण होगा, यह असल में इस्तेमाल करने से पहले अक्सर पता नहीं चलता। इसलिए खरीदना एक empirical experiment बन जाता है
दुर्भाग्य से consumers, recruiters, और कभी-कभी hiring managers भी कुछ बेचने वाली party के साथ information asymmetry में होते हैं। consumer को उन suppliers की self-reporting पर निर्भर होना पड़ता है जो खुद को expert बताते हैं
https://vonnik.substack.com/p/the-expert-layman-problem
1–2 साल पहले HN पर मैंने एक छोटा-सा लेख पढ़ा था कि internet search करते समय “best” शब्द हटाकर criteria को ज्यादा specific लिखें। जैसे “best car” की जगह “car with best resale value” search करना। उसके बाद मेरी जिंदगी और सोचने का तरीका काफी बेहतर हुआ
ये tools अलग-अलग ecosystems और funding levels से आए हैं, लेकिन इन्हें कई सालों तक reliably इस्तेमाल किया जा सका है, और ये सभी complex tools हैं। बेशक bugs हैं, लेकिन severity और manageability के लिहाज से वे acceptable रहे हैं
हालांकि लगता है कि वे भी इसे खुलकर कहने से थोड़ा हिचकते हैं: मेरे हिसाब से software और product outcomes के खराब होने की वजह यह है कि मौजूदा antitrust laws को भी ठीक से enforce नहीं किया गया, और Moore’s Law के 50 iterations के बाद की reality के अनुसार उन्हें update भी नहीं किया गया
Smartphone चाहिए? App Store fees सूदखोरी जैसे स्तर पर हैं और वही दो कंपनियां हैं। Cloud computing किराए पर लेनी है? सिर्फ कुछ कंपनियां हैं, जिनमें चौथे नंबर की company भी नंबर 1 company जैसा ही price लेती है। कोई disruptive encrypted messenger बनाते हैं? तो Mr. Marlinspike की तरह नाव पर रहते हुए Jason Bourne की तरह पीछे नज़र रखनी पड़ती है
क्या इसमें जरा भी हैरानी है कि Google Search से लेकर Netflix तक, सब 10 साल पहले के अपने ही versions से खराब हो गए हैं? उन्हें आकर्षक बनाने का incentive ही नहीं है
समस्या यह है कि यह प्रवृत्ति तकनीकी लोगों में universal नहीं है। इसलिए मैं artistic, creative और persistent engineers को hire और train करना पसंद करता हूँ
यह दावा मेरी कंपनी Fivetran के बारे में है, इसलिए मैं कुछ हद तक समझा सकता हूँ
Dan की यह समझ गलत है कि “Postgres data source को change log में पीछे की ओर navigate कर पाना चाहिए, लेकिन Postgres change log को consume करने के बाद फेंक देता है, इसलिए यह काम support नहीं कर सकता”
Postgres logical replication हर consumer को WAL में bookmark बनाए रखने देता है, और उस segment के receive होने की पुष्टि करके bookmark आगे बढ़ाने से पहले तक WAL को सुरक्षित रखता है। लगता है उन्होंने हमारे product को थोड़ी देर आज़माया, कोई समस्या हुई या उन्हें लगी कि समस्या है, और थोड़ी-सी जांच के बाद इस निष्कर्ष पर पहुँच गए कि वे इस technology को सालों से संभाल रहे लोगों से बेहतर जानते हैं
बेशक expert गलत हो सकते हैं और कोई एक समझदार व्यक्ति सही हो सकता है। लेकिन इस लेख का एक हिस्सा ऐसा भी है जिसमें कोई अहंकारी व्यक्ति, जिसे लगता है कि वह सब से बेहतर जानता है, दूसरों के काम को खराब मानने का जल्दबाज़ी में निष्कर्ष निकालता दिखता है
यह “Connect data sources to PostgreSQL in minutes using Fivetran” कहकर advertise करता है, लेकिन अगर Dan Luu और उनके साथी, जो smart और capable engineers हैं, product को ठीक से इस्तेमाल करने का तरीका नहीं समझ पाए, और customer support भी यह नहीं समझ पाया कि sync क्यों टूट रहा है, तो यह सिर्फ़ customer का अहंकार नहीं हो सकता
अगर बहुत smart लोग product को advertised तरीके से इस्तेमाल नहीं कर पाते, तो समस्या advertising, documentation या default settings में कहीं है। या source data को शायद बहुत specific तरीके से set up करना पड़ता हो
आखिरकार, इस तरह के काम को outsource करने पर भी काफी internal knowledge चाहिए होती है, और इसलिए यह पहली नज़र में जितना सस्ता दिखता है, उतना शायद न हो—लेख का बड़ा मुद्दा भी यही है
यह reply पढ़ने के बाद तो उल्टा product को लेकर संवेदनशील और defensive आप ही लगते हैं। product के लिए पैसे देने वाले और मुश्किल झेल रहे customer को लेकर, यह समझने के बजाय कि वह क्यों frustrated है, आप उसे अहंकारी ठहराने के करीब दिखते हैं
Dan का निष्कर्ष गलत हो सकता है। लेकिन reply का tone और wording अप्रिय है, और उसमें wit, empathy या सीखने का रुख नहीं दिखता
अगर जवाब कुछ ऐसा होता, “नहीं, मुझे नहीं लगता कि x, y, z की वजह से यह टूटा है। हालांकि यहाँ developer experience की कमी समझ में आती है। हम इसे सुधार सकते हैं,” तो कहीं बेहतर होता
मैंने Fivetran लंबे समय तक इस्तेमाल किया और ऐसे sync issues लगातार झेले। लगभग हर दो महीने में forced resync करना पड़ता था। contract खत्म हुआ तो सच में राहत मिली
Dan का लेख 2022 का है। अब 2024 है, तो हो सकता है इस बीच Postgres और Fivetran के बीच code path बदल गया हो और rewind करना संभव हो गया हो
“बाज़ार efficiency को force करता है, इसलिए किसी company में बड़ी inefficiency होते हुए भी उसका बच पाना असंभव है” — यह बात ऊपर-ऊपर से ही पूरी तरह गलत लगती है
अगर आपने बड़ी companies में काम किया है, तो आपको पता होगा कि वे किसी जादू से ज़्यादा smart नहीं होतीं, और अक्सर बहुत inefficient काम करती हैं
intuitive तौर पर भी यह बात इतनी गलत है कि जो लोग इसे सच मानते हैं, उन्हें देखकर हैरानी होती है
यह सिर्फ़ बुरे अर्थ में नहीं है। ज़्यादातर religions Golden Rule जैसे उपयोगी concepts, और ऐसी चीज़ें—जो literal तौर पर सच नहीं होतीं लेकिन social और emotional ज़रूरतें पूरी करके उपयोगी विचारों को पीढ़ियों तक आगे बढ़ाती हैं—दोनों को साथ पैक करती हैं। Huston Smith के शब्दों में, religion spirituality को historical traction देता है
यह idea कि markets efficiency ला सकते हैं, एक मूल्यवान insight है। लेकिन जिन लोगों के लिए economics intro religion की तरह काम करता है, वे उस पल को पहचानने में मुश्किल महसूस करते हैं जब यह effect overwhelm हो जाता है। आजकल यह आसानी से दिख जाता है जब nominally pro-market लोग oligopoly और monopoly को cheer करते हैं, या market को ज़्यादा efficient बनाने वाले regulations पर गुस्सा होते हैं
आसान test यह है कि वे sustained high profits को कैसे देखते हैं। जो लोग competition के ज़रिए improvement कराने की क्षमता के कारण markets को महत्व देते हैं, उनके लिए लंबे समय तक high profits बने रहना price competition की कमी जैसा warning signal है
पहले company के scale को ध्यान में रखना होगा। आप लाखों dollars leak करती हुई साफ़ inefficiency देख सकते हैं, लेकिन अगर company का annual revenue 12 digits में है, तो यह बड़ी बात नहीं हो सकती
developer hardware पर बचत करके पैसे घटाने की कोशिश करने वाली company को हम सब जानते हैं, या शायद उसी में काम कर रहे हैं। एक simple upgrade से ही कुछ हफ्तों में productivity gains के ज़रिए cost recover हो सकती है। लेकिन अगर वह cost developer productivity का लगभग 10% है तो? यह बड़ी है, फिर भी शायद company के अस्तित्व का सवाल नहीं बनेगी
extreme cases में यह निश्चित रूप से सही है, और government programs व private companies के बीच बड़ा फर्क भी यही है। Companies हमेशा घाटे में रहकर टिक नहीं सकतीं
कम extreme स्थितियों में, यह बात तब सही होती है जब inefficiency की cost company की moat से आगे निकल जाए। Oracle enterprise database market के एक खास हिस्से पर इतनी मजबूत पकड़ रखता है कि वह भारी inefficiency सह सकता है। लेकिन अगर बात बहुत आगे बढ़ जाए, तो नए खिलाड़ी उसे खा जाएँगे
competitors को आपको catch up करने के लिए कुछ market frictions पार करने पड़ते हैं। factory हो तो वह friction factory की cost और उस पैसे को factory में फँसाने की opportunity cost है। इसलिए उससे छोटी inefficiency असल में safe inefficiency level बन जाती है। मोटे तौर पर बात यही है
एक बड़ी company के अंदर developer के तौर पर आप पागलपन भरी inefficiency देख सकते हैं, लेकिन competitors से लड़ने की क्षमता पर उसके असली असर की तुलना में वह cost आम तौर पर relatively छोटी होती है
markets का सवाल efficient होने का नहीं, बल्कि competitor से epsilon भर ज़्यादा efficient होने का है
Big Tech में काम करने वाले दोस्त के शब्दों में, हालत यह है: “काश 300 लोगों की team को शुरुआती 3 लोगों की team जितना ही productive बना पाते”
कई क्षेत्रों में जवाब कहीं ज़्यादा सरल है। अक्सर खरीदारों में उत्पाद का मूल्यांकन करने की क्षमता ही नहीं होती
उदाहरण के लिए, लगता है कि 50% से ज़्यादा लोग tax accountant को उसकी तकनीकी और कानूनी सटीकता के बजाय refund की रकम के आधार पर आंकेंगे। लेकिन ज़िम्मेदारी फिर भी आपकी ही रहती है, इसलिए सटीकता “अच्छा” होने का एक अहम पैमाना है
Dentistry में भी यही बात है। अगर dentist कहे कि procedure X ज़रूरी है, तो एक गैर-विशेषज्ञ कुछ सवाल पूछने के अलावा और कर ही क्या सकता है। डॉक्टरों के साथ भी ऐसा ही है, और कारीगरों के काम में भी—ऊपर से काम सरल दिखे, फिर भी उसमें वर्षों का जमा हुआ practical knowledge होता है जो गैर-विशेषज्ञ को दिखाई नहीं देता
खासकर STEM झुकाव वाले लोग हर चीज़ को optimization problem और सही metrics खोजने तक सीमित करना चाहते हैं, लेकिन वास्तविकता अक्सर ऐसे नहीं चलती
लेकिन जहां सामान बिकता है, जैसे Amazon, वही reviews host भी करता है—इसमें हमेशा conflict of interest रहा है। AirBNB भी ऐसा ही है। वह यह बर्दाश्त नहीं कर सकता कि उसके सारे hosts 2-star बन जाएं
खरीदार के लिए यह लगातार मुश्किल होता जाएगा, और आगे इसके और खराब होने की संभावना है
किसी भी चीज़ में पर्याप्त गहराई तक जाएं, और उसी समय लोग आपको nerd कहना शुरू कर देते हैं
SSD के NAND types, DRAM, CPU cores, microarchitecture, board layout, power supply, fans आदि जैसे छोटे variables सचमुच बहुत हैं। जब तक कोई खुद दिलचस्पी न ले, ज़्यादातर लोग marketing या advertising से आसानी से प्रभावित हो जाते हैं
इन दिनों अच्छे design के बारे में सोच रहा/रही हूँ। चीज़ों को ठीक से काम करना चाहिए, लेकिन साथ ही जब वे सुंदर भी हों तो जीवन कहीं बेहतर हो जाता है। लगता है Don Norman का essay Emotion and Design इस सोच की शुरुआत था
Conan OBrien और Jordan Schlansky के podcast में नाक के बाल काटने वाले trimmer के संदर्भ में इस पर बात हुई थी, जो बहुत मज़ेदार भी थी और काफ़ी गहराई से जुड़ी भी लगी। Schlansky ने कहा, “मैं मानता हूँ कि मैं minimal तरीके से जी सकता हूँ, लेकिन जो products मैं खरीदता हूँ वे बहुत high quality के होने चाहिए और उनमें कुछ खास होना चाहिए। तब वे लंबे समय तक चलते हैं, इसलिए आगे चलकर मैं कम चीज़ें खरीदता हूँ”
उन्होंने यह भी कहा, “हम खुद को उन चीज़ों से परिभाषित करते हैं जिनसे हम रोज़ interact करते हैं। मैं खुद को सुंदरता और ऊँचे aesthetic आनंद से घेरता हूँ। इसमें सिर्फ़ सुंदर कपड़े पहनना नहीं, बल्कि सुंदर nose hair trimmer इस्तेमाल करना भी शामिल है”
मैं भी trimmer खरीदने वाला/वाली हूँ, इसलिए ऐसा version चाहता/चाहती हूँ जिसे सोच-समझकर design किया गया हो और अच्छी तरह बनाया गया हो। Covid pandemic शुरू होने के बाद से मैं घर पर लगातार ऐसा ही करता/करती आया/आई हूँ। यानी उन छोटी-छोटी परेशान करने वाली चीज़ों को बदलना, या उन चीज़ों को upgrade करना जिनसे दिन थोड़ा बेहतर हो सके
एक बेहतर नियम है। अगर आपको लगे कि किसी चीज़ की ज़रूरत है, तो पहले उसका सबसे सस्ता version खरीदें जो काम पूरा कर सके। अगर आप उसे इतना इस्तेमाल कर लें कि वह घिसकर खत्म हो जाए, तब अपनी क्षमता के हिसाब से सबसे अच्छा विकल्प खरीदें। वरना आप शायद ऐसी चीज़ पर पैसा फेंक रहे हैं जिसे अंत में इस्तेमाल ही न करें। यह मुख्यतः tools पर लागू होता है, लेकिन दूसरे non-essential सामानों पर भी लागू होता है
दूसरे शब्दों में, यह universal signal नहीं है, लेकिन अच्छा और खासकर अच्छी तरह execute किया गया design इस बात का संकेत हो सकता है कि बनाने वाले ने उसके काम करने के तरीके और अंदरूनी हिस्सों पर भी वही बारीकी लगाई है
उदाहरण के लिए, अच्छी quality के kitchenware खरीदने का काम मैं लगभग 10 साल से टाल रहा/रही हूँ, क्योंकि options बहुत ज़्यादा हैं और discoverability कम है—यह एक विरोधाभासी combination है
https://archive.org/details/quintessence00bett
किताब में आने वाली चीज़ें हैं The Martini, The Ace Comb, Wedgwood Plain White Bone China, The Spalding Rubber Ball, Ivory Soap, Campbell’s Tomato Soup, The Peanut Butter and Jelly Sandwich, The Timex Mercury 20521 Watch, The Steinway Piano, Camel Cigarettes, Keds High-top Sneakers, The Oreo Cookie, The Mont Blanc Diplomat Pen, Frederick’s of Hollywood Lingerie, The Slinky Toy, The Brown Paper Bag, The Milk-Bone Dog Biscuit, The Cigarette Hawk Speedboat, Silly Putty Toy, Crayola Crayons, The Harley-Davidson ElectraGlide Motorcycle, The Zippo Lighter, The Cartier Santos Watch, Coppertone Suntan Lotion, The Goodyear Blimp, The Bean Maine Hunting Boot, Green Giant Peas, The Frisbee Flying Saucer, The English Bull Terrier, The Louisville Slugger Baseball Bat, Jockey Briefs, Monopoly Board Game, The Ghurka Express Bag No. 2, The Polaroid SX-70 Camera, Ray-Ban Sunglasses, Budweiser Beer, The Hershey’s Chocolate Kiss, The Volkswagen Beetle Car, The American Express Card, M&M’s Chocolate Candies, Bayer Aspirin, Honey Bear, The Faber Mongol #2 Pencil, Fox’s U-Bet Chocolate Syrup, Lacoste Polo Shirt, Steiff Teddy Bears, Johnson’s Baby Powder, The Swiss Army Knife, Levi’s Jeans, Bass Weejun Loafers, The Hamilton Beach Model 936 Drink Mixer, Coca-Cola Soft Drink, Ohio Blue Tip Kitchen Matches, Kleenex Tissues, Barnum’s Animal Crackers, The Marklin Electric HO Gauge Model Trains, The Stetson Hat, Heinz Ketchup, The Nathan’s Famous Hot Dog, The Oil Can, LePage’s Mucilage, Tupperware Containers, El Bubble Bubblegum Cigar, Dom Perignon Champagne, The Checker Cab हैं
Dan Luu की लिखी चीज़ें हमेशा सोचने पर मजबूर करती हैं, और यह लेख भी वैसा ही है
यह हैरानी की बात लगी कि संगठन के बड़े होने पर अंदरूनी जागीरों के बीच बनने वाले अविश्वास के जाल को Dan ने Nash equilibrium से नहीं जोड़ा
संगठन के भीतर अविश्वास का जाल, Prisoner's dilemma के एक जटिल संस्करण से ज्यादा कुछ नहीं है
अगर CEO भरोसे और सहयोग को सक्रिय रूप से लागू नहीं कराता, तो हर जागीर संगठन के भीतर मौजूद दूसरे अविश्वसनीय गुटों की संभावित धोखाधड़ी के खिलाफ टिके रहने और फलने-फूलने के लिए स्वाभाविक रूप से अपने व्यवहार विकसित कर लेती है। प्राकृतिक ecosystem में भी ऐसा ही व्यवहार दिखता है, जहां समूहों के बीच स्थायी ईमानदारी मांगने वाले global optimum की बजाय, धोखाधड़ी के खिलाफ मजबूत suboptimal equilibrium की ओर विकास होने की प्रवृत्ति होती है। कई माहौल में धोखाधड़ी के प्रति मजबूती एक evolutionary advantage है
https://en.wikipedia.org/wiki/Nash_equilibrium
https://en.wikipedia.org/wiki/Prisoner's_dilemma
यह 2022 का लेख है। आधार: https://x.com/danluu/status/1503512394126938120
काश Dan अपने लेखों में तारीख डालते
अजीब तरह से, इस लेख को देखकर मुझे stock याद आया। वही liquid जो gravy, soup, sauce आदि में इस्तेमाल होता है
मेरे जानने वाले ज्यादातर लोग box या bottle वाला stock, या bouillon cubes इस्तेमाल करते हैं। इसमें अपने-आप में कुछ गलत नहीं है, और इससे संतोषजनक खाना बन सकता है
लेकिन अगर आप खुद खाना बनाते हैं, तो stock बनाना आसान है। फेंकने लायक सब्जियों और मांस के टुकड़े, जैसे हड्डियां या प्याज के छिलके, एक बर्तन में डालें, पानी डालें, चाहें तो नमक और काली मिर्च डालें, और करीब एक घंटे तक उबालें। यह आप कोई और खाना बनाते हुए भी कर सकते हैं, और बाद में इस्तेमाल के लिए freeze भी कर सकते हैं
और यह bottle या cube से निश्चित रूप से बेहतर होता है। शायद इसलिए कि आपने खुद मेहनत की होती है, या इसलिए कि industrial process में खो जाने वाली कई स्वाद-परतों की जटिलता इसमें बची रहती है। जो भी हो, यह बहुत अच्छी तरह काम करने वाला stock है
आखिर में जरूरत समय की होती है, और हम अक्सर सोचते हैं कि हमारे पास वह समय नहीं है। शायद यह असंबंधित विचार हो, लेकिन अगर आपको घर पर खाना बनाना पसंद है, तो मैं अपना stock खुद बनाने की सलाह दूंगा
“अगर यह इतना साफ है, तो कंपनी के अंदर किसी ने इसे ठीक कर दिया होता, या कोई दूसरी कंपनी ज्यादा efficient या बेहतर होकर जीत गई होती” वाली बात पर, मुझे लगता है कि tech कंपनियों में दो तरह के लोग होते हैं
एक वे जिन्होंने ऐसे unused cloud infrastructure को हटाया है जिस पर हर महीने 50,000 डॉलर से ज्यादा खर्च हो रहा था और जिसे कोई याद भी नहीं करता था, और दूसरे वे जो मानते हैं कि ऐसा होना संभव ही नहीं है
evolution और market को लेकर एक बुनियादी गलतफहमी है। बात यह है कि दोनों में से किसी को भी किसी चीज को “optimize” करने की जरूरत नहीं होती
जीवों को भोजन पाने में सबसे बेहतरीन और efficient होने की जरूरत नहीं होती, बस इतना काफी है कि वे प्रजनन करने तक लंबे समय तक जीवित रहें। चीते को मैदान का सबसे तेज चीता होने की जरूरत नहीं, बस सबसे धीमे हिरण से तेज होना काफी है। कंपनियों को भी perfect product बनाने की जरूरत नहीं, वे तब तक बची रहती हैं जब तक कोई भी profit कमाने लायक पर्याप्त ठीक-ठाक हों
यह समझ में आते ही सब कुछ समझ आने लगता है। accountant गलती कैसे कर सकता है? क्योंकि वह इतनी खराब नहीं होती कि customer चला जाए। product घटिया तरीके से कैसे बनाया जा सकता है? क्योंकि वह इतना घटिया नहीं होता कि लोग खरीदना बंद कर दें। सच में, profit के नजरिए से कंपनी के लिए सबसे optimal यही है कि वह न डूबने की हद तक जितनी हो सके उतनी खराब हालत में रहे। market जिस quality improvement की मांग नहीं करता, उस पर extra resources लगाना एक मायने में बर्बादी है
engineering के नजरिए से यह दर्दनाक है। हम अच्छी चीजें बनाना चाहते हैं, लेकिन customer बहुत बार इस बात से ज्यादा परवाह करता है कि वह सस्ता है और खरीदने लायक बस पर्याप्त है, न कि वह कितना अच्छा है