मेरा सॉफ़्टवेयर North Star

सॉफ़्टवेयर विकास में प्राथमिकताएँ

1. सॉफ़्टवेयर अंतिम उपयोगकर्ता के लिए उपयोगी होना चाहिए, और इसका लक्ष्य "प्यार किया जा सकने वाला सॉफ़्टवेयर" बनना होना चाहिए
2. सॉफ़्टवेयर सही (correct) होना चाहिए। गलत तरीके से काम करने वाला सॉफ़्टवेयर उपयोगकर्ता को मिलने वाली उपयोगिता को कम कर देता है
3. सॉफ़्टवेयर मेंटेनेबल और efficient होना चाहिए। सॉफ़्टवेयर से अधिक उपयोगिता निकालने की कोशिश करते समय मानव और computing resources की बर्बादी से बचने के लिए यह एक मानदंड है

जब प्राथमिकताएँ उलट जाती हैं, तब उसकी निरर्थकता

• अगर blockchain में bug न भी हो, फिर भी यदि वह rugpull है, तो उसका कोई अर्थ नहीं
• जिस भाषा का आप उपयोग कर रहे हैं वह memory-safe हो, तब भी यदि उसमें correctness के लिए design नहीं है और आखिरकार हर bug को ठीक करते जाने की process नहीं है, तो उसका कोई अर्थ नहीं
• भले ही सॉफ़्टवेयर सुंदर abstraction layers की छतरी हो, अगर उसका कामकाज बेहद खराब है और कोई भी उसका maintenance नहीं कर सकता या उसमें नए feature नहीं जोड़ सकता, तो उसका कोई अर्थ नहीं

कभी-कभी मेरा उत्साह कम हो जाता है, कभी-कभी मैं गलत रास्ते पर चला जाता हूँ, और कभी-कभी जानबूझकर चक्कर लगाता हूँ, लेकिन कोई भी मुझे यह गलतफ़हमी नहीं दे सकता कि मेरी असली मंज़िल कोई नीची चीज़ है।
मैं अपने developer experience को महत्वपूर्ण मानता हूँ, लेकिन उतना ही, जितना वह मुझे ऐसा अधिक सॉफ़्टवेयर बनाने में मदद करता है जिसका आनंद दूसरे लोग और आप ले सकें।

• अंतिम लक्ष्य अंतिम उपयोगकर्ता की उपयोगिता को अधिकतम करना है, और बाकी सब कुछ उस लक्ष्य को हासिल करने के साधन हैं
  • सॉफ़्टवेयर विकसित करने में यही सबसे महत्वपूर्ण सिद्धांत है

[GN⁺]

Lobste.rs की राय

• मैं भी ऐसा ही नज़रिया पसंद करता हूँ
  screwdriver जैसी “प्यारी नहीं” लगने वाली चीज़ें भी बहुत लंबे समय तक बेहद विश्वसनीय हो सकती हैं। Phillips screwdriver हमेशा Phillips ही होता है; toolbox से निकालते समय उसके 1% संभावना के साथ flathead बन जाने और फिर वापस रखकर दोबारा निकालने जैसी नौबत नहीं आती। उसके handle का design भी लगातार नहीं बदलता, और खरीदा हुआ tool टूटने तक बस इस्तेमाल किया जा सकता है
  काश और ज़्यादा software भी ऐसे हो पाते

  • “screwdriver जैसी प्यारी नहीं लगने वाली चीज़” से आपका क्या मतलब है, यह जानने की जिज्ञासा है

• मैं उन developers का सम्मान करता हूँ और उनका आभारी हूँ जो इस सिद्धांत पर चलते हैं कि “अंतिम लक्ष्य end user की utility को अधिकतम करना है, और बाकी सब उसी लक्ष्य के लिए है”, लेकिन मैं खुद हमेशा ऐसा नहीं जी पाता। मुझे लगता है कि end user के अलावा भी software के प्रति कुछ वैध जवाबदेहियाँ होती हैं
  पेशेवर रूप से मैं अपने परिवार का पालन-पोषण करने के लिए software बनाता हूँ, और अक्सर users का पक्ष भी लेता हूँ, लेकिन आखिरकार मेरी निष्ठा पैसे देने वाली company और अपने परिवार के प्रति ज़्यादा होती है।
  व्यक्तिगत काम में मेरा मानदंड यह होता है कि “क्या यह काम मेरे लिए सार्थक है”, और कलात्मक, सौंदर्यात्मक, बौद्धिक संतोष महत्वपूर्ण होता है। आम तौर पर यह user के हित से मेल खाता है, लेकिन हो सकता है कि मैं user की utility का गलत आकलन करूँ, और मान लीजिए यह साबित भी हो जाए कि animated hamburger menu utility को अधिकतम करता है, तब भी मैं अपनी रचना में सौंदर्यात्मक पसंद की स्वतंत्रता का इस्तेमाल करके उस utility को त्याग सकता हूँ

  • और इन trade-offs से अलग, यह भी हमेशा स्पष्ट नहीं होता कि असली end user है कौन
    ऐसे मामलों को कैसे देखें, जहाँ user को जानबूझकर software के कुछ हिस्सों के प्रति unfriendly बनाया जाता है ताकि वह अपने users के साथ कोई बेहूदा नुकसानदेह काम न कर सके।
    Goodhart का नियम जिन खास reporting features पर बहुत आसानी से लागू हो सकता है और जिनके दुष्प्रभाव का दायरा भी बड़ा हो सकता है, उन्हें software users की इच्छा के बावजूद हमेशा “अभी उपलब्ध नहीं” की स्थिति में रखने के लिए जानबूझकर ऐसे उपायों पर चर्चा हुई थी

• यह पोस्ट पढ़कर ही मुझे पता चला कि Tiger Style की अब अपनी website भी है

• “जिसे कोई maintain नहीं कर सकता, नए features जोड़ना तो दूर की बात है” और “हर bug fix” दोनों बातें साथ कही गई हैं, लेकिन scope freeze के बिना हर bug को ठीक करने का तरीका आखिर संभव कैसे है, यह मुझे ठीक से समझ नहीं आता

• “अगर blockchain में bugs न भी हों, तो भी rug pull हो तो उसका कोई मतलब नहीं” — यह बात तीन अलग बातें एक ही वाक्य में समेट देती है
  किसी चीज़ की efficiency बढ़ाने का कोई अर्थ नहीं अगर उससे नए bugs पैदा हो जाएँ, और वह भी तभी अर्थपूर्ण है जब वह rug pull न हो

• यह बात ध्यान खींचती है कि software को ज़रूरी तौर पर सिर्फ इंसानों द्वारा ही लिखा जाना चाहिए, ऐसी कोई requirement यहाँ नहीं है। मुझे पता है कि Kristoff, Ziglang के core developers में से एक हैं, इसलिए यह और दिलचस्प लगता है
  मैं यह सोचना चाहूँगा कि AI-assisted development का इस्तेमाल करके भी इस requirement के मुताबिक software बनाया जा सकता है।
  खुद हाथ से code लिखना भी आनंद देता है, और उसे पूरा करना भी, लेकिन कभी-कभी ये दोनों टकरा जाते हैं।
  AI की बात छेड़ने के लिए माफ़ी, लेकिन Kristoff और Zig community के करीबी रिश्ते, Zig के मज़बूत रुख, और खैर, इस बात को देखते हुए कि मैं अब भी Ziglang का प्रचार करता रहता हूँ, इसे अलग करके देखना मुश्किल है

  • मेरे हिसाब से तीसरा बिंदु तो उल्टा ऐसे tools के ख़िलाफ़ संकेत करता है। ऐसे tools जो बनाते हैं, वह अक्सर maintain न हो सकने वाले spaghetti code जैसा दिखता है
  • शायद कोई वजह है कि यह लेख ziglang.org पर नहीं, बल्कि Loris के निजी blog पर आया है
    सिर्फ इसलिए कि किसी project का large language model-आधारित code के बारे में एक स्पष्ट रुख हो, इसका मतलब यह नहीं कि उस project के सभी लोग इस project या हर project में वही रुख साझा करते हों।
    यह सिर्फ Loris तक सीमित बात नहीं है; ऐसे फ़ैसलों में case-by-case judgment ही तर्कसंगत लगता है