अच्छा software जानता है कि कब रुकना है

• software की मूलभूत भूमिका यह है कि वह साफ़ तौर पर जाने कि उसे कौन-सी समस्या हल करनी है, और अपनी सीमाओं को पहचाने
• अच्छा software हर feature को समेटने की कोशिश नहीं करता, बल्कि केवल वहीं काम करता है जहाँ सुधार की ज़रूरत हो, और अपने उद्देश्य से भटकता नहीं
• ls command को AI feature से बदल देने के एक काल्पनिक उदाहरण के ज़रिए, मौजूदा tools के बेवजह फैलते जाने की प्रवृत्ति पर व्यंग्य किया गया है
• 37Signals की ‘Getting Real’ और ‘Rework’ में दिए गए सिद्धांतों का हवाला देते हुए, यह ज़ोर दिया गया है कि constraints को ताकत बनाना चाहिए और गैर-ज़रूरी feature requests को ठुकराना चाहिए
• AI उछाल के बीच भी यह याद दिलाया गया है कि मौजूदा standards की स्थिरता और समस्या की स्पष्ट परिभाषा किसी नए trend से अधिक मूल्य रखती है

---

software की भूमिका और सीमाएँ

• लेख की शुरुआत एक काल्पनिक दृश्य से होती है, जिसमें Linux distribution update करने के बाद ls command AI-आधारित directory intelligence में बदल जाती है
  • नया als command user की मंशा का अनुमान लगाता है, files को rank करता है, और यह संदेश दिखाता है कि मौजूदा ls का support 30 दिनों में बंद हो जाएगा
  • यह दृश्य feature overload और गैर-ज़रूरी innovation पर एक व्यंग्यात्मक उदाहरण है
• “खुशकिस्मती से ऐसा वास्तव में नहीं होता” कहते हुए, यह रेखांकित किया गया है कि अच्छा software जानता है कि उसे कब रुकना चाहिए

अच्छे software के मुख्य सिद्धांत

• अच्छा software जानता है कि उसका उद्देश्य क्या है, वह सब कुछ करने की कोशिश नहीं करता, और यह अलग कर पाता है कि कब रुकना है और क्या सुधारना है
• इंसानी ‘maximalist mindset’ हर चीज़ को बड़ा, अधिक जटिल और अधिक भरा हुआ बनाने की प्रवृत्ति रखता है
• लेकिन software को अपने role और स्थान को स्पष्ट रूप से परिभाषित करना चाहिए, और अगर कोई नया विचार मौजूदा vision से मेल नहीं खाता, तो उसे अलग project के रूप में अलग कर देना चाहिए

37Signals की product philosophy

• Basecamp के संस्थापकों की लिखी ‘Rework’ और ‘Getting Real’ product design के लिए महत्वपूर्ण सीख देती हैं
  • constraints फायदे हैं (Constraints are advantages): छोटी team, सीमित budget और सीमित scope बेहतर निर्णय लेने में मदद करते हैं
  • feature requests को नज़रअंदाज़ करना (Ignore feature requests): users की माँगी हर feature को सीधे implement करने के बजाय, मूल समस्या को समझने वाला दृष्टिकोण ज़रूरी है
  • जल्दी ship करो, बार-बार ship करो (Ship early, ship often): पूरी तरह perfect लेकिन launch न हुआ product, अपूर्ण लेकिन सचमुच काम करने वाले product से कम मूल्यवान है
  • core-केंद्रित design (Epicenter design): navigation या आसपास के elements से पहले core interface और interaction को design करना चाहिए
  • default रूप से ‘न’ कहना (Say no by default): हर नए feature के साथ complexity, maintenance cost और exception handling जैसी छिपी हुई लागतें आती हैं
  • जो खुद चाहिए वही बनाना (Scratch your own itch): वही product जो आपकी अपनी वास्तविक समस्या हल करता है, बेहतर निर्णय लेने में मदद करता है

बदलाव से अधिक निरंतरता का मूल्य

• हाल में कई products में AI को केंद्र में रखकर नाम और features को फिर से गढ़ने का रुझान देखा जा रहा है
  • MinIO → AIStor
  • Oracle Database → Oracle AI Database
• हर चीज़ का नाटकीय रूप से बदलना ज़रूरी नहीं है
• किसी खास problem domain में de facto standard बन जाना उससे भी बड़ा मूल्य रखता है

[GN⁺]

Hacker News की राय

• “feature requests को अनदेखा करो” वाली सलाह देखकर Blizzard और World of Warcraft Classic का मामला याद आया
  कई सालों तक users ने classic version की मांग की, लेकिन Blizzard ने “तुम्हें वो नहीं चाहिए होगा” कहकर मना कर दिया
  आखिरकार उन्होंने classic WoW जारी किया और उसे ज़बरदस्त सफलता मिली
  बाद में developers ने माना कि “users सच में जानते थे कि वे क्या चाहते हैं”
  यानी हमेशा feature requests को अनदेखा करने के बजाय, कभी-कभी यह मानना चाहिए कि user बिल्कुल सही भी हो सकता है

  • user की request शुरू में बेतुकी लगे, तब भी अगर वह user विनम्र हो, तो यह समझाते-समझाते कि वह क्यों संभव नहीं है, कई बार खुद ही बेहतर समाधान सूझ जाता है
    उल्टा, बदतमीज़ या आत्मकेंद्रित user के साथ बातचीत ही थकाऊ हो जाती है, इसलिए जवाब देना बंद कर दिया जाता है
    आखिरकार सीख यही है कि request करते समय शिष्ट होना चाहिए
  • “user requests को अनदेखा करो” सुनने में अच्छा लगता है, लेकिन असल में “समझो कि user क्या कह रहा है” ज़्यादा सही बात है
    उसके बाद तय करना चाहिए कि request वैध है या नहीं, और उसे कैसे implement किया जाए
  • Blizzard के मामले में देखें तो users सिर्फ़ “classic version” नहीं चाहते थे, बल्कि modern WoW के जटिल systems के खिलाफ़ उनकी नाराज़गी थी
    मूल समस्या यह थी कि ‘game अपनी शुरुआती feeling खो चुका था’, और अगर इसे समझा जाता तो classic के अलावा किसी और तरीके से भी हल निकाला जा सकता था
  • सच तो यह है कि user भी, developer भी और PM भी अक्सर वास्तव में क्या चाहते हैं यह साफ़-साफ़ नहीं जानते
    WoW Classic, ‘पुरानी भावना’ वापस पाने की सतही इच्छा की अभिव्यक्ति थी, लेकिन उसके नीचे ‘भरोसेमंद न लगने वाली development direction’ के प्रति अविश्वास था
    आदर्श दुनिया में दोनों versions की खूबियों को मिलाकर एक परफेक्ट रूप बन सकता था, लेकिन हक़ीक़त में रायों का टकराव सिर्फ़ और ज़्यादा भ्रम पैदा करता
  • इसके उलट उदाहरण Ultima Online है
    user requests के अनुसार non-PVP instances जोड़ दिए गए, तो tension ही खत्म हो गया और game फीका पड़ गया
    इस मामले में developer, users से बेहतर समझ रखता था

• मेरा मानना है कि ऐसे complete software ज़्यादा होने चाहिए जो feature जोड़ना बंद कर दें
  “अब यह काफ़ी है” कह सकने का साहस होना चाहिए
  Evernote और Dropbox जैसे कई उदाहरण हैं, जो अपने बेहतरीन दौर के बाद feature overload की वजह से उलझनभरे हो गए

  • पहले ज़्यादातर software इसी तरह release होते थे
    वे box में बिकते थे, और नया version आने पर नया box खरीदना पड़ता था
    यह आज के लगातार update होने वाले web apps से पहले का दौर था
  • ज़्यादातर software यह मानने को तैयार नहीं होते कि वे complete हो चुके हैं
    बल्कि update के साथ कई बार वे और खराब हो जाते हैं
    सच में बेहतर होने वाले products बहुत कम हैं
  • संबंधित टिप्पणी पढ़ने के बाद ही समझ आया कि ऐसा क्यों होता है
  • Dropbox अपने मूल सरल उद्देश्य से भटक गया और फिर से एक जटिल network filesystem जैसा बन गया
    आखिर में उसने वही समस्या फिर से पैदा कर दी जिसे वह शुरुआत में हल करना चाहता था
  • पहले Task Eater नाम का एक सरल iOS to-do app था, जिसके developer ने घोषित कर दिया था कि “अब यह complete है” और updates बंद कर दिए
    लेकिन समय के साथ iOS version compatibility टूट गई और अंततः वह इस्तेमाल लायक नहीं रहा
    इससे completion की सुंदरता और technology evolution की क्रूरता, दोनों एक साथ महसूस हुईं

• 2020 में जब मैंने infra का काम छोड़कर Java developer के रूप में काम शुरू किया, तो कई प्रमुख libraries maintenance mode में थीं, इसलिए लगा “क्या Java मर चुका है?”
  लेकिन बाद में समझ आया कि वह दरअसल feature complete स्थिति थी
  अनगिनत edge cases सुलझाकर वह एक स्थिर अवस्था में पहुँच चुका था
  समस्या यह है कि लोग ऐसी stability नहीं चाहते, वे हमेशा कुछ नया चाहते हैं
  नतीजा यह होता है कि वही framework बस language बदल-बदलकर बार-बार बनाया जाता है

  • बहुत से लोग maintenance mode में चल रही library इस्तेमाल करने से डरते हैं कि कहीं bugs fix न हों
    इसलिए वे लगातार active development वाले projects को पसंद करते हैं
    कुछ कंपनियाँ तो compliance requirements की वजह से सिर्फ़ वही software इस्तेमाल कर सकती हैं जिसमें updates लगातार आते रहें
  • पहले एक Java memcached library maintenance mode में थी, इसलिए मैंने Redis पर switch किया था
    मज़ाक में कहा था, “शायद यह बस complete हो चुकी है, इसलिए सुधारने को कुछ बचा नहीं,” लेकिन आखिर में बदलना ही पड़ा

• मुझे Sublime Text उसकी सादगी और speed की वजह से पसंद है
  वह AI या जटिल features जोड़ने के बजाय एक ही उद्देश्य पर केंद्रित रहता है

  • इसी वजह से मैं अब भी vim इस्तेमाल करता हूँ

• अच्छा software ज़रूरी नहीं कि वही हो जो पैसा कमाए
  लेकिन पैसा कमाने के लिए ऐसे features चाहिए जिन्हें लोग सच में इस्तेमाल करें
  हर user अलग-अलग 20% features इस्तेमाल करता है, इसलिए विविधता का ध्यान रखना पड़ता है

• मुझे लगता था Notepad.exe complete software का एक प्रतिनिधि उदाहरण है,
  लेकिन Windows 11 में file association बदलने के लिए लगभग hacking जैसी प्रक्रिया चाहिए, यह देखकर हैरानी हुई

  • लेकिन कुछ लोग Notepad को खराब उदाहरण मानते हैं
    Windows Insider ब्लॉग और
    security advisory को देखें,
    तो उनके मुताबिक समस्या यह है कि updates रुकते ही नहीं

• मैं complete software की सुंदरता को मानता हूँ, लेकिन आजकल ज़्यादातर चीज़ें “perpetual beta” जैसी हैं
  internet connection को आधार मानकर यह ढाँचा बन गया है कि “कभी भी update किया जा सकता है”,
  और bug fixes तथा अनचाहे feature additions अलग-अलग नहीं रखे जाते
  YouTube जैसी web services में तो version चुनने का विकल्प भी नहीं है

  • मैं Evernote से Obsidian पर आ गया, लेकिन Obsidian भी धीरे-धीरे feature-heavy होता जा रहा है
    खासकर Canvas feature जुड़ने के बाद उसकी मूल सरल philosophy डगमगाने लगी
    अगर वह open source होता, तो शायद मैं उसी समय उसे fork कर देता

• Signal free, open source और privacy-focused है, इसलिए उसमें features कम हैं
  लेकिन यही बात मुझे पसंद भी है

  • फिर भी scheduled send feature एक ऐसी चीज़ है जो WhatsApp से कहीं ज़्यादा उपयोगी है
    WhatsApp बेकार के features ही बढ़ाता जा रहा है

• 37signals की किताब में कही गई ‘हमेशा ज़रूरी रहने वाली चीज़ों (evergreen)’, खासकर speed, की अहमियत पहले समझ नहीं आती थी
  लेकिन समय के साथ apps को और धीमा होते देखकर एहसास हुआ कि fast software की value कितनी बड़ी है

• Neal Stephenson की 『REAMDE』 में एक पंक्ति है: “लेखकों को बस्तियाँ पसंद होती हैं”
  जैसे लेखक अपनी बस्तियों को ज़िंदा रखने के लिए लगातार काम पैदा करते रहते हैं, वैसे ही developers में भी काम बनाए रखने के लिए code बदलते रहने की प्रवृत्ति होती है

  • “हमें codebase को पूरी तरह X architecture या Y language में rewrite कर देना चाहिए” जैसी बातें मैंने अनगिनत बार सुनी हैं
    आखिरकार हम भी सिर्फ़ बदलाव के लिए बदलाव दोहराते रहते हैं