उपयोगकर्ता परवाह नहीं करते — लेकिन आपको करनी चाहिए

• उपयोगकर्ता कोड की अपनी अंतर्निहित विशेषताओं से ज़्यादा इस बात की परवाह करते हैं कि प्रोडक्ट काम करता है या नहीं, लेकिन खराब कोड का performance·bug·development speed पर सीधा डाउनस्ट्रीम असर पड़ता है
• “उपयोगकर्ता tech stack या testing की परवाह नहीं करते” जैसी बात सतही तौर पर सही लग सकती है, लेकिन कोड quality जितनी खराब होगी, bug fix और feature addition उतने ही कठिन और धीमे हो जाते हैं
• पुल निरीक्षण, नशे में पायलट, और इमारत की अस्थिर नींव जैसी उपमाओं की तरह, भले उपयोगकर्ता प्रक्रिया को खुद न देखें, उसका नतीजा सुरक्षा और भरोसे को प्रभावित करता है
• AirBnB, OpenAI, Meta जैसी कंपनियाँ बाज़ार पर पकड़, भारी VC समर्थन, और संदिग्ध वैधता के सहारे इन समस्याओं को धकेल सकती हैं, लेकिन हर कंपनी ऐसी स्थिति में नहीं होती
• सॉफ़्टवेयर की सफलता sales, tech stack, user experience, और unique identifiers तक फैली कई तरह की चिंताओं और दृष्टिकोणों के संयुक्त असर का परिणाम होती है

---

बार-बार दोहराए जाने वाले क्लिशे और उनकी सीमाएँ

• सॉफ़्टवेयर उद्योग में अक्सर ऐसी बातें दोहराई जाती हैं: “ग्राहक testing की परवाह नहीं करते, वे सिर्फ़ यह देखते हैं कि प्रोडक्ट काम करता है या नहीं”, “उपयोगकर्ता tech stack की परवाह नहीं करते”, “engineering elegance बाज़ार मूल्य के बराबर नहीं है”, “उपयोगकर्ता को इससे फर्क नहीं पड़ता कि इसे AI ने लिखा है या इंसान ने, या कौन-सा framework इस्तेमाल हुआ है; उन्हें बस प्रोडक्ट के काम करने से मतलब है”
• ये सभी कथन मूलतः एक ही थीम के रूप हैं: “ग्राहक को उसकी परवाह नहीं है”, और इन्हें अक्सर कठोर यथार्थ बताने वाले pragmatism की तरह पेश किया जाता है
• यही तर्क जब दूसरे क्षेत्रों में लगाया जाता है, तो इसकी सतहीपन साफ़ दिखने लगती है
  • जैसे कहना कि सड़क उपयोगकर्ता पुल के अंतिम निरीक्षण की परवाह नहीं करते, उन्हें बस इतना चाहिए कि पुल उनकी कार का भार संभाल ले
  • या यह कहना कि यात्रियों को इस बात की परवाह नहीं कि पायलट ने शराब पी रखी है या नहीं; उन्हें बस विमान का समय पर पहुँचना चाहिए
  • या यह कहना कि दफ़्तर में काम करने वालों को ऊँची इमारत की नींव की स्थिरता से मतलब नहीं; उन्हें बस पैसा कमाना है
• ये उपमाएँ ऊपर से सही लग सकती हैं, लेकिन वे स्पष्ट downstream effects को नज़रअंदाज़ करती हैं
• यह सही है कि ग्राहक कंप्यूटर कोड के अंतर्निहित गुणों में रुचि नहीं रखते, लेकिन कोड quality performance, bug की मौजूदगी, bug fix में लगने वाले समय, और feature जोड़ने में लगने वाले समय को प्रभावित करती है
• कोड जितना खराब होगा, इन समस्याओं को हल करना उतना ही कठिन और धीमा होगा
• इसमें यह भी इशारा है कि AirBnB, OpenAI, Meta जैसी कंपनियाँ अपनी भारी market power, विशाल VC समर्थन, और संदिग्ध वैधता के बल पर इन चिंताओं को दबा सकती हैं
• निष्कर्ष यह है कि अगर आपकी कंपनी ऐसी नहीं है, तो आप इन्हीं तरीकों से समस्याओं को ढक नहीं सकते

‘लोक-ज्ञान’ की टिकाऊपन और सॉफ़्टवेयर की अनेक चिंताएँ

• लोक-ज्ञान की टिकाऊपन

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

• हम समाज के भीतर हैं

  • गंभीर सॉफ़्टवेयर कार्य अलग-अलग चिंताओं और अलग-अलग दृष्टिकोणों का मिश्रण होता है
  • technical sales से tech stack तक, user experience से unique identifiers तक, सॉफ़्टवेयर प्रयास में कई प्रकार के तत्व शामिल होते हैं
  • ये सभी तत्व मिलकर सफलता या विफलता में योगदान देते हैं

[GN⁺]

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 हैं कि यह जाना जा सके कि हम सचमुच वहाँ पहुँचे भी हैं या नहीं