बड़ी टेक में गुणवत्ता बेचना मुश्किल है
बड़ी टेक कंपनियों में गुणवत्ता को सही ठहराना increasingly मुश्किल माना जाता है, जब अल्पकालिक growth, feature velocity, और lock-in दीर्घकालिक maintainability या user experience से अधिक महत्वपूर्ण हो जाते हैं। टिप्पणीकार software के इस “enshittification” को गलत aligned incentives, कमजोर प्रतिस्पर्धा, गुणवत्ता के खराब metrics, और ऐसी management practices से जोड़ते हैं जो durable, well-tested systems बनाने की बजाय जल्दी ship करने को इनाम देती हैं। कुछ लोग मानते हैं कि open source, मजबूत प्रतिस्पर्धा, या mission-driven cultures इस प्रवृत्ति को रोक सकते हैं, लेकिन यह भी नोट करते हैं कि high quality महंगी होती है, मापना कठिन है, और अक्सर तभी मूल्यवान लगती है जब उसकी कमी catastrophic हो जाए।
“गुणवत्ता” का स्वभाव और सरलता
- कई लोग तर्क देते हैं कि गुणवत्तापूर्ण कोड आमतौर पर सरल/कम उलझा हुआ होता है, लेकिन यह भी नोट करते हैं कि कई डोमेन में अपरिवर्तनीय जटिलता होती है।
- “जटिल” (आवश्यक) और “उलझा हुआ” (क्रफ्ट, परतें, वर्कअराउंड) के बीच भेद किया जाता है।
- कुछ के लिए गुणवत्ता का मतलब मॉड्यूलरिटी है ताकि जूनियर लोग छोटे हिस्सों के बारे में तर्क कर सकें; अन्य लोग कहते हैं कि “गुणवत्ता” व्यक्तिपरक है और इस पर तीखी बहस होती है (APIs, architectures, languages, tests)।
प्रोत्साहन, प्रतिस्पर्धा, और एंशिटिफिकेशन
- कई लोग गुणवत्ता में गिरावट को मोनोपॉली/लॉक‑इन से जोड़ते हैं: एक बार उपयोगकर्ता पकड़ में आ जाते हैं, तो ROI विकास, विज्ञापनों, और “moats” को सुधार से ऊपर रखता है।
- अन्य इसे सामान्य पूंजीवाद/अल्पकालिक सोच के रूप में देखते हैं: लगभग हर उद्योग में निकट-कालीन राजस्व को अधिकतम करना दीर्घ-कालीन उत्पाद स्वास्थ्य से बेहतर माना जाता है।
- विरोधी पक्ष: गैर-पूंजीवादी प्रणालियों में भी खराब गुणवत्ता मौजूद थी; उपयोगकर्ता “काफी अच्छा” सस्ता सॉफ़्टवेयर सह लेते हैं।
- कुछ लोग ओपन सोर्स को दीर्घ-कालिक उत्तर मानते हैं: इन्फ्रास्ट्रक्चर को कमोडिटी बनाओ; बड़ा पैसा नेटवर्क-इफ़ेक्ट मोनोपोलियों में बैठा है।
टेस्टिंग, QA, और इंजीनियरिंग प्रैक्टिस
- कई टिप्पणियाँ QA के समाप्त होने या कमजोर होने पर अफसोस जताती हैं; डेवलपर्स “मानो” टेस्ट करने चाहिए लेकिन आम तौर पर नहीं करते, और उनके लिए प्रोत्साहन भी नहीं होता।
- गुणवत्ता के प्रयास अक्सर नीचे से, परवाह करने वाले इंजीनियरों से आते हैं; ऊपर से दबाव तभी काम करता है जब नेतृत्व उन्हें स्पष्ट रूप से प्राथमिकता दे और शेड्यूल पर पड़ने वाले असर को स्वीकार करे।
- टेस्टेबिलिटी और रिफैक्टरिंग को शुरुआती तौर पर महंगा लेकिन टेक-डेट तबाहियों और री-राइट्स से सस्ता माना जाता है।
मैनेजमेंट, प्रोडक्ट, और संगठनात्मक गतिशीलता
- प्रोडक्ट मैनेजरों की आलोचना की जाती है कि उनमें तकनीकी गहराई नहीं होती और वे तकनीकी निर्णयों को requirements के रूप में छिपा देते हैं।
- फीचर चर्न और प्रेस का ध्यान खींचने के लिए “रीब्रांडिंग” को परिपक्व उत्पादों को खराब करने का कारण माना जाता है।
- परफ़ॉर्मेंस सिस्टम (छोटे review cycles, stack ranking, KPI obsession) दृश्य फीचर्स को अदृश्य गुणवत्ता या रोकथाम वाले काम से ऊपर इनाम देते हैं।
- रिज़्यूमे-ड्रिवन डेवलपमेंट और छोटी नौकरी-अवधियाँ दीर्घकालिक देखभाल को हतोत्साहित करती हैं।
गुणवत्ता को मापना और उसके लिए भुगतान करना
- गुणवत्ता बेचना मुश्किल है क्योंकि इसे मापना कठिन है; लाभ भविष्य की टाली गई लागतों और कम churn के रूप में सामने आते हैं।
- लोग “technical debt” को एक संप्रेषणीय रूपक के रूप में इस्तेमाल करते हैं; इसी तरह का “product debt” प्रस्तावित किया जाता है।
- कुछ लोग कहते हैं “गुणवत्ता महंगी है,” जबकि अन्य कहते हैं कि गुणवत्ता की कमी समय के साथ और महंगी पड़ती है; सर्वोत्तम बिंदु “good enough” है, न कि पूर्णता।
“Enshittification” शब्द पर बहस
- एक उप-चर्चा स्वयं इस शब्द पर बहस करती है: कुछ इसे सजीव और सटीक मानते हैं; अन्य इसे cringe, असंगत, या मुख्यधारा/शैक्षणिक उपयोग के लिए अशिष्ट मानते हैं।
- सुझाए गए विकल्पों में “platform decay,” “management decay,” “rent seeking,” और “platform arson” शामिल हैं, और इस पर असहमति है कि क्या वे इरादतनता और भावनात्मक तीव्रता को पकड़ते हैं।