कोड को पढ़े जाने से ज़्यादा चलाया जाता है

• “कोड को लिखे जाने से ज़्यादा पढ़ा जाता है” वाला सिद्धांत लेखक से अधिक मेंटेनर को प्राथमिकता देने की बात से शुरू होकर, user·operations·business तक को शामिल करने वाले decision-making model तक फैलता है
• कोड का मूल्य उसकी जटिलता में नहीं, बल्कि इस बात में है कि वह user के उद्देश्य को पूरा करता है या नहीं; इसलिए उसे जल्दी और बार-बार users को दिखाना और feedback को शामिल करना महत्वपूर्ण है
• production में कोड को “चलाने” का मतलब सिर्फ deploy करना नहीं, बल्कि deployment, upgrade, observation, audit, monitoring, fix, retirement तक की पूरी प्रक्रिया है; और long-term operations cost, development के दौरान होने वाली असुविधा से कहीं ज़्यादा बड़ी हो सकती है
• KISS सिर्फ code simplification तक सीमित नहीं रहता, बल्कि moving parts को घटाने और failure modes को समझकर failure के बावजूद system को काम करते रहने लायक बनाने वाले operational principle तक बढ़ता है
• budget, marketing, deadline, stakeholders, investors और राजनीतिक हित decision-making में शामिल होते हैं, इसलिए यह मानना ज़रूरी है कि users को खुश करना और revenue बनाना हमेशा एक ही बात नहीं होती

---

प्राथमिकता मॉडल का विस्तार

• “कोड को लिखे जाने से ज़्यादा पढ़ा जाता है” का मतलब है कि जो व्यक्ति आज कोड लिख रहा है, उसे भविष्य में उसे पढ़ने और बदलने वाले व्यक्ति की लागत को नज़रअंदाज़ नहीं करना चाहिए
• यही सिद्धांत simplicity, testing, documentation जैसी maintainability में निवेश करने का आधार बनता है
• संक्षेप में इसे maintainer > author मॉडल के रूप में देखा जा सकता है

user, developer से पहले आता है

• कोड किसी उद्देश्य के लिए एक साधन है, और software को किसी user को service देनी चाहिए
• चाहे कोड कितना भी अच्छा लिखा गया हो या technology कितनी भी परिष्कृत हो, अगर वह उद्देश्य पूरा नहीं करती और अच्छा user experience नहीं देती, तो उसका मूल्य घट जाता है
• प्राथमिकता user > maintainer > author तक फैलती है, और अगर developer roles को अलग न करें तो यह user > dev बन जाती है
• user क्या चाहता है, इसका अनुमान लगाने या सिर्फ पूछने के बजाय, program को जल्दी और बार-बार users के सामने रखना और feedback से सीखी बातों को शामिल करना बेहतर है

execution में production operations भी शामिल हैं

• “execution” सिर्फ program चालू करने की क्रिया नहीं, बल्कि production में उसे चलाने की पूरी प्रक्रिया है
  • deployment
  • upgrade
  • observation
  • audit
  • monitoring
  • fix
  • retirement
• Dan McKinley का Choose Boring Technology यह तर्क देता है कि system को लंबे समय तक स्थिर रूप से चलाते रहने की लागत, उसे बनाते समय होने वाली असुविधा से लगभग हमेशा बहुत अधिक होती है
• इस नज़रिए को जोड़ें तो मॉडल user > ops > dev बन जाता है
• बहुत-सा software कभी meaningful scale की production तक पहुँच ही नहीं पाता, और unvalidated assumptions पर बनाया जाता है
• production में कोड चलाने पर KISS सिर्फ code-level मुद्दा नहीं रह जाता, बल्कि moving parts को कम करने और failure modes को समझने का सवाल बन जाता है
• महत्वपूर्ण बात है कुछ deploy करना, और यह सुनिश्चित करना कि failure होने पर भी वह काम करे

business एक अलग axis है

• users को ध्यान में रखकर development करना बहुत दूर तक ले जा सकता है, लेकिन “जो software users के लिए valuable है, वही organization के लिए भी valuable होगा” यह एक सरल किया हुआ abstraction है
• developer के नज़रिए से अच्छा software बनाना और business का उसे पैसे में बदलना अलग-अलग लग सकता है, लेकिन अंततः काम की प्रक्रिया में business perspective को शामिल करना पड़ता है
• यह विभाजन consumer software और enterprise software दोनों में मोटे तौर पर काम करता है
• मॉडल biz > user > ops > dev तक फैलता है
• budget इसका सबसे स्पष्ट उदाहरण है, क्योंकि user की ज़रूरतें पूरी करने के लिए resources असीमित नहीं होते, इसलिए cost और benefit को मापना पड़ता है
• marketing, deadlines, stakeholders, investors, personal interests और politics भी decisions को प्रभावित करते हैं
• software, team और users को अलग रखकर जो decision सही लगता है, वह पूरे organization को देखें तो सही न भी हो सकता है
• कभी-कभी users को खुश करने से ज़्यादा revenue बनाने वाला काम करना पड़ता है

इस मॉडल से दिखने वाली development organization की bad smells

• maintain न किया जा सकने वाला code: author > maintainer

  • चालाक लेकिन आलसी code, spaghetti और “ghost forest” में बदल जाता है
  • इसमें premature optimization और ऐसे modules जैसी समस्याएँ शामिल हैं जिन्हें सिर्फ कुछ खास लोग ही छू सकते हैं

• उपयोग न किया जा सकने वाला software: dev > user

  • यह उन teams से आता है जो users से नहीं सीखतीं या technology को प्राथमिकता देती हैं
  • over-engineered programs, user experience को खराब करने वाली “modernization”, और browser features तोड़ने वाले web apps इसके उदाहरण हैं

• “मेरे कंप्यूटर पर तो चलता है”: dev > ops

  • ऐसा software जिसे operations को ध्यान में रखकर design नहीं किया गया
  • इसमें छोटी data load के लिए चमकदार database का उपयोग, या एक छोटी team द्वारा microservices ecosystem चलाने जैसी अत्यधिक complexity शामिल होती है
  • वह software भी इसमें आता है जिसमें outage होने पर रात में जगाया जाने वाला व्यक्ति और system design करने वाला व्यक्ति अलग-अलग हों

• “सही काम”: dev > biz

  • जब code को अपने-आप में ही उद्देश्य की तरह लिया जाता है
  • दिखावे वाले craftsman, Titanic के musicians, और Lisp Hackers इसके उदाहरण हैं

• resume-driven development: dev > *

  • ऐसा software जो तब बनता है जब कोई दाँव पर न हो और developers अपनी पसंद से सब कुछ कर सकें

• काल्पनिक software: biz > user > ops > dev

  • ऐसा software जो बना तो दिया गया, लेकिन लगभग या बिल्कुल भी production में नहीं गया
  • Charity Majors इसे living a lie कहती हैं
  • users के बिना software भी इसी में आता है; यानी ऐसा software जो कोई समस्या हल नहीं करता, गलत समस्या हल करता है, या ऐसी समस्या हल करता है जो किसी के पास थी ही नहीं
  • इसमें वह स्थिति भी शामिल है जहाँ बढ़ा-चढ़ाकर पेश की गई technology से हर चीज़ पर चोट की जाती है और अंत में कुछ धुँधला-सा use case निकलता है

• “late-stage capitalism”

  • जब venture-funded software का कोई business model नहीं होता, या monopoly तक बढ़ने के बाद users का शोषण करने वाला business model होता है

user और business के बीच तनाव

• biz > user के असर स्वीकार करना मुश्किल है
• software सीखने का पारंपरिक तरीका end user की समस्या हल करना था, और The Pragmatic Programmer की आख़िरी सलाहों में से एक का सार यह है कि सिर्फ code deliver मत करो, बल्कि user को प्रसन्न करो
• जैसे-जैसे software सर्वव्यापी हुआ है, इस धारणा को बनाए रखना कठिन होता गया है
• बहुत-सा software users की परवाह नहीं करता, उन्हें manipulate करता है, या users को ही product बना देता है
• यह समस्या सिर्फ social media तक सीमित नहीं है
  • room booking, food ordering, और Windows के Start button पर click करते समय भी user का ध्यान खींचने वाले pop-ups सामने आते हैं
  • Google search के बारे में इसे कूड़े के ढेर जैसे results मिलने के रूप में कहा गया है
• यह असंगति—एक तरफ यह विश्वास कि हम अच्छा काम कर रहे थे, और दूसरी तरफ industry के बड़े हिस्से द्वारा profit को प्राथमिकता देना—कई software professionals की बेचैनी को समझाती है
• हम उस अतीत में वापस नहीं जा सकते जहाँ आर्थिक वास्तविकताओं को नज़रअंदाज़ किया जाता था, लेकिन users को नुकसान न पहुँचाने के लिए एक अधिक मजबूत ethical stance की ज़रूरत है
• user हमेशा business से पहले नहीं आ सकता, लेकिन business भी हर बार अपने-आप पहले नहीं आना चाहिए
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

Hacker News की राय

• कुछ उपयोगकर्ता किसी सिस्टम को इसलिए नहीं इस्तेमाल करते कि उन्हें वह पसंद है, बल्कि इसलिए क्योंकि कंपनी ने उसे खरीदा है
  ऐसी स्थिति में परिभाषा के अनुसार business, users से ऊपर होता है, और developers वास्तविक users की बजाय ग्राहक कंपनी के middle managers की मांगों के हिसाब से काम करने लगते हैं। वरना contract नहीं मिलता। नतीजतन users को आधे-अधूरे दिए गए features के साथ ही काम चलाना पड़ता है, जबकि development team उन नए features को बनाने में व्यस्त रहती है जो middle managers को पसंद आएँ
  यह थोड़ा cynical लग सकता है, लेकिन एक engineer के तौर पर यह जानना मददगार है कि आप मूल रूप से ऐसी ही किसी कंपनी में हैं या नहीं। उदाहरण के लिए online retailers users के प्रति बहुत sensitive होते हैं, इसलिए वे यह देखते हुए कि जर्मनी के लोग X पसंद करते हैं और अमेरिका के लोग Y, देश के हिसाब से वेबसाइट के अलग-अलग versions भी रखते हैं। क्योंकि छोटे बदलाव भी revenue में बड़ा फर्क ला सकते हैं
  दूसरी ओर कुछ कंपनियाँ usability के प्रति लगभग बिल्कुल sensitive नहीं होतीं, क्योंकि product खरीदने वाला व्यक्ति वास्तविक user नहीं होता

  • मैंने ऐसी कंपनी में काम किया है जो बड़े enterprises को SaaS बेचती थी
    contract जीतने के लिए हमें ग्राहक की checklist पूरी करनी पड़ती थी, लेकिन हम user experience का भी ध्यान रखते थे। अच्छा user experience शायद ही कभी ग्राहक की सख्त requirement होता था
    competitor software इस्तेमाल करने में बहुत तकलीफ़देह था, इसलिए हम उसी पहलू में अलग पहचान बनाना चाहते थे। उसका फायदा यह हुआ कि training आसान हुई, users ज़्यादा संतुष्ट रहे, और जहाँ संभव हुआ वहाँ उन्होंने अपने managers से हमारी product और खरीदने की recommendation भी की
    आखिरकार इसका 80% हिस्सा “हमारा software इतना भी खराब नहीं है” वाली गर्व की भावना और empathy से आया था, लेकिन लंबे समय में यह हमारे लिए भी फ़ायदेमंद था क्योंकि इससे brand बनता है
  • मैंने ऐसे बाज़ार की एक कंपनी में काम किया है जहाँ खरीद की संरचना मिलती-जुलती थी, लेकिन हम सिर्फ users पर ध्यान दे रहे थे
    हमने product-led growth strategy अपनाई थी, इसलिए कोई salespeople नहीं थे, और product team पूरी तरह user experience पर केंद्रित थी। समस्या यह थी कि हम users को बेच ही नहीं रहे थे। software खरीदने वाले लोग user organization के भीतर कोई और लोग थे, और उन्होंने खुद product इस्तेमाल भी नहीं किया था
    यह approach शुरू से ही असफल होने वाली थी। ऐसे salespeople चाहिए थे जो buyers की सोच समझें, उन्हें benefits समझाएँ, और users को यह सिखाएँ कि वे उसी benefit को अपनी organization के दूसरे लोगों को कैसे समझाएँ। user और buyer के बीच की खाई पाटनी ज़रूरी थी
  • आम तौर पर middle managers भी users होते हैं, लेकिन पूरे user base में वे अल्पसंख्यक होते हैं और जिन features का वे उपयोग करते हैं, जैसे reports, वे अलग होते हैं
    इसलिए सवाल यह बन जाता है कि किस user को प्राथमिकता दी जाए, और इस बात के बीच संतुलन खोजना पड़ता है कि बाकी users पर प्रभाव रखने वाले उस छोटे समूह के अनुभव को प्राथमिकता दी जाए, या बाकी users product का इतना उपयोग कर सकें कि management को अर्थपूर्ण data मिलता रहे
  • मैंने यह स्थिति उस कंपनी में देखी जो city governments को software बेचती थी
    वहाँ सिर्फ mayor, town manager और city council की राय मायने रखती थी। अगर reports अच्छी दिखतीं और कीमत सही होती, तो renewal हो जाता था
    मुझे याद है कि onsite meetings में रोज़ाना इस्तेमाल करने वाले लोग हमारे सामने कहते थे कि यह कितना भयानक है। फिर भी बिना किसी अपवाद के, कुछ खास bugs ठीक करने के वादे और न्यूनतम price increase के साथ वह ग्राहक renewal कर देता था
  • यही वजह है कि developers वास्तविक users की बजाय ग्राहक कंपनी के middle managers की मांगों के मुताबिक काम करते हैं, और enterprise software पूरा का पूरा खराब होता है

• आज मुझे ≹ यह symbol पता चला। कहा गया कि इसका अर्थ है “ऐसा संबंध जिसमें तुलना की जा रही दो चीज़ों में से कोई भी दूसरी से न बड़ा है न छोटा, लेकिन यह ज़रूरी नहीं कि वे बराबर ही हों। यह उन क्षेत्रों में एक महत्वपूर्ण सूक्ष्म भेद है जहाँ तुलना हमेशा सख्ती से संख्यात्मक नहीं होती” (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • complex numbers z_1, z_2 के लिए z_1 ≹ z_2 वाला उदाहरण अजीब लगता है
    इसकी बजाय |z_1| = |z_2|, यानी दोनों complex numbers का absolute value समान है, ऐसा लिखना ज़्यादा स्पष्ट लगता है
    वहाँ लिखा है, “निष्कर्षतः ≹ symbol पारंपरिक relational operators के बीच के मध्य क्षेत्र को उपलब्ध कराने में महत्वपूर्ण भूमिका निभाता है,” लेकिन मैं mathematics PhD student हूँ और मैंने इसे कभी नहीं देखा। यह मानना मुश्किल है कि इसकी कोई महत्वपूर्ण भूमिका है
  • यह glyph ऐसा लगना चाहिए जैसे apple emoji और orange emoji को जोड़कर बनाया गया हो
  • इससे combinatorial game theory में game की अवधारणा याद आती है
    games, surreal numbers का superset हैं, और surreal numbers, real numbers का superset हैं। यहाँ surreal numbers की definition को ढीला कर दिया जाता है, जिससे total order property खो जाती है
    इस कारण कुछ अजीब संख्याएँ बनती हैं जो दूसरी संख्याओं से “confused” हो सकती हैं या fuzzy होती हैं। सबसे सरल उदाहरण * (star) है, जो 0 से न बड़ा है न छोटा, इसलिए 0 से confused होता है। यह 0 के आसपास एक fuzzy cloud जैसा है, और इसे 0║* लिखा जाता है
    इससे जटिल games जैसे switches, बड़े number intervals के साथ confused हो सकते हैं और उन्हें “hot” माना जाता है। switches से numbers बनाकर और भी दिलचस्प hot games बनाए जा सकते हैं
  • मुझे लगता है कि यह अवधारणा distributed systems में causal ordering को समझने के लिए महत्वपूर्ण है। उदाहरण के लिए CRDT के संदर्भ में
    एक ही device पर बने events हमेशा पूरी तरह ordered होते हैं। लेकिन अगर दो offline devices पर events बनते हैं, तो यह नहीं कहा जा सकता कि कौन पहले हुआ, और उन दोनों events के बीच ≹ संबंध बनता है। दूसरे शब्दों में, उन्हें concurrent माना जाता है
    इसलिए “d > b > a” और “d > c > a” जैसी ordering हो सकती है, लेकिन “c ≹ b” होगा
    ऐसे मामलों में tie-breaking को deterministic ढंग से कैसे किया जाए, यह तय करना CRDT जिन समस्याओं को हल करता है, उनका बड़ा हिस्सा है
  • लिंक के “उदाहरण 1: संख्यात्मक संदर्भ” में दो real numbers a और b दिए गए हैं, और कहा गया है कि अगर a, b से न बड़ा है न छोटा, लेकिन स्पष्ट रूप से बराबर भी नहीं है, तो संबंध ≹ है
    यह कैसे संभव है?

• हममें से काफ़ी लोगों के लिए कोड को 1 अरब बार चलाने की लागत, डेवलपर के कुछ मिनटों के समय से कम हो सकती है
  AWS पर महीने का सर्वर खर्च 200 डॉलर हो तो मेरे web API कोड का बड़ा हिस्सा 100 अरब बार भी चलाया जा सकता है
  इसलिए इंसानी पाठकों के लिए optimization करना हमेशा बेहतर है, और दूसरी optimization तभी करनी चाहिए जब यह साबित हो जाए कि वह आर्थिक रूप से अस्वीकार्य स्तर तक धीमा है

  • लेखक भी शायद यही सोचता है, लेकिन लगता है उसने शीर्षक कुछ उलझाने वाला चुना
    लेख का अंत कुछ इस तरह होता है:
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    निष्कर्ष यह लगता है कि कोड का अस्तित्व अंतिम उपयोगकर्ता और business, दोनों के लिए है। आख़िरी चिह्न ≹ यह साफ़ तरीके से दिखाता है कि अंतिम उपयोगकर्ता और business की ज़रूरतें एक जैसी नहीं हैं, लेकिन कोड के अस्तित्व के लिए दोनों समान रूप से महत्वपूर्ण हैं
  • “डेवलपर समय से कम लागत” वाली गणना की समस्या अक्सर यह होती है कि वह लागत चुकाने वाला व्यक्ति खुद वह नहीं होता
    उपयोगकर्ता यह कीमत कम स्पष्ट तरीकों से चुकाते हैं, जैसे ज़्यादा बिजली बिल, कम हुई उम्र[0], खोए हुए मौके, अधिक निराशा, और बार-बार hardware upgrade
    ऊपर से, ज़्यादातर उपयोगकर्ताओं के पास डेवलपर जैसी salary या जीवन-गुणवत्ता नहीं होती, इसलिए यह नुकसान उन पर कई गुना ज़्यादा भारी पड़ता है
    [0] किसी और का समय बर्बाद करना QALY कम करना है
  • लेख में “चलाना” का मतलब सिर्फ़ program execute करना नहीं है
    इसमें production में चलाना भी शामिल है, यानी deployment, upgrade, observation, audit, monitoring, fixing, retirement आदि सब
  • मेरे अनुभव में latency पर ध्यान देना चाहिए। क्योंकि इसका असर user experience पर पड़ता है। बेहतर latency को पैसे से खरीद पाना काफ़ी मुश्किल है
  • मुझे लगा था प्रतिक्रिया कुछ ऐसी होगी। लेकिन यह लेख कुछ और है। एक बार पढ़ने लायक है

• शीर्षक के निष्कर्ष को लेखक की ओर पलटकर कहें तो, “कोड लिखा जाने से ज़्यादा पढ़ा जाता है” से ज़्यादा सही बात शायद यह है कि जो कोड पढ़ा नहीं जा सकता, वह लंबे समय तक चल नहीं पाता
  हालाँकि, मैं development में lateral move करना चाहने वाला एक अनुभवी system administrator हूँ, और उस अर्थ में बिल्कुल beginner हूँ

  • बहुत सारा जमा हुआ कोड ऐसा है जिसे लोग समझ नहीं पाते, इसलिए छूने से डरते हैं, लेकिन business उसी पर टिका होता है
  • source के बिना proprietary software, जैसे third-party library या लगभग हर black-box system, उस निष्कर्ष के counterexample हैं
  • शायद पूरी financial industry इससे सहमत न हो। और क्या आप retirement से थोड़ी देर के लिए लौटकर दूसरे developers को अपना COBOL code समझाने वाले हैं?
  • सही infrastructure हो तो वह चलता रह सकता है
    ज़्यादा सटीक रूप से कहें तो, “जो कोड पढ़ा नहीं जा सकता, वह लंबे समय तक modify करने लायक नहीं रहता”
  • यह बुरा point नहीं है, लेकिन ज़्यादा अलग विषय जैसा है
    जब तक बात जानबूझकर obfuscation की न हो, ज़्यादातर कोड वह व्यक्ति पढ़ सकता है जो मेहनत करने को तैयार हो, और ज़रूरत पड़े तो code formatter भी है

• यहाँ एक और निष्कर्ष जोड़ने लायक है। नीचे दिए गए हर चरण के बीच उपयोग की संख्या घातीय रूप से बढ़ती है

  1. भाषा डिज़ाइनर और standard library developer
  2. shared module या library developer
  3. सामान्य developer
  4. अंतिम उपयोगकर्ता
     कई भाषाओं में हर चरण का अनुपात लगभग 1000 गुना के आसपास हो सकता है, इसलिए 1 भाषा डिज़ाइनर पर 1000 module डिज़ाइन और publish करने वाले, 10 लाख developer, और 100 करोड़ उपयोगकर्ता हो सकते हैं। स्थिति के अनुसार संख्या बहुत बदल सकती है, लेकिन गुणात्मक चर्चा के लिए यह मोटा पैमाना ठीक है
     मूल बात यह है कि पहले या दूसरे चरण की बहुत छोटी लापरवाही नीचे की तरफ़ नाटकीय रूप से कई गुना बढ़ जाती है। चरण 1 में “अपनी सुविधा” के लिए बचाया गया 1 मिनट का गंदा hack, सचमुच दूसरों की कीमती ज़िंदगी के लाखों घंटे बर्बाद कर सकता है। क्योंकि वह लोगों को धीमे software का इंतज़ार कराता है, crash से निराश करता है, या चरण 2 और 3 में feature development धीमा करके लोगों को प्रतीक्षा में रखता है
     पहले दो चरणों में ज़रूरी quality level बनाए रखने के लिए बहुत बड़ी self-discipline और व्यक्तिगत ethics चाहिए। उल्टा, जब भी मैं core language या standard library design के बारे में ऐसे रुख़ का बचाव सुनता हूँ जिसे सही नहीं ठहराया जा सकता, तो गहरा दुख होता है
     हम अक्सर ऐसी बातें सुनते हैं जैसे, “अगर तुम बस इस नुकीले हिस्से का पूरा इतिहास जान लो तो सब ठीक है! हमेशा सावधान रहो तो कोई समस्या नहीं। जब तक इसका गलत इस्तेमाल न करो, यह unsafe, security risk, slow, या problematic नहीं है” — और यह इसलिए दुख देता है क्योंकि पता है कि ऐसी चीज़ें आने वाले दशकों तक developers को गिराती रहेंगी और लाखों-करोड़ों लोगों के software को धीमा बनाती रहेंगी

• लगता है लेखक ने काफ़ी ठीक-ठाक अनुभवजन्य नियम लेकर theory of everything बनाने की कोशिश की है
  यह साफ़-सुथरा और बुद्धिमान लगता है, लेकिन थोड़ी ज़बरदस्ती वाली भाषा हटाएँ तो यह काफ़ी हद तक वही पुरानी, सबको मालूम बातों की दोहराई हुई chewing है

  • theory > /dev/null
  • मैंने “ज़बरदस्ती वाली भाषा” कहा, लेकिन हमें अक्सर यह याद रखने की ज़रूरत है कि इस उद्योग में बहुत से लोग ऐसे हैं जो न तो native English speaker हैं और न ही English-speaking देश में रहते हैं, फिर भी अंग्रेज़ी में लिखने की कोशिश करते हैं
    इसलिए अभिव्यक्ति थोड़ी अटपटी हो सकती है
    और “सबको मालूम घिसी-पिटी बात” होने पर भी, यह लेख उन्हें ख़ास तौर पर एक बहुत सुसंगत तरीके से जोड़ता है, इसलिए उपयोगी reference material बन जाता है
  • मेरा मानना है कि अनुभवजन्य नियमों में variation लाने, और उस variation के ज़रिए उन चीज़ों को फिर से देखने और संदर्भ में रखने में भी मूल्य है जिन्हें हम पहले से जानने का दावा करते हैं
    किसी के लिए सब कुछ नया हो सकता है, और भले ही इसने सिर्फ़ मेरी अपनी bias की पुष्टि की हो, फिर भी यह एक दिलचस्प नज़रिया था
  • ज़्यादा सटीक रूप से कहें तो यह software development में गड़बड़ हो सकने वाली हर चीज़ की theory of everything है। फिर भी पढ़ने में दिलचस्प था
  • क्या आपने इसे अंत तक पढ़ा? बाकी सब तो सिर्फ़ background story है

• लेखक की framing इतनी तरह से गलत समझी जा सकती है कि इसे उपयोगी shorthand कहना मुश्किल है। इन tokens के बीच कोई निरपेक्ष ranking हो ही नहीं सकती
  सबसे पहले, यहाँ “dev” एक व्यक्ति नहीं है, बल्कि कई संगठनों की product, engineering और design teams में फैले, अलग-अलग विशेषज्ञता और अनुभव-स्तर वाले लोगों का समूह है
  “ops” भी कोई एक चीज़ नहीं है, और इसका मतलब सिर्फ engineering operations नहीं है। इसमें business operations, customer support आदि भी शामिल हो सकते हैं
  “biz” भी एक नहीं है। इसमें branding, marketing, sales, legal, executives, board, regulators, lenders और investors शामिल होते हैं
  ये सभी लोग इस बात को प्रभावित करते हैं कि कौन-सा code लिखा जाता है, वह कैसे लिखा जाता है, और कब व कैसे users तक deploy किया जाता है। सभी को एक ही समस्या हल करनी होती है
  किसी संगठन में बहुत से लोगों की भूमिका ही इस बात को सुनिश्चित करना होती है कि सब लोग एक ही समस्या को समझें, उसे देखें, और एक ही लक्ष्य की ओर काम करें
  लेकिन यह समझ लगातार बदलती रहती है, और पूरे संगठन में फैलने में देरी होती है। इसलिए जब लक्ष्य खुद बदल रहा हो, तब सबका उसी लक्ष्य की ओर काम करना भी देरी का शिकार होता है
  आखिर में, “user” भी कोई एक नहीं है, और कोई भी user group स्थिर नहीं होता। अलग-अलग user groups होते हैं, और उनका व्यवहार लंबे समय में स्थिर रहे, यह ज़रूरी नहीं
  इसलिए यह समझना और स्वीकार करना मददगार है कि आपके आसपास के सारे variables कैसे बदलते हैं, और उसी संदर्भ में इस अपूर्ण और टूटी हुई दुनिया की व्याख्या करनी चाहिए। नहीं तो आसानी से यह सोच बन जाती है कि बाकी सब लोग निकम्मे हैं, सब कुछ टूटा हुआ है, और सब कुछ शुरू से फिर से बना देना चाहिए

• यह देखकर अच्छा लगा कि चर्चा नैतिकता के करीब पहुँच रही है
  लेख में जहाँ कहा गया है, “जो हम अच्छा काम मानते थे और जिसे industry का बड़ा हिस्सा profitable समझता है, उनके बीच असंगति है, और मेरा मानना है कि यही कई software professionals की बढ़ती बेचैनी का कारण है”, वहाँ बेचैनी काफ़ी हल्का शब्द है। बहुत-सी बातें अनकही रह जाती हैं
  मैं कुछ सवाल जोड़ना चाहूँगा। जब user, customer यानी पैसे देने वाला व्यक्ति न हो, तब क्या होता है? क्या business की नैतिक ज़िम्मेदारी सभी users के प्रति होती है, उन users सहित जो पैसे नहीं देते? अगर paying customer आपके business का इस्तेमाल ऐसे तरीक़े से करना चाहे जिससे users पर नकारात्मक downstream effects पड़ें, तब क्या होगा?
  उदाहरण के लिए, अगर कोई platform मौजूदा विकल्पों की तुलना में fraud को आसान बना दे, misinformation फैलाना आसान कर दे, या users की राय को लंबे समय में विनाशकारी लेकिन आकर्षक और आदत डालने वाले तरीक़ों से shape करना आसान कर दे, तो क्या? यह सब एक समयावधि तक सफल business model साबित हो चुका है
  अगर ये dynamics वास्तविक हैं, तो क्या business को ऐसे exploitative models अपनाने चाहिए? अगर अपनाने चाहिए, तो क्या उन्हें ज़्यादा ज़िम्मेदारी से अपनाया जा सकता है? क्या business का कोई अधिक ethical version competitors की सबसे ख़राब प्रवृत्तियों को कम कर सकता है, या वह अंततः खुद भी समस्या का हिस्सा बन जाता है?
  मुख्य निष्कर्ष साफ़ है। कुछ तरह की समस्याएँ business model से बड़ी और ज़्यादा महत्वपूर्ण होती हैं। ऐसी समस्याएँ होती हैं जिन्हें इस तरह गढ़ा जा सकता है: “कंपनियों को कुछ बुनियादी समझदारी की सीमाओं के भीतर काम करने के लिए कौन-से norms और rules चाहिए?”
  अंत में, मैं एक बात स्पष्ट करना चाहता हूँ। business स्वभाव से ही कुछ मूल्य पहुँचाता है, और इससे बचा नहीं जा सकता। भले ही आप सिर्फ “लोकप्रियता जीतती है” वाला रुख़ लें, वह भी अपने आप में मूल्यों पर गहरे असर वाला चुनाव है। political scientists और historians बहुत पहले से बहुमत की तानाशाही की समस्या को जानते रहे हैं। आपकी political philosophy जो भी हो, इस पर सोचना चाहिए
  मुझे नहीं पता “सबसे अच्छा” ethical framework कौन-सा है, लेकिन इतना जानता हूँ कि कुछ ethics, दूसरी ethics से बेहतर होती हैं। और मैं चाहता हूँ कि हम ethics को बिना जाँचे-परखे छोड़ देने के बजाय उन्हें लगातार बेहतर बनाते रहें

  • मुझे लगता है कि यह लेख जिस समस्या की बात कर रहा है, उससे अलग समस्या है
    आप यह चुन सकते हैं कि कौन-सी समस्याएँ और क्षेत्र आपकी ethics से मेल खाते हैं। यह लेख इस बारे में है कि systems कैसे बनाए जाते हैं और काम की priorities कैसे तय की जाती हैं

• बिज़नेस वास्तव में कोई ठोस चीज़ नहीं है; यह संसाधनों को संगठित करके साथ काम करने के लिए हमारे द्वारा बनाया गया एक कल्पित ढाँचा है
  बिज़नेस सबसे बढ़कर महत्वपूर्ण नहीं है। यूज़र कई होते हैं और कभी-कभी उनके हित आपस में टकराते हैं। हम हर जगह नहीं हो सकते और सब कुछ नहीं बन सकते, इसलिए प्राथमिकताएँ तय करनी पड़ती हैं। ज़्यादा लाभदायक यूज़रों या दीर्घकालीन रणनीति से मेल खाने वाले यूज़रों का पीछा करना “बिज़नेस के लिए अच्छा” लग सकता है, लेकिन असल लक्ष्य यूज़रों की सेवा करना ही है। बस वहाँ तक पहुँचने में कुछ अतिरिक्त चरण होते हैं
  अगर आंतरिक राजनीति इतनी उलझ जाए कि फैसले यूज़र की खुशी तक कैसे पहुँचते हैं यह देखे बिना सिर्फ बिज़नेस के हित में लिए जाने लगें, तो संगठन विषाक्त हो चुका है। फिर उसका अस्तित्व नहीं होना चाहिए। वह कुछ समय तक ज़ॉम्बी की तरह लड़खड़ाते हुए चल सकता है, लेकिन वह गिरावट में है और अच्छे लोग सब छोड़कर चले जाएँगे

  • यह कहना कि बिज़नेस वास्तव में मौजूद नहीं है, कुछ वैसा ही है जैसे कहना कि भावनाएँ मौजूद नहीं हैं
    यह कहा जा सकता है कि भावनाएँ भी केवल स्थितियों के प्रति प्रतिक्रियाओं को समझाने के लिए बनाया गया एक ढाँचा हैं, लेकिन सिर्फ इसलिए कि वे परमाणुओं से बनी नहीं हैं, इसका मतलब यह नहीं कि वे “वास्तविक” नहीं हैं
    बिज़नेस इतना तो वास्तविक है कि वह अधिकांश लोगों के जीवन को तय करने वाला प्रमुख कारक है। वह शहरों, मीडिया, क़ानून, राजनीति और विदेश नीति को आकार देता है, और लगभग हर महत्वपूर्ण चीज़ पर बड़ा असर डालता है। वह वास्तविक हो या न हो, हमारे आसपास ठोस प्रभाव डालता है
    open source के बाहर यह काफ़ी स्पष्ट है कि भुगतान करने वाला पक्ष यह तय करता है कि क्या बनाया जाएगा। चाहे वह निर्णय उसी पक्ष के लिए बुरा हो, यूज़रों के लिए बुरा हो, आम जनता के लिए या पर्यावरण के लिए बुरा हो। बेशक उद्योग और सरकारी नियमन होते हैं, लेकिन आम तौर पर फ़ैसला कंपनी ही करती है
  • यह सही नहीं है। बिज़नेस एक कानूनी संरचना के रूप में मौजूद है, और ऐसी बहुत-सी चीज़ें हैं जो बिज़नेस के लिए अच्छी लेकिन लगभग सभी के लिए बुरी होती हैं। साथ ही, बिज़नेस यूज़रों की सेवा करने के लिए मौजूद नहीं होता
    दुर्भाग्य से, बिज़नेस मालिकों की सेवा करने के लिए मौजूद होता है। ज़्यादातर मामलों में, खासकर 5 लोगों से कम वाले अति-छोटे धंधों को छोड़कर बड़ी कंपनियों में, मालिक पैसे चाहते हैं, इसलिए कंपनी में हर व्यक्ति मालिकों के लिए अधिक पैसा कमाने के लिए मौजूद होता है। दूसरे लोगों की खुशी, यहाँ तक कि यूज़रों की खुशी भी, तब तक पूरी तरह अप्रासंगिक है जब तक उसका राजस्व से संबंध न हो
    कंपनी के भीतर एक और सार्वभौमिक प्रोत्साहन आत्म-सुरक्षा है। इसलिए निर्णय लेने वाले लोग पैसा कमाने के अलावा अपनी नौकरी की सुरक्षा भी देखते हैं
    कर्मचारी छोड़कर नहीं जाते। ऐसा इसलिए क्योंकि कंपनी उन्हें पर्याप्त संतुष्ट रखती है। अच्छा पैसा देकर और उन्हें “समुदाय” का हिस्सा महसूस कराकर, किसी बुरी या बेनाम संस्था में भी लोगों से काम करवाते रहना हैरान कर देने वाली हद तक आसान है। FAANG दफ़्तरों को देखें तो ऐसे HR ट्रिक्स की पूरी सूची मिल जाएगी
    मैं इस बात से सहमत हूँ कि ऐसी कंपनियाँ विषाक्त हैं और उनका अस्तित्व नहीं होना चाहिए, लेकिन व्यवहार में कंपनियाँ ऐसे ही चलती हैं। यह पतन का संकेत नहीं, बल्कि एक परिपक्व और स्वस्थ बिज़नेस की शक्ल है जो दशकों तक चल सकती है। executives बदलते हैं, products बदलते हैं, owners बदलते हैं, लेकिन बिज़नेस बना रहता है
  • शुरुआत में मेरी भी यही प्रतिक्रिया थी। जब कोई लेख पैसा > लोग में समेटा जा सके, तो वह ग़लत लगता है
    लेकिन महत्व व्यक्तिपरक होता है। अगर यह सिर्फ अपने आनंद के लिए लिखा गया निजी code है, तो बिज़नेस महत्वपूर्ण नहीं है। अगर आप उसे अपनी मुख्य आय का स्रोत बनाना चाहते हैं, तो बिज़नेस सबसे महत्वपूर्ण है। क्योंकि अगर software किसी की सेवा नहीं कर पाता, तो यूज़र उसे कितना भी पसंद करें, वह वास्तविक राजस्व में नहीं बदलेगा
  • यहाँ “बिज़नेस” का अर्थ उदारता से “ऐसा टिकाऊ funding model जो maintenance, support और future development को सहारा दे सके” मान लेते हैं
    बिज़नेस मॉडल के बिना, ऐसा शानदार software भी जो यूज़रों को पसंद आए, deploy किया जा सके और maintain किया जा सके, धीरे-धीरे समाप्त हो सकता है

• शुरुआत में मैं सशंकित था, लेकिन मुझे यह सोचने का मॉडल पसंद आया
  बेशक इसका आँख मूँदकर पालन नहीं करना चाहिए। dev > biz वाले अपवाद भी हैं, OpenAI वाली घटना ऐसा ही मामला है, और dev > ops वाले अपवाद भी हैं। शुरुआती startup में तेज़ी से चलना पड़ता है, इसलिए खासकर बिज़नेस कारणों से dev > ops हो सकता है