क्या सॉफ़्टवेयर बदतर हो रहा है?
कई engineers का तर्क है कि रोज़मर्रा का software विशाल hardware gains के बावजूद अधिक धीमा, अधिक bug-prone, और अधिक bloated महसूस होता है, और वे इसका कारण उन incentives को मानते हैं जो efficiency और reliability की बजाय तेज़ feature shipping, ad-driven “free” apps, और disposable, web-based tooling को reward करते हैं। दूसरे इसका जवाब देते हैं कि floppy disk era के बाद से overall reliability और capabilities काफ़ी बेहतर हुई हैं, क्योंकि robust operating systems, security advances, और mature tools उपलब्ध हैं, और यह कि globalization, accessibility, sync, media, security जैसी आधुनिक आवश्यकताएँ स्वाभाविक रूप से overhead जोड़ती हैं। दोनों दृष्टिकोणों में एक common theme है: markets और management visible features और growth को optimize करते हैं, जबकि performance, simplicity, और long-term maintainability तब तक undervalued रहती हैं जब तक failures या user frustration को नज़रअंदाज़ करना बहुत महँगा न हो जाए।
क्या सॉफ़्टवेयर बदतर हो रहा है? (समग्र भावना)
- कई लोग “हाँ” कहते हैं: ज़्यादा bloat, तेज़ hardware के बावजूद धीमे apps, अधूरे “permanent beta” releases, और असम्मानजनक व्यवहार (tracking, ads, forced changes)।
- दूसरे कहते हैं “वास्तव में नहीं”: 80s/90s में crashes और OS instability ज़्यादा खराब थे; आधुनिक systems, compilers, और tools अधिक robust और accessible हैं।
- कई लोग नोट करते हैं कि नया software अक्सर खराब होता है, जबकि लंबे समय से चल रही projects (OS kernels, compilers, major apps) लगातार बेहतर हुई हैं।
Performance, Bloat, और Resource Use
- chat/email clients (Slack, Teams) के बारे में बार-बार शिकायतें आती हैं कि वे सिर्फ़ text और images दिखाने के लिए gigabytes of RAM और भारी CPU इस्तेमाल करते हैं।
- कुछ लोग modern chat tools का बचाव करते हैं क्योंकि वे वास्तव में अधिक complex हैं (history sync, media, threading, moderation, APIs, globalization, accessibility)।
- दूसरे कहते हैं कि इससे मौजूदा performance को सही नहीं ठहराया जा सकता; पुराने clients (AIM/ICQ/MSN/IRC) बहुत कम resource footprint के साथ समान functionality देते थे।
- Resource abundance (RAM, CPU, bandwidth) को sloppy design को बढ़ावा देने वाला माना जाता है; कुछ teams inefficiencies को शुरू में पकड़ने के लिए जानबूझकर dev environments को constrain करती हैं।
Economics, Incentives, और “Quality”
- एक मज़बूत थीम: organizations feature delivery और growth को reward करती हैं, speed, reliability, या resource efficiency को नहीं।
- PMs और management अक्सर refactoring या performance work की तुलना में visible features (और resume bullets) को प्राथमिकता देते हैं।
- Users शायद ही कभी software को efficiency के आधार पर चुनते हैं; वे ज़रूरी features वाले “good enough” tools चुनते हैं, या जो IT mandate करे।
- Free/ad‑supported models और “attention harvesting” surveillance, tracking, और engagement की ओर धकेलते हैं, craftsmanship की बजाय।
- कई लोग नोट करते हैं कि “quality” multi-dimensional है (performance, reliability, UX, features, privacy) और बहुत subjective है।
Complexity, Security, और Distribution
- Platforms और stacks अधिक complex हो गए हैं: web apps, app stores, multiple device types, localization, accessibility, security layers.
- Security hardening और global text support overhead जोड़ते हैं, लेकिन इन्हें ज़रूरी tradeoffs माना जाता है।
- Internet distribution ने incentives बदल दिए: patches ship करना सस्ता हो गया, इसलिए 1.0 releases CD/floppy era की तुलना में बहुत अधिक buggy हो सकते हैं, जब support और patch distribution महँगे थे।
Nostalgia बनाम वास्तविक Regression
- कुछ लोग nostalgia और selection bias देखते हैं: हम पुराने tools में सबसे अच्छे tools याद रखते हैं, खराब ones भूल जाते हैं।
- दूसरे concrete regressions की ओर इशारा करते हैं: पहले lean tools (जैसे lightweight clients, छोटे utilities) का bloated, subscription-tied, या ad-ridden बन जाना।
- व्यापक सहमति: अधिकांश software हमेशा से mediocre रहा है; जो बदला है वह scale, incentives, और यह है कि bloat कितना visible हो गया है।