Fast - तेज़ सॉफ़्टवेयर की ताकत

• सॉफ़्टवेयर डेवलपमेंट में तेज़ (fast) की मांग कम ही की जाती है, लेकिन तेज़ सॉफ़्टवेयर उपयोगकर्ता के व्यवहार को बदल देता है
• तेज़ deployment और real-time streaming जैसी तकनीकें काम की दक्षता और remote work को क्रांतिकारी रूप से बेहतर बनाती हैं
• धीमा सॉफ़्टवेयर cognitive friction पैदा करता है और वास्तव में उपयोगकर्ता की productivity को काफी घटा देता है
• तेज़ सॉफ़्टवेयर जटिलता को छिपाता नहीं, बल्कि सरलता और फोकस दिखाता है
• आगे चलकर डेवलपमेंट इंडस्ट्री में performance और experience optimization पर ज़्यादा ज़ोर रहने की संभावना है

---

सॉफ़्टवेयर इंडस्ट्री जो तेज़ी की मांग नहीं करती

• सॉफ़्टवेयर इंडस्ट्री में आम तौर पर features, pricing, data integration जैसी चीज़ों की मांग होती है, लेकिन ‘तेज़ी’ की सीधी मांग कम ही होती है
• फिर भी तेज़ सॉफ़्टवेयर में उपयोगकर्ता के व्यवहार को बदलने की ताकत होती है
• अगर कोड deploy करने का समय सेकंडों में आ जाए, तो डेवलपर deployment की आवृत्ति भी बढ़ा देते हैं
• AI-आधारित code autocomplete फीचर अनजान भाषाओं में prototyping को आसान बना देता है
• real-time streaming तकनीक remote work की नई संभावनाएँ खोलती है

धीमे सॉफ़्टवेयर की सीमाएँ

• धीमा सॉफ़्टवेयर हमारी सोच से कहीं अधिक सीमाएँ पैदा करता है
• उदाहरण के तौर पर, हवाई जहाज़ के WiFi का उपयोग करते समय बड़ा काम कर पाना मुश्किल होता है
  • Slack पर संदेश भेजना या ईमेल का जवाब देना ही मुश्किल से हो पाता है,
  • Google Docs कई बार ठीक से काम नहीं करता
  • अंत में अनुभव ऐसा बन जाता है कि उपयोगकर्ता हार मान लेता है
• इसके विपरीत Instagram जैसी सेवाएँ लगातार तेज़ अनुभव देती हैं

तेज़ सॉफ़्टवेयर का असर

• तेज़ी जादुई महसूस होती है
• तेज़ सॉफ़्टवेयर cognitive friction को हटाता है, और Raycast या Superhuman की तरह उम्मीद से एक कदम आगे की प्रतिक्रिया देता है
• Superhuman की 100ms से कम प्रतिक्रिया गति और बेहतरीन shortcut support ईमेल उपयोग के अनुभव को बदल देती है
• Mercury का instant transfer फीचर भी धीमे बैंकिंग ट्रांज़ैक्शन के आदी उपयोगकर्ताओं को चौंका देता है
• इन टूल्स की स्पीड की खुलकर तारीफ़ नहीं होती, लेकिन यही वह वजह है जिससे उपयोगकर्ताओं को यह लगभग जादू जैसा लगता है

तेज़ी, सरलता और फोकस

• तेज़ी का मतलब सरलता भी है, और आधुनिक सॉफ़्टवेयर माहौल में यह एक दुर्लभ होती जा रही वैल्यू है
• सॉफ़्टवेयर को तेज़ बनाने के लिए अनावश्यक फीचर्स हटाने की मेहनत ज़रूरी है
• Linear जैसे सरल project management tools Workday, Oracle जैसी enterprise apps की तुलना में कहीं बेहतर और तेज़ उपयोग अनुभव देते हैं
• तेज़ी उपयोगकर्ता के प्रति सम्मान है, जो दिखाती है कि अनावश्यक चीज़ों को सख्ती से हटाया गया है

तेज़ बनाने के लिए छिपी हुई मेहनत

• तेज़ सॉफ़्टवेयर बनाने के लिए जटिल backend optimization की ज़रूरत होती है
• Cash App में सिर्फ वही चरण जोड़ने की कोशिश की गई जो उपयोगकर्ता की यात्रा के लिए बिल्कुल ज़रूरी हों, जबकि जटिलता को भीतर ही संभाला गया
• Instagram ने फ़ोटो अपलोड करते समय caption लिखते ही upload शुरू कर दिया, ताकि उपयोगकर्ता को लगे कि अपलोड तुरंत हो गया
• तेज़ी सिर्फ तकनीकी उपलब्धि नहीं, बल्कि priorities और focus का नतीजा है

तेज़ी है मज़ा और प्रेरणा

• तेज़ सॉफ़्टवेयर अपने आप में मज़ा और संतुष्टि देता है
• typing speed (WPM) मापना, shortcuts सेट करना जैसी छोटी चीज़ों में भी उपयोगकर्ता तेज़ होने के अनुभव का आनंद लेते हैं

तेज़ी की सापेक्षता

• AI और LLM-आधारित workflows पारंपरिक तरीकों की तुलना में कहीं अधिक तेज़ अनुभव देते हैं
• उदाहरण के लिए, 6 मिनट में LLM से research करवा लेना पुराने तरीकों की तुलना में 10,000 गुना से अधिक तेज़ productivity दे सकता है
• लेकिन अभी भी AI app development, build और deployment प्रक्रिया में पिछले सॉफ़्टवेयर युग की तुलना में कई कमियाँ हैं
• इस समय performance और experience की तुलना में नए फीचर्स पर ज़्यादा ध्यान है
• भविष्य में low latency, interface design, connectivity, reliability जैसी optimization priorities अधिक महत्वपूर्ण हो जाएँगी
• तब और ज़्यादा नई संभावनाएँ और उपयोगकर्ता अनुभव का विकास सामने आएगा

संदर्भ सामग्री

• तेज़ी पर उपयोगी अतिरिक्त सामग्री के रूप में नीचे दिए गए लेख हैं
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Hacker News की राय

• YCom में HN इंटरफ़ेस को तेज़ और अच्छी तरह बनाए रखने के लिए मैं सच में आभारी हूँ। जब Slashdot ने "modern UI" के नाम पर इंटरफ़ेस पूरी तरह बदल दिया था, तो वह इतना खाली-खाली और स्कैन करना मुश्किल हो गया कि मैंने उसे तुरंत छोड़ दिया। पहले मैं उसे रोज़ पढ़ता था
  • information density और मनचाही जानकारी जल्दी ढूँढ पाना, "engagement" की अवधारणा के लगभग उलट है। अक्सर साइटें जानबूझकर चीज़ों को जटिल बनाती हैं ताकि साइट पर बिताया गया समय बढ़े और विज्ञापनदाताओं को दिखाया जा सके। पेज को जानबूझकर धीमे लोड किया जाता है ताकि गलत क्लिक हों और "conversion" बढ़े। हकीकत यह है कि यूज़र-केंद्रित होने से ज़्यादा कमाई दूसरों को बहकाने में होती है
  • HN वह साइट है जिसे मैं यह देखने के लिए खोलता हूँ कि इंटरनेट कनेक्शन चल रहा है या नहीं। इतने सारे web bloat के बीच यह सच में चमकती है
  • HN UI में भी, खासकर mobile पर, सुधार की ज़रूरत है। contrast कम है, बटन बहुत छोटे हैं इसलिए इस्तेमाल करना असुविधाजनक है, dark mode नहीं है वगैरह। मेरे हिसाब से आदर्श UI का एक वर्ज़न मैंने Elm में, पूरी तरह client-side, HN firebase API के साथ बनाया है https://seville.protostome.com/
  • मुझे नहीं लगता कि Slashdot सिर्फ UI की वजह से खराब हुआ। उसकी असली वैल्यू बहुत शुरुआती दौर के उच्च-स्तरीय SME लोगों की टिप्पणियों में थी। साइट बिकने के बाद कमज़ोर यूज़र, खराब moderation और लोगों के छोड़कर जाने से गिरावट शुरू हुई लगती है। अब भी साइट का ज़िंदा होना हैरान करता है
  • orange site(HN) अब भी Markdown link tags को सपोर्ट नहीं करती
• मुझे लगता है कि LLM अपनाने वाले workflow अक्सर व्यवहार में धीमे पड़ जाते हैं। IDE का "refactor" फीचर 1 सेकंड में काम खत्म कर देता है, लेकिन वही काम AI helper को देने पर 30 सेकंड लगते हैं, और "agent" तरीके में 15 मिनट। उदाहरण के लिए, मैंने agent को HTTP endpoint का कोड लिखने को कहा तो पहले लगा कि "एक दिन का काम 10 मिनट में हो गया", लेकिन बाद में देखा कि logic उलझा हुआ था और error handling भी कमजोर थी। आखिरकार मैंने खुद करीब 5 घंटे लगाकर उसे फिर से लिखा, टेस्ट भी मेरे मानक से बेहतर हुए और error handling भी उसकी अपनी कोशिश से बेहतर स्तर तक पहुँची। इस पर एक संबंधित अध्ययन भी है https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • मैं इस विषय पर पहले भी कई बार लिख चुका हूँ। मुझे लगता है कि LLM का benchmark score के पीछे भागना, programming tools के नज़रिए से गलत दिशा है। मेरे अनुभव में यह काफ़ी ऊँची संभावना से गलत होता है, इसलिए हमेशा नतीजे जाँचने पड़ते हैं। इस वजह से LLM के साथ आगे-पीछे में समय जाता है, और जवाब भी धीमे आते हैं, तो अक्सर लगता है कि मैं खुद हाथ से ज़्यादा जल्दी बना सकता था। मैं तो ऐसा agent चाहता हूँ जो benchmark में 60% ही सही, लेकिन 1 सेकंड के भीतर जवाब दे
  • LLM ने मेरा काम सच में तेज़ सिर्फ code के advanced find/replace जैसे कामों में किया है। जैसे कोड के कई हिस्सों में मौजूद "XXX से जुड़ा logic" किसी और चीज़ से बदलने को कहो, तो यह काफ़ी अच्छा जवाब देता है। खुद खोजकर एक-एक जगह बदलने की मेहनत बहुत कम हो जाती है। हाँ, बहुत बड़े कोडबेस पर मैंने इसे आज़माया नहीं है
  • शायद यह स्थिति पर निर्भर करता है। refactor के मामले में अगर IDE या language server सपोर्ट करे तो वह कहीं तेज़ है, लेकिन बाकी जगह LLM मददगार हो सकता है। जैसे कल मैंने URL normalization logic का MVP बनाया। ग्राहक डेटा में URL के बहुत तरह-तरह के रूप थे, इसलिए validation cases काफ़ी थे। मैंने सबसे आम customer examples Claude में डालकर "minimum spanning test cases" बनाने को कहा, तो 5~10 सेकंड में नतीजा आ गया। उसके आधार पर Zed के Opus agent फीचर से टेस्ट फ़ाइल बनाई, फिर cases की समीक्षा की, गैर-ज़रूरी हिस्से हटाए, और logic भी थोड़ा सुधारा। यह तरीका सब कुछ अकेले बनाने से बहुत तेज़ था
  • मैं online और offline दोनों जगह यह बहुत सुन रहा हूँ कि senior-level काम में 40~60% तक speedup मिल रहा है। फिर भी अभी ऐसा नहीं लगता कि सिर्फ AI agents पर भरोसा करके सब कुछ ढीला छोड़ दिया जाए
• यह मेरे नए दिनों की एक घटना है, जब software engineer के रूप में speed बढ़ाने के लिए मेरी पहचान बनी थी। वह ऐसा दौर था जब algorithm की जानकारी और compiler output पढ़ने की क्षमता दोनों महत्वपूर्ण थीं, और Carmak, Abrash जैसे लोग स्टार बन रहे थे। 22 साल की उम्र में पहली बार मैं एक बड़े multinational ग्राहक की मीटिंग में शामिल हुआ, जहाँ हमारे प्रोडक्ट की speed पर सवाल उठा। उस कंपनी के VP को यह कहते सुनना कि "1 सेकंड की तेजी हमारे सालाना मुनाफ़े में 1 million dollars जोड़ देती है" मेरे लिए जबरदस्त झटका था। speed को इस तरह पैसे से जोड़कर देखना मेरे लिए पहली बार था, और वही निर्णायक पल था। 20 साल बाद भी वह मेरे करियर के सबसे बड़े highlights में से एक है। और फिर एक दूसरे engineer ने VP से मज़ाक में पूछा, "अगर 0 सेकंड तक ले आएँ तो क्या अनंत पैसा कमाएँगे?" कमरे में कोई नहीं हँसा, लेकिन मुझे वह काफ़ी मज़ेदार लगा
  • क्या 1 सेकंड से 0 सेकंड, या 2 सेकंड से 1 सेकंड करने पर हर बार 1 million dollars बढ़ते हैं? अनंत पैसे वाली बात पर जाना थोड़ा अजीब तर्क है
  • आख़िर में क्या वह सचमुच तेज़ हुआ, यह जानने की उत्सुकता है
• ब्लॉग पोस्ट की पहली पंक्ति से सहमत होकर यह प्रतिक्रिया लिख रहा हूँ। यूज़र शायद ही कभी डेवलपर से सीधे कहते हैं कि "इसे तेज़ बनाइए", लेकिन अगर चीज़ तेज़ न हो तो वे भरोसा भी नहीं करते। अगर Rust, Ruby से धीमा होता तो कोई उसकी परवाह नहीं करता। Rust को ध्यान इसलिए मिलता है क्योंकि वह "C++ से तेज़" कहा जाता है। HN पर भी बस इतना काफ़ी है कि कुछ "तेज़" है, और लोग लगभग सम्मोहित होकर उत्साहित हो जाते हैं। ज़रा सा भी तेज़ हो तो तुरंत ध्यान खिंच जाता है
  • यह बात सिर्फ HN पर लिखने वाले छोटे programmer वर्ग पर लागू होती है। ज़्यादातर डेवलपर और आम यूज़र को धीमे होने से ज़्यादा फ़र्क नहीं पड़ता, बस UI सुविधाजनक होना चाहिए। प्रो data scientists भी बहुत तेज़ commands की बजाय साफ-सुथरा Github Desktop ज़्यादा इस्तेमाल करते हैं
  • निष्कर्ष गलत लगता है। "तेज़" तब एक बहुत मज़बूत differentiator बनता है जब वही feature set तेज़ी से दिया जाए। लोग "X से तेज़ X" पर टूट पड़ते हैं, लेकिन वे अधिक features, बेहतर UX, कम कीमत या किसी और अच्छाई के लिए भी बदल सकते हैं; धीमी चीज़ भी चुनी जा सकती है
  • languages और runtimes में speed महत्वपूर्ण है, लेकिन frameworks के मामले में features, compatibility जैसी दूसरी बातें ज़्यादा अहम होती हैं। Electron जैसा धीमा प्लेटफ़ॉर्म भी लोग खूब इस्तेमाल करते हैं
  • हम वास्तव में ऐसी दुनिया में जी रहे हैं जहाँ काफ़ी सारे apps, खासकर web apps, बहुत ही धीमे हैं। यूज़र कुछ करे और response आने में कई सेकंड लग जाएँ, यह आम बात है। "तेज़ ही सबसे अच्छा है" कहने के बावजूद वास्तविकता उलटी है
  • HN यूज़र 'तेज़' को इसलिए पसंद करते हैं क्योंकि हम जानते हैं कि आज जो ज़्यादातर tech हम इस्तेमाल करते हैं, वह बहुत धीमी है, और उसे मूल रूप से इससे कहीं तेज़ बनाया जा सकता है
• उल्टा यह भी होता है कि अगर कोई चीज़ "बहुत" तेज़ हो, तो शक होता है कि क्या यह सच में हुई भी है। TurboTax के एक उदाहरण में असली analysis को 1 सेकंड भी नहीं लगता था, लेकिन जानबूझकर एक नकली loading screen दिखाने पर लोगों ने उस पर ज़्यादा भरोसा किया और उसे ज़्यादा पसंद किया। यानी असली processing समय बहुत कम होने के बावजूद, 'क्या इसने सच में जाँच की?' इस भरोसे के लिए उसे जानबूझकर धीमा दिखाया गया
• speed लागत के लिहाज़ से भी महत्वपूर्ण है। cloud में सेकंड के हिसाब से पैसे देने वाले ढाँचे में, अगर हर प्रक्रिया optimize न की जाए तो सस्ती transcription service देना संभव नहीं होता। उदाहरण के लिए, मेरी बनाई हुई image open source वाले विकल्प के बाद अगली सबसे अच्छी image से 2.5 गुना छोटी हो गई, और उसी से faster cold boot, lower cost और better service मिली https://speechischeap.com
  • S3 धीमा है या तेज़? व्यवहार में दोनों। single request के हिसाब से धीमा, लेकिन parallel में कई requests चलाओ तो तेज़ महसूस होता है। आख़िरकार 'तेज़' कभी survival के लिए ज़रूरी होता है, और कभी एक तरह की aesthetics भी होता है
  • मैं तो उल्टा consumer hardware पर services चलाता हूँ और cloud से कहीं सस्ता ऑपरेट करता हूँ। image size की चिंता नहीं करनी पड़ती (bare metal ज़्यादा तेज़ है)। मैं अभी 20,000 minutes per minute की transcription मुफ़्त दे रहा हूँ (5-second request limit के आधार पर)। इससे जुड़ा open source और cross-platform alternatives भी बना रहा हूँ https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer अगर transcription services में क्रांति लाने में रुचि हो तो संपर्क का स्वागत है
  • मुझे उम्मीद है कि PAPER जैसे tools की कुल install size (कम-से-कम Linux पर) 2MB के भीतर हो, cache समेत भी। pip 10~15MB है, pipx उससे बड़ा है, और uv 35MB है। मैं इससे छोटा रखने की कोशिश कर रहा हूँ
  • सिर्फ तेज़ होने का मतलब यह नहीं कि चीज़ हल्की और efficient भी हो। कई बार उसे तेज़ बनाने के लिए महँगा hardware बड़ी मात्रा में झोंक दिया जाता है
• जब भी अमेरिकी bank transfer की धीमी प्रक्रिया पर शिकायत वाला कोई लेख दिखता है, मुझे खुद को याद दिलाना पड़ता है कि UK या Switzerland जैसे देशों में bank transfer लगभग तुरंत हो जाते हैं। समझ नहीं आता कि अमेरिका में यह इतना धीमा क्यों है
  • अमेरिका के regional banks में अपने programmers बहुत कम होते हैं, और वे "core processor" पर निर्भर रहते हैं। इस वजह से system upgrades बहुत धीमे होते हैं। Faster ACH लागू करने में भी कई साल लगे, और regional bank lobby ने यह कहकर देरी की माँग की कि यह उनके खिलाफ है। इस पर एक अच्छा ब्लॉग है https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • ACH में scheduling और batch processing ही देरी की वजह हैं। transfer खुद तुरंत हो सकता है, लेकिन आम तौर पर आधी रात को जोड़कर process किया जाता है। इसी वजह से अमेरिका में Venmo और Zelle लोकप्रिय हैं। Switzerland में भी IBAN transfer धीमे हैं, और real-time payments के लिए TWINT ज़्यादा चलता है (QR code स्कैन वाला तरीका)। UK का BACS भी इसी वजह से धीमा है
  • अमेरिका में वास्तव में दो real-time transfer systems हैं: RTP और FedNow। इनमें भाग लेने वाले banks लगातार बढ़ रहे हैं https://real-timepayments.com/Banks-Real-Time-Payments.html पहले थोड़ी फीस देकर credit card network के ज़रिए instant transfer करना संभव था। लेकिन credit cards की guarantees और refund rules अलग होते हैं, और fraud होने पर bank का नुकसान ज़्यादा होता है
  • इसका एक consumer-friendly पहलू भी है। जैसे अगर automatic withdrawal किसी ऐसे खाते से हो जहाँ balance नहीं है, तो bank कई बार email से चेतावनी देता है। real-time में यह तुरंत समस्या बन जाती, लेकिन मौजूदा व्यवस्था में सूचना मिलने के बाद खुद सुधार का समय मिल जाता है, जिससे late fee या charges से बचा जा सकता है। यानी instant transfer न होने से bank चेतावनी देता है और मुझे प्रतिक्रिया का मौका मिलता है
  • patio11 ने इस पर विस्तार से लिखा है https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• यह लेख दिलचस्प था और सोचने के लिए काफ़ी बातें देता है। speed सच में तब महसूस होती है जब सिर्फ वास्तविक throughput नहीं, बल्कि "महसूस होने वाली तेजी" महत्वपूर्ण हो — जैसे UI responsiveness या input delay। इसी वजह से मैं Rust की बजाय Go को पसंद करने लगा हूँ। Go की compilation speed इतनी तेज़ है कि मानो उसे मापने की भी ज़रूरत नहीं। दूसरी ओर, जो चीज़ धीमी महसूस हो, वह चाहे वास्तविक throughput में तेज़ ही क्यों न हो, मुझे फिर भी नापसंद होती है (जैसे Java startups)
  • Go और Rust की तुलना में भी compile speed सच में महत्वपूर्ण लगती है। Rust builds में तरह-तरह की dependencies बहुत होती हैं, जिससे project structure कुछ-कुछ JavaScript जैसा लगने लगता है। Go में comparative तौर पर dependencies काफ़ी कम हैं, यही बात मुझे पसंद है
  • डेवलपर्स का इस तरह बहस करना अच्छी बात है, लेकिन असली सवाल यह है कि "यूज़र के लिए कौन-सी language ज़्यादा तेज़ है"
• "software में 'इसे तेज़ कर दीजिए' बहुत कम सुनने को मिलता है" वाली बात के उलट, जिन लगभग सभी कंपनियों में मैंने काम किया, वहाँ page responsiveness और latency सबसे ऊँची प्राथमिकताओं में थे। startup हो या बड़ी company, speed और latency महत्वपूर्ण goals थे, और आम तौर पर product कितना तेज़ है, पेज कितनी जल्दी खुलता है, कहीं अजीब delays तो नहीं हैं — यह सब हमेशा गंभीरता से देखा जाता था
  • मेरे सीधे अनुभव में ज़्यादातर कंपनियाँ (8 में से 6) performance optimization के लिए लगभग समय ही नहीं देती थीं, इसलिए मुझे यह काम छिपकर करना पड़ता था। यहाँ तक कि जो latency नापती थीं और इसे महत्वपूर्ण कहती थीं, वहाँ भी feature additions के आगे यह व्यवहार में पीछे छूट जाता था
  • search results की speed पर जुनून की हद तक ध्यान देते हुए भी, page rendering या यूज़र को भेजे जाने वाले data size पर बहुत कम ध्यान दिया जाता था
• कई नौकरियों में बार-बार मैंने यही देखा है कि ज़्यादातर लोग speed की असली वैल्यू को कम आँकते हैं। वे बस यह मानते हैं कि "वही workflow, बस थोड़ा तेज़"। उदाहरण के लिए, रात भर चलने वाले बड़े experiments को तेज़ करना बहुत मददगार नहीं लगता, लेकिन अगर speed को बहुत ज़्यादा बढ़ा दिया जाए तो दिन में भी कई बार experiment चलाए जा सकते हैं, और उससे बिल्कुल अलग स्तर की productivity मिलती है
  • लोग context switching की लागत को बहुत कम आँकते हैं। वे सोचते हैं कि अगर कोई command 30 सेकंड से 3 सेकंड हो जाए और दिन में 10 बार चले, तो बस 5 मिनट बचेंगे; लेकिन वास्तव में switching cost उससे कहीं बड़ी होती है
  • हर बार जब CI pipeline में कई घंटे लगते हैं, तो सोचता हूँ कि अगर यह 20 मिनट के भीतर खत्म हो जाती, तो मैं हर बार उन छोटे-मोटे lint warnings तक को भी तुरंत ठीक कर देता