98% उतना ज़्यादा नहीं है

 (whynothugo.nl)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 98% का आंकड़ा लॉटरी जीतने या परीक्षा में टॉप स्कोर जैसी असाधारण उपलब्धियों के लिए बड़ा लग सकता है, लेकिन वेबसाइट जैसी उन चीज़ों में कम पड़ सकता है जिनसे बुनियादी तौर पर काम करने की उम्मीद होती है
  • जिस रेस्टोरेंट में फूड पॉइज़निंग न हो, समय पर वेतन देने वाला नियोक्ता, या बिल चुकाकर जाने वाला ग्राहक—ऐसी स्थितियों में जहां बुनियादी अपेक्षाएं दांव पर हों, 2% विफलता भी बार-बार नुकसान बन जाती है
  • अगर नया ब्राउज़र फीचर इस्तेमाल करने वाली वेबसाइट आबादी के केवल 98% लोगों के लिए काम करती है, तो हिसाब के मुताबिक करीब 15 करोड़ लोग बाहर रह जाते हैं
  • “कुल आबादी के आधार पर 98% support” असल visitors के distribution से अलग हो सकता है; एक ग्राहक की site पर पिछले 1 साल में आए browsers में nested CSS support लगभग 70% ही था
  • अगर कोई नया feature gracefully degrade नहीं कर पाता, तो 98% support “widely supported” नहीं है, बल्कि कुछ users के लिए बुनियादी न्यूनतम शर्तें पूरी न करने वाली स्थिति है

जहां 98% पर्याप्त नहीं होता

  • 98% का अर्थ context के हिसाब से बहुत बदल जाता है
    • लॉटरी खेलते समय 98% संभावना से जीतना, या परीक्षा में 98% संभावना से top score पाना बहुत अच्छा result है
    • अगर रेस्टोरेंट के ग्राहक केवल 98% संभावना से ही food poisoning से बचते हों, तो हर महीने या हर हफ्ते कोई न कोई बीमार हो सकता है
    • अगर employer केवल 98% संभावना से ही wages देता हो, या customer रेस्टोरेंट छोड़ने से पहले केवल 98% संभावना से ही bill pay करता हो, तो इसे स्वीकार करना मुश्किल है
  • जहां बुनियादी अपेक्षाएं दांव पर हों, वहां 2% failure rate भी बड़ी समस्या बन जाता है
    • अगर कोई website केवल 98% लोगों के लिए काम करती है, तो करीब 15 करोड़ लोगों के लिए काम नहीं करती
    • अगर website में किया गया बदलाव केवल 98% visitors के लिए काम करता है, तो यह मौजूदा users के 2% को effectively बाहर निकालने जैसा है

Browser support rate और असल visitors का अंतर

  • सामान्य आबादी के आधार पर support rate, वास्तविक site visitors के support rate से अलग हो सकता है
    • कोई feature पूरी आबादी के 98% लोगों के लिए काम करे, फिर भी किसी खास site के वास्तविक users में केवल 70% के लिए काम कर सकता है
  • nested CSS के उदाहरण में यह अंतर दिखता है
    • nested CSS 2023 से standard है, लेकिन किसी खास site पर “सुरक्षित रूप से इस्तेमाल किया जा सकता है” वाला आकलन वैसा ही सही हो, यह ज़रूरी नहीं
    • एक ग्राहक की website के पिछले 1 साल के browser distribution की जांच में, नए CSS feature को support करने वाले visiting browsers लगभग 70% थे
    • आम तौर पर “widely supported” दिखने वाला feature भी उस site के visitors के 30% को बाहर कर सकता था
  • मजबूत engineering का मतलब केवल अधिकतर लोगों के लिए काम करना नहीं, बल्कि edge cases को gracefully handle करना है
    • अगर नया feature gracefully degrade नहीं कर पाता, तो 98% support 2% users के लिए बुनियादी न्यूनतम शर्तें पूरी न करने की स्थिति ही रहता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • 98% कई बार पर्याप्त भी होता है
    अगर किसी business plan के चलने के लिए बाज़ार के 98% से भी ज़्यादा हिस्से को पकड़ना ज़रूरी है, तो वह योजना पहले से ही असफल है, और ऐसा होने की संभावना भी कम है
    हमेशा की तरह, यह “हालात पर निर्भर करता है” वाला मामला है। अगर user base आम तौर पर तकनीक से परिचित नहीं है, तो आपको ऐसे 10 साल से भी पुराने browser को support करना पड़ सकता है जिन्हें update भी नहीं किया जाता; लेकिन अगर ऐसा नहीं है, तो शायद उन लोगों की ही चिंता करना काफी हो जो ऐसा computer इस्तेमाल करते हैं जिस पर कम से कम साल में एक बार browser update किया जा सके
    आखिरकार trade-off code complexity और development time बनाम बड़ा बाज़ार है, और हर company को इसका फैसला अलग से करना होगा

    • एक पूर्व chef के तौर पर, मैंने 2 Michelin two-star restaurants में काम किया है, और 5% भी पर्याप्त से कहीं ज़्यादा, बल्कि शानदार है
      कहा जाता है कि “अगर यह 98% लोगों के लिए काम करता है, तो लगभग 15 करोड़ लोगों के लिए काम नहीं करता”, लेकिन अगर आप एक रात में सिर्फ 70 लोगों के लिए खाना बना सकते हैं, तो latest browser तक access न रखने वाले 15 करोड़ लोगों को आप शुरू से ही serve नहीं कर सकते। जो लोग latest browser इस्तेमाल कर सकते हैं लेकिन नहीं करते, वे शायद मेरे खाने को भी बहुत पसंद न करें
      किसी restaurant को टिके रहने के लिए 8 अरब लोगों को खुश करने की ज़रूरत नहीं; उसे बस करीब 1,000 ऐसे लोगों को खुश करना है जो anniversary, birthday और creative food के आनंद के लिए बार-बार लौटते रहें
      yacht chef के रूप में काम करते समय मुझे सिर्फ 10 लोगों को खुश करना था, और मैंने ऐसा तरीका अपनाया जिसमें crew और guests सभी एक ही खाना खाते थे। supply company पर निर्भर रहने के बजाय खुद shopping करने से, जब guests एक महीने तक onboard रहते थे तो monthly food cost लगभग 30,000 dollars से घटकर 10,000 dollars हो गई। करीब 2005 में St. Barts में ingredients France से रोज़ air freight होकर आते थे, इसलिए महंगे थे, लेकिन इसी वजह से मैं crew को भी Chateaubriand, osso buco जैसे dishes परोस सकता था
      इसलिए जो balanced, fiber-rich और healthy खाना मैं रोज़ खाना चाहता था, वही सबके रोज़ का खाना बन गया
      कुछ लोग पूछते हैं कि क्या guests या owner यह नहीं बताते थे कि वे रोज़ क्या खाना चाहते हैं; पति Fortune 500 company के CEO थे और retirement के बाद भी board chairman थे। वे रोज़ अरबों dollars के फैसले लेने वाले व्यक्ति थे, और उनकी पत्नी भी बहुत व्यस्त थीं। हर शाम menu का जवाब देना उनके लिए सबसे नापसंद कामों में से एक था, और उन्होंने वह निर्णय मुझे सौंप दिया था। मैं हमेशा वही बनाता था जो मैं खाना चाहता था, और वह हमेशा सही साबित होता था
      सभी को खुश करना असंभव है। कोशिश न करना ही बेहतर है। वरना आप टूट जाते हैं
    • लेख पढ़कर लगा, “फिर वही paternalistic advice, मानो resources, time और money असीमित हों”
      जिसने भी website या mobile development किया है, वह जानता है कि browsers और platforms के combinations बहुत ज़्यादा हैं, और long-tail configurations तक support करना कभी-कभी लगभग असंभव होता है और cost-benefit भी लगभग नहीं के बराबर होता है। पहले जब मैंने कुछ web apps चलाए थे, तब भी टूटे हुए या कभी-कभी malicious browser plugins की वजह से काफी errors आए थे। मैं arbitrary browser plugin combinations सभी को अपनी site के खिलाफ test करके यह verify नहीं कर सकता कि वे काम करते हैं या नहीं
      आखिर में बात सचमुच हालात पर निर्भर करती है, इसलिए मुझे लेख जैसी blanket guidelines देने की शैली पसंद नहीं। अगर Gmail users के 2% अचानक login नहीं कर पाते, तो यह करोड़ों लोगों को प्रभावित करने वाली बड़ी घटना होगी। लेकिन “आप Google नहीं हैं” वाली कहावत की तरह, कई छोटी e-commerce sites के लिए 10 साल से भी पुराने browser का इस्तेमाल करने वाले किसी एक व्यक्ति के लिए ठीक करने की कोशिश करना समझदारी नहीं है। दूसरे comment की तरह, ऐसे users वैसे भी purchase conversion की संभावना में सबसे कम होते हैं
    • यह network effects को नज़रअंदाज़ करने वाली गणना है। अमेरिका की आबादी में vegetarians 10% से कम हैं, लेकिन अगर किसी restaurant में vegetarian menu बिल्कुल नहीं है, तो आप सिर्फ उस 10% को नहीं खोते, बल्कि उस पूरी group को खो देते हैं जिसमें एक भी vegetarian शामिल है
      इसी तरह, अगर किसी website में थोड़ा भी social network effect है, तो population के कुछ हिस्से को ignore करने पर सीधे प्रभावित होने वाले प्रतिशत से कहीं बड़ी user decline हो सकती है
      भले ही site के features में social element न हो, हर business word-of-mouth नाम के network effect से प्रभावित होता है। लोग positive experience की तुलना में negative experience कहीं ज़्यादा share करते हैं, इसलिए अगर 50 में से 1 व्यक्ति को लगे कि site टूटी हुई है, तो online feedback का बड़ा हिस्सा negative से भर सकता है, और वह 2% नहीं बल्कि पूरे market में reputation को नुकसान पहुँचाता है
      business में total addressable market के छोटे हिस्से को पाने के लिए भी मेहनत करनी पड़ती है। किसी specific market पर focus करने के strategic decision के तौर पर total addressable market को जानबूझकर कम करना ठीक है, लेकिन बिना खास वजह लोगों को exclude करना निरर्थक है। Texas के BBQ restaurant में vegetarian menu न होना ठीक है क्योंकि कोई वहां इसकी उम्मीद करके नहीं जाता, लेकिन किसी सामान्य restaurant में कुछ vegetarian options भी न होना मूर्खता है। Web developers का सिर्फ इसलिए लोगों को exclude करना कि वे पिछले 20 साल से अच्छी तरह काम कर रहे तरीकों को इस्तेमाल करने में आलस करते हैं और चमकदार नई technology इस्तेमाल करना चाहते हैं, उससे भी ज़्यादा मूर्खता है
    • दुर्भाग्य से कुछ businesses essential services होते हैं, इसलिए किसी के पास उन्हें इस्तेमाल न करने का विकल्प नहीं होता, या न इस्तेमाल करने की cost बहुत ज़्यादा होती है
      उदाहरण के लिए Uber, visa/immigration से जुड़ी websites, low-cost airline booking sites वगैरह
    • हर बार अलग 2% हो सकते हैं। अंततः अगर 2% का सामना 50 बार होता है, तो 100% users को कम से कम एक बार असर पड़ेगा, और हर user को लग सकता है कि software सिर्फ 98% समय ही काम करता है। तब unreliable vendor की reputation बनती है
      बेशक आमतौर पर यह इतना extreme नहीं होता, लेकिन इस पर विचार करना चाहिए। Negative reputation positive reputation से तेज़ फैलती है
      और अगर कोई चीज़ पहले से support की जा रही थी, तो बस उसे न तोड़ना होता है। आमतौर पर यह उसे शुरुआत से काम करने लायक बनाने से आसान होता है

  • इस साल Christmas के बाद living room से tree हटाते समय, उसे ले जाते हुए सूई जैसे पत्ते हर तरफ गिर गए। मैंने झाड़ू लगाया, लेकिन पहली बार में कुछ जगहें छूट गईं, और दूसरी बार झाड़ने पर भी कुछ पत्ते रह गए
    तभी यह बात जोर से समझ आई कि सूई जैसे पत्तों के 99% से ज़्यादा हटा देना भी बिल्कुल पर्याप्त नहीं है। बहुत सारे cleaning tasks शायद ऐसे ही होते हैं, क्योंकि बहुत छोटी गंदगी भी visually साफ दिखती है। उल्टा, 100% के करीब पहुँचने पर बची हुई गंदगी और ज़्यादा उभरकर दिखने लगती है

    • yard में weeds निकालते समय हर बार बिल्कुल यही महसूस होता है। weeds का ढेर बनाने के बाद जब काम की हुई जगह देखता हूँ, तो अब भी हर तरफ weeds दिखते हैं
    • यह antibacterial soap जैसा है जो bacteria के 99.9% को हटाने का दावा करता है। यह भी साफ नहीं कि वह bacteria population के आधार पर है या types के आधार पर, लेकिन दोनों में से कोई भी हो, जो बचता है वह शायद millions में होगा और कई types का भी होगा

  • कुल मिलाकर मंशा से सहमत हूँ, लेकिन यहाँ समस्या यह नहीं है कि डेवलपर statistics से परिचित नहीं हैं, बल्कि यह सीधी-सी बात है कि इनमें से ज़्यादातर सब कुछ revenue-केंद्रित तरीके से चलता है
    पिछले हफ्ते मैं एक इवेंट का टिकट खरीदने की कोशिश कर रहा था, और आधिकारिक रास्ता सिर्फ Ticketmaster था। उन्होंने account verification के लिए phone number अनिवार्य किया, लेकिन वे जिस messaging provider का इस्तेमाल करते हैं वह मेरे नंबर पर code पहुँचा नहीं सका। घर के कुछ और नंबरों से भी कोशिश की, लेकिन सब फेल रहे
    खोजने पर इसी समस्या के बहुत से मामले मिले, इसलिए यह निश्चित रूप से known issue था, लेकिन असल में मेरे हाथ में कुछ नहीं था। उनके लिए यह बस एक calculation है। मेरे छोटे EU देश को cover करने वाला कोई दूसरा SMS provider शायद महँगा पड़े। यह भी हो सकता है कि वे अतीत में मेरे mobile carrier का दुरुपयोग करने वाले scammers से बचना चाहते हों। जो भी हो, समस्या ठीक करने की cost शायद ticket sales के नुकसान से ज़्यादा होगी
    जब तक कोई government agency उन्हें मजबूर नहीं करती, उन्हें इस बात में खास दिलचस्पी नहीं कि मैं वह इवेंट देख पाऊँ या नहीं

    • Infrastructure को सिर्फ revenue-केंद्रित आधार पर नहीं चलना चाहिए। किसी railway operator का revenue बढ़ाने का सबसे आसान तरीका छोटे और ग्रामीण इलाकों को जोड़ने वाली lines घटाना है, क्योंकि बड़े शहरों को service देने की तुलना में उनकी economics बहुत खराब होती है। mobile phone coverage और broadband internet के साथ भी यही है। सबसे profitable विकल्प है आबादी के कुछ प्रतिशत को बिल्कुल cover ही न करना
      एक बिंदु ऐसा आता है जहाँ technology सामाजिक भागीदारी का आधार बन जाती है। तब उसे सब तक उपलब्ध कराने के लिए regulate करना चाहिए
    • यह विषय HN पर जब भी आता है, वही बहाने हमेशा दिखते हैं। हर जगह चलने वाला software बनाना मुश्किल है, एक से ज़्यादा browser पर test करने में बहुत समय लगता है, X platform पर port करने के लिए किसी को hire करना बहुत महँगा है, हम जल्दी में bootstrap कर रहे हैं इसलिए Y लोगों को support करने का समय नहीं है, जब सब latest पर upgrade कर सकते हैं तो पुराने systems test क्यों करें—ऐसी बातें
      यह attitude उस privilege से आता है कि आप कभी उन 2% users में नहीं रहे। जब तक किसी दिन हम खुद वे 2% बनकर system इस्तेमाल न कर पाने की स्थिति में नहीं आ जाते, तब तक ऐसा सोचना आसान है
      iOS app बनाते समय मैं लगातार नाराज़ रहता था, क्योंकि tech lead और product management ज़िद करते थे कि हम सिर्फ current major OS version और उसके ठीक पिछले version को support करें। Engineers bug fixes, performance improvements और feature development के बजाय iOS X-2 support हटाने में समय लगाते थे। वह code refactoring में बाधा नहीं था, खास तौर पर buggy नहीं था, और architecture को भी नुकसान नहीं पहुँचा रहा था। मेरी नज़र में यह बस users को परेशान करना था; मैं तब भी इसे समझ नहीं पाया था और आज भी नहीं समझता
      अब मैं 8 साल पुराना phone इस्तेमाल कर रहा हूँ, और जैसा अंदेशा था, App Store की लगभग आधी apps इसी attitude की वजह से अब काम नहीं करतीं। तो अब लगता है कि मैं पक्का उन 2% में आ गया हूँ
    • जब हम “profit motive” कहते हैं, तो उसके नीचे का सिद्धांत असल में utilitarianism के करीब होता है। लक्ष्य अधिकतम लोगों को अधिकतम लाभ देना है, और profit उसका सिर्फ एक अपूर्ण proxy metric है

  • व्यापक बात यह है कि percentages भ्रामक हो सकते हैं। इसलिए उनका अक्सर ऐसा इस्तेमाल होता है, और वे चीज़ों को बेहतर दिखाते हैं
    आम तौर पर ज़्यादा सटीक तरीका 98% के बजाय “50 में 1” जैसी odds-style notation का इस्तेमाल करना है। Percentages के दोनों सिरों पर एक तरह की singularity होती है, और छोटे numerical changes वास्तविकता में बड़ा फर्क ला सकते हैं। success rate 98% से 99% जाना मामूली लगता है, लेकिन failure 50 में 1 से घटकर 100 में 1 हो जाता है। यानी effect दोगुना हो गया

    • शायद यही इस लेख का मुख्य point है
    • context इस पर निर्भर करता है कि desired outcome probability के किस छोर पर है
      SPF इसका एक उदाहरण है। SPF 30 ultraviolet का 1/30, यानी 3% पास होने देता है और 29/30, यानी 97% रोकता है। SPF 50 1/50, यानी 2% पास होने देता है और 49/50, यानी 98% रोकता है। इस मामले में denominator के रूप में व्यक्त करना effect को कहीं ज़्यादा intuitive बनाता है
      SPF 30 और 50 की तुलना करना, 97% और 98% की तुलना करने से effect की बढ़ोतरी को बेहतर दिखाता है
      इसे pass-through amount के रूप में भी कह सकते हैं, लेकिन नाम Sun Protection Factor है, Sun Transparency Factor नहीं
    • कई मामलों में probability से बेहतर odds होते हैं। खासकर तब, जब probability के दोनों सिरों पर छोटे अंतर वास्तविक दुनिया में बड़े अंतर दर्शाते हों
      लेकिन कुछ मामलों में सिरों पर छोटे अंतर असल में भी छोटे ही होते हैं। खासकर expected value में ऐसा होता है। उदाहरण के लिए, 98% probability से 100 dollars मिलने और 99.9% probability से 100 dollars मिलने के मामलों को देखें
      दूसरे का expected value पहले से बस थोड़ा अधिक है। 99.9 dollars में से 98 dollars घटाने पर 1.90 dollars का फर्क है। इसके उलट odds का फर्क बहुत बड़ा है। (0.999/0.001)/(0.98/0.02)≈20.39 है। यानी 99.9% probability के odds 999-to-1 हैं और 98% probability के odds 49-to-1, इसलिए पहला 20 गुना से भी ज़्यादा है, लेकिन expected return लगभग समान है
    • आपने effect को 98 से 99 तक बढ़ाया है; वह कोई बहुत बड़ा बदलाव नहीं है। वास्तव में जो किया गया वह ineffectiveness को आधा करना है, और वह बड़ा बदलाव है

  • संबंधित लेख: Science is a strong-link problem
    https://news.ycombinator.com/item?id=35712694
    lottery जैसी चीज़ें strong-link problems हैं। system की value उसके सबसे strong link की value के बराबर होती है। food safety एक weak-link problem है। किसी meal की safety सबसे unsafe bite से निर्धारित होती है
    लेखक CSS के लिए weak-link criterion का समर्थन करते लगते हैं। यानी यह ज़्यादा महत्वपूर्ण है कि majority क्या देखती है, और एक-दो बड़ी सफलताएँ failures की भरपाई नहीं कर सकतीं

  • Meat Loaf के गाने “Two Out of Three Ain’t Bad” की याद आती है। Japan में यह 66%の誘惑 “66% is Good Enough” जैसे title से release हुआ था https://www.discogs.com/release/8303076

    • 誘惑 का अर्थ शायद “attraction, temptation, seduction” के ज्यादा करीब नहीं है?

  • मुझे लगता है समस्याएँ मोटे तौर पर दो तरह की होती हैं। वे जिनमें partial credit मिल सकता है, और वे जिनमें नहीं
    restaurant वाला उदाहरण उस तरफ है जहाँ partial credit नहीं मिलता। food का 98% safe होना काफी नहीं है; या तो सब safe है, वरना उसका कोई मतलब नहीं। employee payroll भी इसी तरह है—या तो पूरा सही, वरना बड़ा मुद्दा। salary एक बार भी miss हो जाए तो भारी समस्या बन जाती है
    लेकिन website के CSS में कुछ हद तक partial credit मिल सकता है। भले perfect न हो, theoretically कुछ value दे सकता है
    “completion” का percentage मापते समय यह जानना सच में महत्वपूर्ण है कि आप किस तरह की समस्या से निपट रहे हैं

  • मुझे वह आँकड़ा याद आता है कि अगर कुछ मनचाही चीज़ें बिकनी बंद हो जाएँ, तो ज़्यादातर ग्राहक किसी खास सुपरमार्केट में जाना छोड़ देते हैं
    किसी एक ब्रांड का chocolate spread न रखना मामूली लग सकता है, लेकिन अगर कोई ग्राहक इसी वजह से अपनी ज़रूरत की 12 और किराना चीज़ें भी उस दुकान से नहीं खरीदता, तो discontinued products कुल का सिर्फ़ 2% हैं—यह बात ज़्यादा मायने नहीं रखती। सुपरमार्केट के product assortment का स्थिर रहना इसलिए नहीं है कि कोई नए products नहीं बनाता, बल्कि इसलिए है कि छोटे प्रतिशत का बदलाव भी ग्राहकों को चिढ़ा देता है
    अगर मैं किसी website पर order नहीं कर पाता, तो मैं आगे कोशिश नहीं करता। हो सकता है अगले हफ़्ते ESR browser update होकर काम करने लगे, लेकिन तब तक मैं search results में उस link पर click करना छोड़ चुका होता हूँ

    • क्या Aldi इस theory के उलट नहीं चलता?

  • समस्या का एक हिस्सा यह है कि अमेरिकी सरकार और ब्रिटिश सरकार की websites “2% rule” इस्तेमाल करती हैं और आधिकारिक तौर पर केवल 98% को support करती हैं
    3 साल पहले कहा गया था कि Firefox का 2.2% share government websites पर support बंद होने के जोखिम के करीब पहुँच गया था, और अब यह 1.9% तक गिर चुका है
    https://news.ycombinator.com/item?id=36776603
    https://analytics.usa.gov/ के अनुसार “पिछले 30 दिनों में 1.66 अरब sessions थे।” अगर calculation सही है, तो 2% का मतलब 3.3 करोड़ sessions है

    • यही percentage-based approach की समस्या है। ज़्यादातर मामलों में top 3 implementations चुनना बेहतर होता है। Browser वाले उदाहरण में इसमें WebKit, Blink, Gecko शामिल होंगे, और लंबी tail को तो वैसे भी किसी भी approach में ignore किया जाता है, इसलिए इतना काफ़ी होने की संभावना है
    • अगर Firefox support बंद किया जाता है, तो क्या इसका मतलब Firefox को actively block करना होगा?

  • मुझे लोगों को numbers की तरह treat करना पसंद नहीं है
    98% न बहुत ज़्यादा है, न बहुत कम। यह बस गलत है
    अगर मैं उस 2% में हूँ, तो मेरे लिए वही सब कुछ है। मेरे 2% में होने की कोई जायज़ वजह भी हो सकती है। और उसे नज़रअंदाज़ करने वाला रवैया गलत हो सकता है
    मेरे हिसाब से सही वजहों से सिर्फ़ 2% लोगों के लिए काम करने वाली website, गलत वजहों से 2% लोगों के लिए काम न करने वाली website से बेहतर है