- अगर software optimization को सच में प्राथमिकता दी जाए, तो उम्मीद से कहीं ज़्यादा systems पुराने hardware पर भी चल सकते हैं
- दुर्लभ computing resources पर market price signals काम करें, तो ज़्यादा efficient software बनाने का दबाव बढ़ता है
- interpreted languages और microservices आधारित products को monolithic native codebase के रूप में दोबारा बनाना इसका एक उदाहरण हो सकता है
- लेकिन अगर बेहद सस्ती और high-scale computing उपलब्ध न हो, तो innovative new products को experiment करके launch करना कहीं ज़्यादा दुर्लभ हो सकता है
- केवल performance optimization काफी नहीं है; सस्ती और scalable computing ही product experimentation और launch frequency को तय करती है
Optimization-first वाला thought experiment
- अगर software optimization सच में प्राथमिकता हो, तो उम्मीद से ज़्यादा systems पुराने hardware पर भी चलाए जा सकते हैं
- दुर्लभ computing resources पर price signals मज़बूती से काम करें, तो market ज़्यादा efficient software की मांग करेगा
संभावित implementation तरीके और सीमाएँ
- एक उदाहरण interpreted languages और microservices-based products को monolithic native codebase के रूप में दोबारा बनाना है
- हालांकि, बेहद सस्ती और high-scale computing न हो तो innovative new products कहीं ज़्यादा दुर्लभ हो सकते हैं
1 टिप्पणियां
Hacker News की राय
यह तर्क दिया जा सकता है कि बाज़ार बग्स से भरे और अक्षम software को भी उतनी ही अच्छी तरह खरीदता है जितना अच्छे से बने software को, और दोनों में से एक सबसे सस्ता software है जिसे बनाया जा सकता है
यह “lemons market” वाली बात जैसा है। बाज़ार हर सामान को ऐसे बेचता है जैसे वह high-quality हो, लेकिन marginal cost घटाने के लिए चुपचाप quality कम कर देता है। खरीदार खरीदने से पहले high-quality और low-quality में फर्क नहीं कर पाता, इसलिए demand कृत्रिम रूप से समान हो जाती है, और वजह information asymmetry है
AI में यह पहले से हो रहा है और आगे और बढ़ेगा। users एक sophisticated machine learning app और washing machine के spin cycle को AI कहे जाने में फर्क नहीं कर पाते। AI label खुद price premium पैदा करता है, और users washing machine के लिए बहुत ज़्यादा भुगतान कर देते हैं
खराब software के लिए भी जरूरत से ज्यादा भुगतान करना, यह मानकर कि उसे engineers और experts ने design और लिखा है, मूल रूप से वही बात है। software का 99% IC1~3 लिखते हैं, और ज्यादातर tech companies में QA का एक व्यक्ति “acceptance criteria met” से आगे quality बढ़ाने का इकलौता mechanism होता है। कभी-कभी interns का झुंड “LGTM” मंत्र बोल देता है, लेकिन वह भी दुर्लभ है
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
मुझे पूरा यकीन था कि बेहतर product होगा तो लोगों को convince करेगा और virally grow करेगा, लेकिन ऐसा नहीं हुआ। growth हुई, पर इतनी धीमी कि break-even तक पहुंचने से पहले कुछ सालों में funding खत्म हो गई
समझ यह आया कि competitive market में low cost, और इसलिए low quality, competitive advantage है। product का scale जितना बड़ा होता है, cost cutting का pressure भी उतना बढ़ता है, और लोग सस्ता चाहते हैं, इसलिए कोई न कोई “cost”, यानी quality, काटकर उसे सस्ता बना देता है। company जीवित रहने और profit कमाने के लिए जितना न्यूनतम जरूरी हो, सिर्फ उतना ही खर्च करती है
young company high-quality बनाने की कोशिश कर सकती है या थोड़े समय के लिए खर्च बढ़ा सकती है, लेकिन आखिरकार stable mediocrity की ओर फिसलने वाली धारा बन जाती है। यह lemons market से थोड़ा अलग है, और market collapse के बजाय हर जगह mediocrity में बदलता दिखता है
लेकिन average व्यक्ति से Slack और तेज़ IRC client Weechat में से चुनने को कहें, तो वह terminal-style UI, video calls नहीं, webhook integration नहीं, custom avatars या emoji नहीं—इन सबको low quality मान सकता है
performance भी एक feature है। Internet Explorer के Chrome से पिछड़ने की बड़ी वजह भी यह थी कि launch के समय Chrome बहुत तेज़ था, और Python developers का uv/ruff की ओर तेजी से जाना भी performance improvement की वजह से है। हालांकि Slack के चलने में 10ms की जगह 5 seconds लगने के स्तर पर पहुंच जाए, तो बहुत कम लोग परवाह करते हैं
bug-heavy software में ऐसा हो भी सकता है, लेकिन आम तौर पर लोग कम भुगतान करना चाहते हैं और उस प्रक्रिया में कुछ bugs सहन कर लेते हैं। सोचिए कि अगर हर line of code को कई engineers review करें और rigorous QA पर बहुत समय लगाने वाली प्रक्रिया अपनाई जाए, तो कितना charge करना पड़ेगा
Padova में रहते समय मैंने एक छोटी bookstore के लिए software बनाया था; दोस्त था, इसलिए जल्दी बनाया और ज्यादा charge नहीं किया। वह perfect नहीं था, लेकिन problem आती तो मैं fix कर देता था, problems भी ज्यादा नहीं थीं और दोस्त उस deal से खुश था। उसे पता था कि मैं सस्ता ले रहा हूं, इसलिए उसमें patience भी था
मैंने कई बार कहा कि अगर हमारी team customer से कहे, “project पूरा हो गया है, लेकिन इसमें इस back-office platform जितने bugs और UI nightmares हैं,” तो हमें डांट पड़ेगी और demote या fire कर दिया जाएगा
इसमें Google जैसी companies भी शामिल हैं जहां human support कम है। support कई रूपों में दिखता है: documentation, videos, blogs जैसी information; “मम्मी, Google ऐसे इस्तेमाल करते हैं” की तरह मदद करने वाला व्यक्ति; operating systems, browsers, formats जैसी इस्तेमाल की जाने वाली चीज़ों के लिए support; और Excel की तरह मेरे काम करने के तरीके को ही सहारा देना
आखिर में actual humans होते हैं। यही दुनिया के सबसे खराब ERP को भी जिंदा रखने वाला नंबर 1 factor है। marketing और sales भी इस बात का signal होते हैं कि support मौजूद है। enterprise customers को अगर सिर्फ engineers दिखें, तो यह खराब signal हो सकता है। developers अक्सर दूसरे काम नहीं कर पाते, और वही दूसरे काम जरूरी support होते हैं
product अच्छा हो, लेकिन support न हो तो वह मर जाता है। किसी खराब product से लड़ना हो तो अपनी team की cost घटाने के लिए bugs, performance issues, platforms जैसी support needs को कम करना समझदारी है, लेकिन दूसरे dimension का support जरूर जोड़ना होगा। छोटी team के लिए सबसे आसान है सबसे दुर्लभ support resource, यानी लोग, जोड़ना; उसके बाद creativity चाहिए
साथ ही strengths को अच्छी तरह communicate करना होगा। कुछ लोग “code रख पाने की क्षमता vs proprietary product” जैसे किसी खास तरह के support को ज्यादा महत्व देते हैं। कई लोग code की तुलना में support वाले proprietary product को ज्यादा पसंद करते हैं
1980 के बाद से computing performance लगभग 1000 गुना बढ़ी है, ऐसा मानना ठीक लगता है
dynamic array bounds checking की लागत 5% भी हो, तो असल में वह इससे काफी कम होती है; और अगर इसे हर जगह चालू कर दें, तो कंप्यूटर बस 950 गुना तेज़ रह जाएगा
अगर 1980 में वापस जाकर लोगों से “950 गुना तेज़, memory safety vulnerabilities की एक बड़ी श्रेणी से मुक्त, और debugging कई orders of magnitude आसान करने वाला कंप्यूटर” और “1000 गुना तेज़, लेकिन software अब भी bugs से भरा या उससे भी खराब, और debugging एक nightmare वाला कंप्यूटर” में से चुनने को कहा जाता, तो लोग सिर्फ 950 गुना पर भी हैरान रह जाते
लेकिन हमने दूसरा विकल्प चुना, और निजी तौर पर मुझे लगता है कि 1000x वाले खेमे ने बाकी लोगों का नुकसान किया
आखिरकार जब उन्होंने उसे Sparc 20 पर efficient तरीके से चलने के लिए optimize किया, तो कंपनी को बड़े market में सफल होने का आधार मिला. Optimization को competitive advantage की तरह देखा जाना चाहिए, और कुछ मामलों में यह सबसे महत्वपूर्ण competitive advantage भी हो सकता है
इसलिए bounds checking अनिवार्य करने से कुछ खास tasks में वह language प्रतिस्पर्धी नहीं रह जाती
ज्यादातर मामलों में यह बिल्कुल मायने नहीं रखता और 5% से भी काफी कम होता है. safe/unsafe या general/performance ranges को अलग करने का तरीका अच्छा समाधान लगता है
mainstream CPU, 80 के दशक की मशीनों से 10 लाख–20 लाख गुना तेज़ के ज्यादा करीब हैं. कुछ सौ dollars में आज भी 10 लाख गुना तेज़ श्रेणी का refurbished office computer खरीदा जा सकता है
आज कंप्यूटर के धीमे होने और धीमा महसूस होने की घटना सिर्फ इसलिए नहीं है कि कंप्यूटर धीमे हैं, फिर भी ऐसा हो रहा है. scripting languages का छोटी-छोटी operations पर लगातार memory allocate करना और dynamic types के कारण हर variable के लिए pointers follow करना भी इसकी कुछ वजहें हैं; और कुछ लोग पहले से खराब environment में बेहद inefficient programs भी इस्तेमाल करते हैं
आजकल ज्यादातर programs उस तरह नहीं लिखे जाते जैसे user चाहता है, बल्कि उस तरह लिखे जाते हैं जैसे लेखक काम करना चाहता है. बहुत लोगों को optimization की समझ नहीं होती या यह अंदाजा नहीं होता कि क्या ज्यादा तेज़ चलेगा; वे उसे काम करने लायक बनाते हैं और फिर सोचते हैं, “इस program की speed यही है”
यही software और तेज़ हो सकता है, यह विचार अपने-आप में एक niche mindset है, और Hacker News पर भी हर कोई ऐसा नहीं सोचता
garbage-collected languages अक्सर कई गुना ज्यादा memory इस्तेमाल करती हैं. वे ऐसी memory को तुरंत free नहीं करतीं जो अब इस्तेमाल में नहीं है, और शुरू से ही ज्यादा allocations की जरूरत भी रखती हैं
Google और Facebook में काम करके यह महसूस हुआ कि hardware कितना सस्ता है, और ज्यादातर मामलों में code optimization की value कितनी कम है
Google ने 10 साल से भी ज्यादा पहले datacenter resource usage manage करना शुरू कर दिया था, और हर project के लिए CPU cores, hard disk space, flash storage, disk spindles, memory जैसे budgets होते थे. ये resources आम तौर पर एक-दूसरे में convert किए जा सकते थे, इसलिए relative cost देखी जा सकती थी
उस समय flash storage hard disk से लगभग 20 गुना महंगी थी, लेकिन spindle bottleneck की वजह से total cost में वह कई बार सस्ती पड़ती थी
यह सब “mili-SWE”, यानी 1 SWE के 1 साल के काम के effort के 1000वें हिस्से में बदला जा सकता था. projects hardware बचाकर और लोग hire कर सकते थे, या कम लोग hire करके मौजूदा budget में अधिक hardware पा सकते थे
ठीक याद नहीं कि कितने CPU cores 1 SWE के बराबर होते थे, लेकिन शायद हजारों में थे. अगर पूरे project की optimization पर 1 SWE-year लगाकर भी 5000 CPU cores नहीं बचते, तो यह net loss है
बहुत बड़े projects इससे कहीं ज्यादा खर्च करते थे, इसलिए optimization समझ में आती थी; लेकिन खासकर जब लिखे गए code के कभी न कभी replace हो जाने की संभावना ज्यादा हो, तो optimization अक्सर सही नहीं होती थी
दूसरी तरफ web में सामान्य usability problem है. web को आज जितने resources लगते हैं, उतने नहीं लगने चाहिए. अगर आप किसी ऐसे व्यक्ति को जानते हैं जिसने data entry का काम किया हो, तो आपको पता होगा कि mouse काफी inefficient है. 30–40 साल पहले के text-based terminals बहुत कम resources इस्तेमाल करते हुए भी बेहद efficient interface देते थे
मुझे लगा था कि किसी दिन web “solve” हो जाएगा, यानी आम तौर पर expected technology stack तय हो जाएगा और लोग दूसरे problems पर आगे बढ़ जाएंगे, लेकिन ऐसा नहीं हुआ. अब भी “इस हफ्ते का framework” मौजूद है, और user code में scrollbar को फिर से implement करने जैसी मूर्खता की जाती है, जो mouse wheel के साथ ठीक से मेल नहीं खाता. यह समस्या कैसे हल हो सकती है, या शुरू से ही “solve” हो भी सकती है या नहीं, मुझे नहीं पता
Google ने performance के दो और पहलुओं—latency और overall equipment utilization—पर जबरदस्त effort लगाया. दोनों ऊपर से आए निर्देश थे, उन्होंने हजारों engineers का समय और ध्यान खींचा, और labor cost भी बड़ी थी
लेकिन अगर equipment constraint है, तो individual cores सस्ते होने पर भी उन्हें बेवजह idle नहीं छोड़ना चाहेंगे. वजह यह है कि नया datacenter बनने का इंतजार करने की opportunity cost बड़ी होती है. अगर usage latency के प्रति बहुत sensitive है, तो hardware cost बचाने के लिए नहीं बल्कि business metrics की वजह से milliseconds घटाना समझ में आता है
evaluation marginal cost पर होनी चाहिए. भले ही हर 1 dollar पर सालाना कुछ cents ही बचें, engineer को खाली बैठाने से बेहतर है कि वह काम किया जाए
समस्या यह है कि लगभग कोई ऐसा नहीं करता. decision-making का तरीका economic calculation से असंबंधित होता है, और ज्यादातर लोग बस “Google जो करता है” उसे follow करते हैं. इससे कई dysfunctions समझ में आते हैं
लेकिन आम कंपनियां, यहां तक कि बड़ी कंपनियां भी, उस स्तर पर नहीं होतीं. यह “Facebook/Google/Netflix आदि एक अलग वर्ग हैं और उनकी ज्यादातर practices आप पर लागू नहीं होतीं” वाले classic उदाहरण जैसा लगता है
हम एक alternate universe की कल्पना कर सकते हैं जहां human resources को optimization में झोंक दिया जाता है, लेकिन वह universe आज से बिल्कुल अलग होगा. optimization पर एक और engineer लगाने का मतलब feature development वाला एक engineer कम होना है. किसलिए? कुछ CPU cycles बचाने के लिए? यह मजाक जैसा लगता है
सिर्फ शीर्षक देखकर लगा था कि Carmack ठीक से optimize न किए गए software की आलोचना कर रहे हैं और पुराने hardware पर performance सुधारने की बात कर रहे हैं
असल ट्वीट इनमें से बिल्कुल भी नहीं है; वह एक thought experiment पर है जिसमें hardware की तरक्की रुक जाती है, और निष्कर्ष निकालता है कि “बेहद कम कीमत पर scalable computing न हो तो innovative नए products स्वाभाविक रूप से बहुत कम हो जाएंगे”
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
मुझे तो उल्टा लगता है कि smartphone के बाद 18 वर्षों में हमने बहुत बड़ा innovation ज्यादा नहीं देखा, और इसकी वजह यह है कि capital consumers को मूल रूप से वही product बेचने के लिए hardware advancement पर निर्भर है जो उनके पास पहले से है
हालांकि पहले ट्वीट के बाद मैं पढ़ नहीं पाया
ठहराव होगा, लेकिन स्थायी ठहराव नहीं होगा
अगर कम जटिल languages में लोगों को hire करके productive बनाया जा सके, तो worker market बड़ा होता है और cost घटती है
मूल बात में Carmack मूलतः यह कह रहे हैं कि “अच्छे और smart developers महंगे होते हैं, और करने को बड़े काम हैं, इसलिए code और systems को पूरी तरह optimize करवाने पर पैसा नहीं लगाया जाता, इसी वजह से software slow है”
इसलिए इसका implication यह है कि अगर अच्छे developers अचानक बहुत सस्ते हो जाएं, तो हर कोई उन्हें खरीदकर optimization में लगाएगा और बहुत सा software अचानक तेज हो सकता है। तो अच्छे developers अचानक सस्ते क्यों उपलब्ध हो सकते हैं?
अगर hardware की उम्र “planned obsolescence” के बाद 5 साल, 10 साल और बढ़ाई जा सके तो अच्छा होगा
इससे electronic waste काफी घटेगा, rare earths जमीन के अंदर ही रहेंगी, और greenhouse gas emissions भी काफी कम हो सकेंगे
लेकिन software production की market forces ऐसे externalities की कीमत नहीं चुकातीं। performance के लिए planning और design करने की तुलना में जल्दी release करना, test करना और iterate करना कहीं सस्ता है। game industry के कुछ organizations ने अच्छी performance और sales, दोनों पाने का formula ढूंढ लिया है, लेकिन यह समान रूप से नहीं फैला
enterprise और consumer software में requirements में performance criteria जोड़ने की incentive बहुत ज्यादा नहीं होती। users जितना सह सकें उसी स्तर के हिसाब से design किया जाता है, और changes व features लगातार release करने होते हैं, इसलिए जितना हो सके margin रखा जाता है। हर change performance और user satisfaction को प्रभावित कर सकने वाला debt है, इसलिए error rate संभालने के लिए budget margin रखा जाता है
यह “ready होने तक” बंद दरवाजों के पीछे design और development करने के पुराने तरीके से काफी अलग है
हमारे पास care और maintenance पर केंद्रित economy होनी चाहिए, और macro efforts को कुछ लोगों की perceived wealth के बजाय पूरी मानवता की भलाई के इर्द-गिर्द align करना चाहिए
अगर पुराने vehicles को maintain करने, पुराने computers को reuse करने आदि पर focus किया होता, तो growth की तुलना में landfills छोटे होते
हालांकि शायद कोई game-theoretic setup भी होगा जो दिखाता हो कि preservationist होना objectively inferior strategy है
पूरे exchange के order matching engine को single thread पर चलाना संभव हुए 10 साल से ज्यादा हो चुके हैं
मुझे लगता है कि strictly serialized transaction processing जैसी खास category की compute capability उतनी तेजी से नहीं बढ़ी जितना दूसरे metrics संकेत देते हैं। 31 cores और जोड़ देने से order matching engine तेज नहीं होगा; उल्टा slow हो सकता है
अगर आपका product प्रति सेकंड कुछ मिलियन से कम transactions process करते हुए भी machine cluster ढूंढ रहा है, तो आपको करीब 15 steps पीछे जाकर शुरुआत से फिर शुरू करना चाहिए
original design ही अब भी 99% use cases को satisfy कर देता, और आज की local compute capability को देखते हुए पूरे market को single machine पर चलाया जा सकता है
क्या time और price के हिसाब से sort करने के अलावा पर्याप्त computation नहीं है?
अगर हर transaction पर ज्यादा complex processing करनी पड़ती, तो इतने ज्यादा cases process नहीं कर पाते। हालांकि किस तरह की ज्यादा complex processing जरूरी होगी, यह उस domain का व्यक्ति न होने पर imagine करना मुश्किल है
सही बात है। यह एक आर्थिक समस्या है, यानी resource allocation की समस्या
चुनाव यह है कि किसी से software optimization पर ज़्यादा समय लगवाया जाए, या उससे ज़्यादा features बनवाए जाएँ। अगर दूसरा विकल्प ज़्यादा cash बनाता है तो वही करवाया जाएगा, और अगर पहला cash flow के लिए महत्वपूर्ण हो जाए तो वही करवाया जाएगा
यह software कंपनियों द्वारा आम लोगों पर डाले जाने वाले नकारात्मक externalities का साफ उदाहरण है। ज़्यादातर software कंपनियाँ energy, बर्बाद हुए समय, और अतिरिक्त e-waste की असली लागत नहीं चुकातीं, इसलिए वे optimization की परवाह नहीं करतीं
कई मामलों में बहुत गहरी optimization का खास मतलब नहीं होता, लेकिन दोबारा लिखने के बजाय बस और servers जोड़ देने वाली सोच दुखद स्थिति है
macOS, Windows, Android के ज़्यादातर नए features मैं इस्तेमाल नहीं करता। मुझे apps चलाने के लिए efficient environment और security improvements चाहिए। macOS की Settings app जैसे कई सुधार भी कुछ खास संतोषजनक नहीं हैं
design software में भी यही बात है। Adobe ने जो ज़्यादातर नए features डाले हैं, मैं उनका इस्तेमाल नहीं करता, और 10 साल पुराने Illustrator या Photoshop से भी मैं पूरी तरह खुश रह सकता हूँ। मुझे कम bloated software चाहिए
audio और music production में workflow अभी भी सुधर रहा है, इसलिए नए features चाहिए, लेकिन efficiency की कीमत पर नहीं
code editor के लिए VSCode की features पर्याप्त हैं। उससे ज़्यादा कुछ नहीं चाहिए, बेहतर LSP चाहिए, लेकिन वह editor का core नहीं है। बस चाहता हूँ कि VSCode तेज़ हो और कम memory खाए
software optimization भी इसी तरह आकर्षक है। लेकिन अगर समस्या “महंगे engineering time के कुछ घंटे लगाकर optimize करना” बनाम “सस्ती RAM और जोड़ना” हो, तो सस्ता विकल्प जीतता है। कभी-कभी समस्या इतनी बड़ी होती है कि optimization worthwhile हो जाती है
market तय करेगा कि कौन-सा विकल्प अपनाने लायक है। जब hardware और झोंकने के तरीके में diminishing returns तक पहुँचेंगे, तब software optimize किया जाएगा। Moore's Law धीमा पड़ रहा है, लेकिन लगता है कि हम अभी उस बिंदु तक नहीं पहुँचे हैं
लेकिन वास्तविकता इसके उलट के ज़्यादा करीब है। अगर कीमत कम हो, तो वे कम performance वाले version को भी पसंद करेंगे
Carmack का खंडन कहने से ज़्यादा, मेरे दिमाग में कभी-कभी आने वाला एक ठोस example है
Electron apps consumer के लिए performance समस्या के कारण सहन की जाने वाली चीज़ और नापसंद की जाने वाली चीज़ के बीच कहीं हैं, लेकिन शायद वही single innovation हैं जिसने workplace में Linux laptop को practically usable बनाया। उदाहरण के लिए बिना install किए MS Teams meeting में शामिल हो पाना सच में उपयोगी है
इसलिए हर कोई आजकल यह lament करता है कि Winamp जैसी tight coding वाली चीज़ें नहीं रहीं, लेकिन वे पहले तीन अक्षर भूल रहे हैं
Linux पर भी उसके चलने की संभावना काफी है, लेकिन Electron software हर platform पर खराब ही है
2010 में मैं cleaner के तौर पर काम करते हुए side job की तरह IT in-charge का काम भी करता था
उस समय मैंने कंपनी से कहा था कि पिछले 5 सालों के laptops, मोटे तौर पर Nehalem के बाद के products, spreadsheet work के लिए पर्याप्त performance रखते हैं। उनका काम असल में लगभग बस वही था, और 2 cores, 16GB RAM, 500GB SATA SSD काफी थे। marketing के कुछ लोगों को थोड़ी ज्यादा powerful machines चाहिए थीं, लेकिन बड़ा फर्क नहीं था, और latest top-end laptops न खरीदकर काफी पैसे बचाए गए
अब मैं वहाँ काम नहीं करता, लेकिन मुझे पूरा भरोसा है कि आज भी वे computers spreadsheets के लिए बहुत अच्छे होने चाहिए। workflow बहुत बदला नहीं है; जो बदला है वह software है। अगर लगातार update किया गया होगा, तो पता नहीं वे अभी MS Windows 10 या 11 “चला” भी पाएँगे या नहीं, लेकिन bloat और खासकर online-only spreadsheets की वजह से productivity काफी गिर गई होगी
वहाँ का internet भी बेहद खराब था। विकल्प थे: “business” होने की वजह से करीब 16Mbit asymmetric DSL, $300 प्रति माह, या Comcast 120Mbit cable, $500 प्रति माह। 120Mbit भी online-only spreadsheets के लिए बस किसी तरह चलने लायक है, और 16Mbit निश्चित रूप से कम है। उससे भी खराब बात यह है कि internet बंद हो जाए तो business रुक जाता है
दूसरे comment में जिस चोरी की बात कही गई है, उसकी असलियत यही है और मैं पूरी तरह सहमत हूँ। office में spreadsheets edit और update करने वाले laptop को internet या बेहूदा compute/storage resources, या बड़ी bandwidth की ज़रूरत होने का कोई कारण नहीं है
आज के computers की भयानक performance के लिए customers—यानी individuals और businesses दोनों—पर लागत थोपने के अलावा कोई बहाना नहीं है
https://news.ycombinator.com/item?id=43971960
दुनिया सुंदर, तेज़ और bug-free software पर नहीं, बल्कि features पर चलती है
अंतिम users के लिए किसी feature का न होना और bug होना अलग बात नहीं है। Performance इतनी खराब हो कि किसी काम को पूरा करने में 5 मिनट लगें, और feature न होने की वजह से user को वही काम manually 5 मिनट में करना पड़े—इनमें भी कोई मायने रखने वाला फर्क नहीं है। दोनों ही “slow” हैं
अगर आप अंतिम user value को लगातार maximize करते हैं, तो अनिवार्य रूप से slow और bugs से भरा software बनता है। ऊपर से, जब users से पूछा जाता है कि क्या वे अधिक तेज़ और कम bugs वाला, लेकिन कम features वाला software चाहेंगे, तो हैरानी की बात है कि वे नहीं कहते। और भी महत्वपूर्ण यह है कि enterprise दुनिया में software खरीदने वाला अक्सर अंतिम user नहीं होता, और वे ज्यादा features चाहते हैं, performance और elegance कम
अगर feature set समान हो, तो users और buyers सबसे तेज़, सबसे कम bugs वाला और elegant software चुनेंगे। लेकिन एक भी feature छूट जाए, तो हार हो जाती है। Software को तेज़ और elegant बनाए रखने की वजह यह है कि ऐसा करने पर features जोड़ते रहने के बावजूद कम-features वाला product न बन जाने की संभावना सबसे ज्यादा रहती है
तेज़ और elegant solution को अच्छे reviews मिल सकते हैं और लोग कह सकते हैं कि इसका इस्तेमाल अच्छा लगता है। इसलिए यह महत्वपूर्ण factor जैसा लग सकता है। लेकिन अंत में अगर वह मनचाहा काम नहीं कर सकता, तो लोग उसे खरीदेंगे ही नहीं। अगर जरूरी core feature मौजूद है, तो वे slow, चिड़चिड़ा करने वाला, bugs से भरा mess चुनेंगे
यह भी याद रखना चाहिए कि Microsoft को अब users को लात मारते और चीखते हुए अगले Windows version तक घसीटना पड़ता है। अगर users को खुद फैसला करने दिया जाता, तो कई लोग Windows XP के बाद कभी upgrade ही नहीं करते। बाद की versions में कई सुंदर नए features होने के बावजूद
मैं मानता हूँ कि companies और investors features अपने-आप में चाहते हैं, लेकिन users निश्चित रूप से नहीं
अगर संभव होता, तो कोई भी अब कुछ भी upgrade नहीं करता। बस देखिए Microsoft लोगों को upgrade कराने के लिए कितनी मेहनत करता है। मैंने कभी किसी को यह कहते नहीं सुना कि वे Windows, Office, Slack, Zoom आदि के नए versions चाहते थे
Photoshop जैसी हर चीज़ को cloud में force किए जाने की वजह भी यही है। ज्यादातर लोग दिए जा रहे नए features नहीं चाहते, और इसमें enterprise buyers भी शामिल हैं। Revenue बनाए रखने का जवाब यह है कि features दिए जाएँ या नहीं, लोगों को खरीदने पर मजबूर किया जाए
हालांकि existing users पहले से ही software से अपना जरूरी काम कर रहे होते हैं, इसलिए नए features उन्हें कोई दूसरा software हटाने में मदद कर सकते हैं या कोई नया काम संभव बना सकते हैं। लेकिन अगर वह नया काम सचमुच बेहद महत्वपूर्ण होता, तो वे पहले ही कोई दूसरा software खोजकर इस्तेमाल कर रहे होते, यानी अब तक उसके बिना भी काम चला रहे थे। इसलिए अगर existing users वाकई introspective हों, तो मुझे लगता है वे पहले performance improvements मांगेंगे, और कुछ छोटे improvements चाहेंगे
इसके उलट potential users अभी software को जानते नहीं हैं, या उसे उपयोगी महसूस करने से पहले उन्हें कोई और feature चाहिए। नए features को तर्कसंगत रूप से खोजने वाले यही लोग हैं
इसलिए “features vs performance” का फैसला यह भी संकेत देता है कि developer की priority नए users जोड़ना है या existing users को संतुष्ट करना। Technical लोगों का बाद वाले को पसंद करना स्वाभाविक है। वे यह game पहले खेल चुके हैं, और जानते हैं कि वे acquisition के दौरान नहीं, बल्कि वास्तव में लंबे समय तक इस्तेमाल किए जाने के समय priority बनना चाहते हैं
Buggy और slow, लेकिन feature-rich software का market पर राज करना भी इसलिए है कि companies growth को पहले priority देती हैं। इतिहास ऐसे सुंदर और elegant software से भरा है जिसे users याद करते हैं, लेकिन वे company को टिकाए रखने लायक व्यापक रूप से फैल नहीं पाए
Trade-off दोनों दिशाओं में वास्तविक है। ज्यादातर लोग potential user होने की तुलना में user के रूप में अधिक समय बिताते हैं। यह संभवतः आजकल software और computers के अविश्वसनीय रूप से खराब होने की आम धारणा का एक बड़ा कारण है
घरेलू और office computers में RAM और बेहतर CPU पर खर्च किया गया पैसा, उन पर चलने वाले सभी software को सस्ता और ज्यादा features के साथ release करना संभव बनाता है