मेरा एक सिद्धांत है कि सॉफ्टवेयर लोगों को पागल बना देता है

हाथ धोने वाला साइड-ट्रैक और “संज्ञान” का आधार

• थ्रेड की शुरुआत इस बहस से होती है कि क्या आज बार-बार हाथ धोना “पागलपन” है।
• कई लोग बताते हैं कि महामारी के बाद वे ज़्यादा हाथ धोते हैं और कम बीमार महसूस करते हैं।
• शारीरिक हस्तक्षेपों पर Cochrane review का हवाला दिया गया है: हाथ स्वच्छता से मामूली लेकिन अनिश्चित लाभ; कम अनुपालन से परिणाम कमज़ोर होते हैं; मास्किंग के प्रमाण भी अनिश्चित हैं।
• कुछ लोग HN पर पहले हुए उन तर्कों को याद करते हैं कि “गंदे हाथ” लाभदायक हो सकते हैं।
• कुछ का कहना है कि ऐसी आदतों से sanity का आकलन करना दिखाता है कि लेख एक कमज़ोर premise से शुरू होता है।

डेवलपर, उपयोगकर्ता, और संगठनात्मक संरचना

• बहुतों का तर्क है कि समस्या सॉफ्टवेयर नहीं, बल्कि उसे उपयोगकर्ताओं से अलग-थलग बनाना है जो लोगों को “पागल” करता है।
• ग्राहकों से सीधे, नियमित संपर्क में रहना (जिसमें first-level support करना भी शामिल है) ज़मीन से जोड़े रखने वाला और स्पष्ट करने वाला माना गया है।
• जब संचार केवल project/product managers के ज़रिए होता है, तो requirements विकृत हो जाती हैं, प्राथमिकताएँ राजनीति बन जाती हैं, और devs वास्तविक समस्याओं से दूर हो जाते हैं।
• कुछ कहते हैं कि devs खुद भी अक्सर user contact का विरोध करते हैं, उसे distraction मानते हैं; दूसरे इसे unprofessional कहते हैं, लेकिन misaligned incentives (performance का ticket throughput से जुड़ा होना) भी नोट करते हैं।

Analytics बनाम usability और feature decisions

• context के बिना analytics पर भारी निर्भरता की आलोचना की गई।
• आम पैटर्न: कम इस्तेमाल होने वाली features को raw usage counts के आधार पर हटाना, जबकि critical-but-infrequent workflows और discoverability issues को नज़रअंदाज़ कर देना।
• उदाहरण: ब्राउज़र के “close tabs to the right” विकल्प को कम click rates के आधार पर हटाना; टिप्पणीकारों का तर्क है कि कम frequency का मतलब कम importance नहीं।
• Management कभी-कभी cuts को justify करने के लिए डेटा “manufacture” करती है (पहले features को दफनाना)।
• usability research और लोगों को interfaces के साथ जूझते हुए देखना बार-बार analytics से निकली hypotheses को गलत साबित करता है।

Dogfooding, सहानुभूति, और उनकी सीमाएँ

• अपने ही software का इस्तेमाल करना संज्ञान से बचने और friction जल्दी पकड़ने का एक शक्तिशाली तरीका बताया गया।
• इसे बेहतर accessibility और अधिक भरोसेमंद, low-friction workflows से जोड़ा गया।
• हालांकि, dogfooding तब भटका सकता है जब डेवलपर product को संकीर्ण, expert तरीकों से इस्तेमाल करते हैं जो सामान्य users से मेल नहीं खाते।

Tech churn, जटिलता, और industry culture

• कई लोग पुराने छोटे, focused teams की तुलना आज की बड़ी teams से करते हैं, जो ज़रूरत से ज़्यादा engineered CRUD apps ship करती हैं।
• tech churn और bloated toolchains को बर्बाद मेहनत और cognitive overload का कारण बताया गया, जिससे “पागलपन” बढ़ता है।
• कुछ का कहना है कि असली चालक पैसा और प्रतिस्पर्धी hype है: हर चीज़ को “platform” या “data company” होना चाहिए, इसलिए साधारण products को भी world-changing के रूप में पेश किया जाता है।

सॉफ्टवेयर की प्रकृति और अपेक्षाएँ

• सॉफ्टवेयर की अमूर्तता और बदली जा सकने वाली प्रकृति लगातार बदलाव को बढ़ावा देती है; बदलाव की लागत कम लगती है, इसलिए हर चीज़ urgent बन जाती है।
• उपयोगकर्ता अक्सर software output को authoritative और भरोसेमंद मानते हैं; जब bugs या propagation delays दिखते हैं, तो वे disproportionate anxiety महसूस करते हैं।
• कुछ लोग software को uniquely ये सब पैदा करने वाला नहीं, बल्कि पहले से मौजूद मानवीय ego, delusion, और corporate dysfunction को उजागर करने वाला मानते हैं।

लेख की प्रतिक्रिया

• बहुतों को यह पोस्ट relatable और मज़ेदार लगी, जिसने industry की असल dysfunction को पकड़ लिया।
• दूसरों को यह भटकावपूर्ण, कम संरचित, और बहुत लंबी लगी, जिसमें केंद्रीय thesis कमज़ोर या धुंधली थी।