यूज़र परवाह नहीं करते — लेकिन आपको करनी चाहिए

 (lewiscampbell.tech)
6 पॉइंट द्वारा GN⁺ 2026-06-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यूज़र को कोड की अपनी अंतर्निहित विशेषताओं से ज़्यादा इस बात की परवाह होती है कि प्रोडक्ट काम करे, लेकिन खराब कोड का performance, bugs, और development speed पर सीधा downstream असर पड़ता है
  • “यूज़र tech stack या testing की परवाह नहीं करते” जैसी बात ऊपर-ऊपर से सही लग सकती है, लेकिन code quality जितनी खराब होगी, bug fix और feature addition उतने ही कठिन और धीमे हो जाएंगे
  • पुल की जाँच, नशे में पायलट, और अस्थिर इमारत की नींव जैसी उपमाओं की तरह, भले ही यूज़र प्रक्रिया को खुद न देखें, उसके नतीजे सुरक्षा और भरोसे को प्रभावित करते हैं
  • ऐसी धारणाएँ लोकप्रिय होने के पीछे यह ego defence mechanism काम कर सकता है कि लोग जिस चीज़ में अच्छे नहीं होते, उसका महत्व कम करके दिखाएँ
  • गंभीर software work कई तरह की प्राथमिकताओं और नज़रियों का मिश्रण है, और वे सभी सफलता या विफलता में योगदान देते हैं, इसलिए code quality को हल्के में नहीं लेना चाहिए

बार-बार दोहराया जाने वाला cliché और उसकी सीमाएँ

  • software industry में अक्सर इस तरह की बातें दोहराई जाती हैं:
    • “customers testing की परवाह नहीं करते, उन्हें सिर्फ़ यह चाहिए कि प्रोडक्ट काम करे”
    • “यूज़र tech stack की परवाह नहीं करते”
    • “engineering elegance बाज़ार मूल्य के बराबर नहीं होती”
    • “यूज़र को इससे फ़र्क नहीं पड़ता कि इसे AI ने लिखा है या इंसान ने, या कौन-सा framework इस्तेमाल हुआ है; उन्हें सिर्फ़ यह चाहिए कि प्रोडक्ट काम करे”
  • ये सब असल में एक ही थीम के रूप हैं: “customers इसकी परवाह नहीं करते”
  • इसे अक्सर ऐसे पेश किया जाता है, जैसे कोई अनुभवी व्यवहारवादी आदर्शवादी या अल्पदृष्टि लोगों को दुनिया की कठोर सच्चाई बता रहा हो
  • लेकिन यह सब पूरी तरह बकवास (horseshit) है, और
    जब यही तर्क दूसरे क्षेत्रों में लागू किया जाता है, तो इसकी कमज़ोरियाँ साफ़ दिखने लगती हैं
    • सड़क उपयोगकर्ताओं को इससे फ़र्क नहीं पड़ता कि पुल का final inspection हुआ या नहीं, उन्हें सिर्फ़ यह चाहिए कि पुल गाड़ियों का भार संभाले
    • यात्रियों को इससे फ़र्क नहीं पड़ता कि पायलट नशे में है या नहीं, उन्हें सिर्फ़ यह चाहिए कि विमान समय पर पहुँचे
    • दफ़्तर में काम करने वालों को इससे फ़र्क नहीं पड़ता कि ऊँची इमारत की foundation stable है या नहीं, उन्हें सिर्फ़ पैसे कमाने की परवाह है
  • ये उपमाएँ सतह पर सही लग सकती हैं, लेकिन ये साफ़ तौर पर मौजूद downstream effects को नज़रअंदाज़ करती हैं

नज़रअंदाज़ किए गए downstream effects

  • यह सही है कि customers को computer code की अंतर्निहित विशेषताओं में रुचि नहीं होती, लेकिन
    code quality का असर performance, bugs की मौजूदगी, bug fix में लगने वाला समय, और features जोड़ने में लगने वाला समय पर पड़ता है
  • कोड जितना खराब होगा, इन समस्याओं को हल करना उतना ही कठिन और धीमा होगा
  • AirBnB, OpenAI, और Meta जैसी कंपनियाँ भारी market dominance, विशाल VC backing, और संदिग्ध वैधता के सहारे इन चिंताओं को दबा सकती हैं
    लेकिन अगर आप ऐसी कंपनी नहीं हैं, तो इसी तरह समस्याओं पर परदा डालना मुश्किल है

‘Folk Wisdom’ की स्थायित्व और software की अनेक प्राथमिकताएँ

  • प्रचलित धारणाओं की ज़िद्दी उम्र (The Persistence of Folk Wisdom)

    • केवल first-order effects को महत्वपूर्ण मानने वाली सोच software में एक बेहद लोकप्रिय लोकधारणा बन चुकी है
    • लोग अक्सर उस चीज़ का महत्व घटाकर देखते हैं, जिसमें वे अच्छे नहीं होते
    • अगर किसी को लगे कि उसमें अच्छा कोड लिखने की क्षमता की कमी है, तो उसके लिए यह मान लेना आसान हो जाता है कि अच्छा कोड महत्वपूर्ण नहीं है, बल्कि जो लोग अच्छा कोड लिख सकते हैं, वही समस्या हैं
    • ऐसे नज़रिए में वे लोग समस्या लगते हैं जो उन चीज़ों के कारण release रोकते हैं जिनकी customers परवाह नहीं करते
    • यह रवैया अपनी कमज़ोरी से बचने और ज़िम्मेदारी दूसरों पर डालने वाले ego defence mechanism की तरह काम करता है

  • हम समाज में रहते हैं (We Live in a Society)

    • गंभीर software work, अलग-अलग प्राथमिकताओं और अलग-अलग नज़रियों का मिश्रण होता है
    • tech sales से लेकर tech stack तक, user experience (UX) से लेकर unique identifiers तक, software effort में कई तरह के तत्व शामिल होते हैं
    • ये सभी तत्व सफलता या विफलता में योगदान देते हैं

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

1 टिप्पणियां

 
GN⁺ 2026-06-08
Lobste.rs की राय

  • ऐसे वाक्य जिस तरह बात पहुँचाते हैं, और जिस तरह पढ़े जाते हैं, दोनों ही अच्छे या बुरे हो सकते हैं
    उदाहरण के लिए, “ग्राहक को testing से बिल्कुल मतलब नहीं है। उसे इस बात से मतलब है कि product काम करता है या नहीं” को “buggy चीज़ ship कर दो” की तरह नहीं, बल्कि किसी खास testing ideology से ज़्यादा इस बात पर ध्यान दो कि product सच में काम करे के अर्थ में पढ़ा जा सकता है
    क्योंकि testing, code को काम करने लायक बनाने के साधनों में से सिर्फ एक है, इसलिए test coverage ऊँचा हो और सब pass भी हो जाएँ, फिर भी अगर product काम न करे तो वह असफलता है; और testing के अलावा किसी दूसरे तरीके से product को अच्छी तरह काम करने लायक बना दिया जाए, तो वह भी ठीक है; औपचारिक doctrine का पालन न करते हुए भी अगर bugs अच्छी तरह पकड़े जाएँ, तो उसे भी स्वीकार्य माना जा सकता है
    साथ ही user और business के नज़रिए से “product/feature का मौजूद न होना” भी bug हो सकता है, इसलिए existing bugs को fix करना और features release करना हमेशा साफ़-साफ़ अलग चीज़ें नहीं होतीं
    लेकिन हक़ीक़त में ऐसे वाक्य कभी-कभी “शॉर्टकट मारो और कचरा release करो” के मतलब में भी इस्तेमाल होते हैं, यह भी सुना है

    • “user और business के नज़रिए से product/feature का मौजूद न होना भी bug है” इस बिंदु पर, लेखक के रूप में मैं एक बात साफ़ तौर पर नहीं कह पाया
      घटिया programming को मैं यह सोचकर बिल्कुल स्वीकार नहीं करता कि वह महीनों के हिसाब से भी “practical” है
      खराब design और कम testing वाले codebase में नई features बनाना धीमा और महँगा होता है
    • बहुत से engineer ऐसे भी होते हैं जो मानते हैं कि “जितने ज़्यादा unit tests, उतना अच्छा”, या फिर ऐसे code को भी कई दिनों तक optimize करते रहते हैं जो bottleneck ही नहीं है; ऐसे मामलों में ऊपर वाली व्याख्याएँ काफ़ी सही बैठती हैं
      developers को इस बात का ध्यान रखना चाहिए कि वे अपना समय वहाँ लगा रहे हैं जहाँ value बनती है या नहीं, और ideal स्थिति यह होगी कि management भी समझे कि ऐसा काम क्यों किया जा रहा है
      समझ की कमी और ग़लत incentive structure मिल जाएँ, तो आख़िरकार वही होता है: “शॉर्टकट मारो और कचरा release करो”

  • सच कहूँ तो ऐसी बातें कहने वाले लोग अक्सर ऐसे लगते हैं जैसे उन्हें users की भी ज़्यादा परवाह नहीं है
    users तक working product पहुँचाने के लिए development process के भीतर ऐसे तंत्र होने चाहिए जो उस संभावना को बढ़ाएँ—यह बात मैं कुछ दिन पहले की एक टिप्पणी में भी कह चुका हूँ
    इस तरह की भावना अक्सर वहाँ दिखती है जहाँ users के पास product पर सही feedback देने का कोई तरीका नहीं होता, और असली usage metrics भी मौजूद नहीं होते
    ऐसी बहुत-सी failure scenarios होती हैं जिनका असर users पर पड़ता है, भले ही वे उन्हें तुरंत देखें या उनकी परवाह करें या नहीं
    सबसे बड़ा उदाहरण security है: user “unsafe” होने की चिंता तब तक न करे जब तक उसका data किसी online leak में न पहुँच जाए; और performance भी उसे तब तक समस्या न लगे जब तक उसे पता न चले कि यह इससे काफ़ी बेहतर हो सकती थी

    • ऐसे विषयों को आम audience को समझाना मुश्किल होता है
      किसी भी improvement process में सिर्फ एक तत्व चुनकर उसे optimize करने से अच्छा नतीजा पाना मुश्किल है, लेकिन discussion में प्रगति लाने के लिए कई बार ऐसा करना पड़ता है
      इसलिए feedback के रास्तों को इस तरह align करते हुए चर्चा को ठीक करना मददगार होता है कि असल दिखाई देने वाली समस्या कहाँ है
      मैं ऐसे लेखों को software project की सफलता को प्रभावित करने वाले, लेकिन एक-दूसरे के विरोधी दिखने वाले तत्वों के बारे में सोचने की कोशिश के रूप में देखता हूँ
      उन बातों को शब्दों में समझाना और उनके पक्ष में तर्क देना, जिन्हें सिर्फ technical sense वाले लोग सहज रूप से समझते हैं, क़ीमती है; लेकिन लगता है कि बहुत से technologists दिखाई न देने वाले काम का संतुलन बनाने या उसे असरदार ढंग से समझाने में सफल नहीं होते, और मैं भी उस हिस्से का अभ्यास करता जा रहा हूँ

  • अंदरूनी चीज़ों की परवाह करना महत्वपूर्ण है, और उससे सच में users को भी फ़ायदा होता है

  • मुझे यह नज़रिया पसंद है
    मैं दूसरी चरम सीमा, यानी over-engineering की तरफ़ नहीं जाना चाहता, लेकिन “move fast and break things” वाली सोच से बाहर निकलना चाहिए
    मेरे अनुभव में web development की दुनिया में यह लगभग किसी महामारी जैसा है
    उम्मीद है कि LLM की वजह से आए low-quality software के सैलाब से उल्टा users reliable software को reward करना शुरू करें
    मैं धीरे-धीरे grug brain developer बनता जा रहा हूँ, इसलिए नहीं पता यह भावना कितनी आम है, लेकिन “चलो एक feature और जोड़ते हैं” से थक चुका हूँ
    हम अक्सर software की लागत को सिर्फ release date से मापने की गलती करते हैं, और उसकी पूरी life cycle में आने वाली maintenance cost को लगभग शामिल ही नहीं करते
    “मुश्किल नहीं है, एक हफ़्ते से भी कम लगेगा!” कह दिया जाता है, लेकिन हर साल maintenance, fixes, expansion, updates, integration और documentation पर लगने वाले 2~4 हफ़्तों का ज़िक्र नहीं किया जाता

  • मैं अक्सर इसी तरह की बात कहता हूँ
    “end users को इस बात से फ़र्क़ नहीं पड़ता कि software की test coverage 100% है या नहीं, या वह lbl0 जैसे labels वाले बिना documentation के assembly में 100% लिखा गया है या नहीं। उन्हें correctness, performance और user experience की परवाह होती है”
    लेकिन software engineering वही चीज़ है जो उन लक्ष्यों तक ज़्यादा आसानी से पहुँचने और quality को अच्छे स्तर पर बनाए रखने में मदद करती है
    समस्या यह है कि यही रास्ता cargo cult और over-engineering तक भी ले जा सकता है, और मैं ख़ुद भी निश्चित रूप से इस गुनाह का हिस्सा रहा हूँ
    फिर भी आख़िरकार users तक वास्तविक value पहुँचनी चाहिए

  • Boeing और Airbus की तरह, यहाँ भी साबित किए जा सकने वाले optimal results मौजूद होते हैं
    दोनों कंपनियों के aircraft इतने एक जैसे क्यों दिखते हैं, किसने पहले design किया और किसने किससे “चुराया”, यह असली मुद्दा नहीं है
    किसी ने किसी से नहीं चुराया; दुनिया के बेहतरीन engineer अलग-अलग teams में, एक ही constraints के भीतर design कर रहे थे, इसलिए जो design उनसे हटे, वे परिभाषा के हिसाब से inferior हो जाते हैं
    आपको Pareto frontier पर होना चाहिए, नहीं तो आप बाहर हो जाएँगे
    हमारे क्षेत्र में भी कहीं न कहीं एक optimal point मौजूद है; सवाल यह है कि वहाँ तक पहुँचने के tools, budget और सही लोग हैं या नहीं, और क्या इतने users हैं कि यह जाना जा सके कि हम सचमुच वहाँ पहुँचे भी हैं या नहीं