भले ही आप पूरे codebase को पूरी तरह न समझें, यह ठीक है

• करोड़ों लाइनों वाले बड़े सिस्टम को कोई भी व्यक्ति पूरी तरह अपने दिमाग में नहीं रख सकता, इसलिए engineers को आंशिक लेकिन पर्याप्त रूप से सही समझ के साथ भी प्रभावी ढंग से काम कर पाना चाहिए
• Peter Naur का Programming as Theory Building यह मानता है कि अगर मौजूदा टीम की समझ खत्म हो जाए, तो program को छोड़कर नया बनाना बेहतर है, लेकिन users और अनगिनत exceptions से उलझे बड़े सिस्टम को शुरुआत से फिर बनाना कठिन होता है
• जिन codebase के सभी जिम्मेदार लोग जा चुके हों, उन्हें भी एक flow को शुरू से अंत तक समझकर और फिर सावधानी से बदलाव की सीमा बढ़ाते हुए फिर से जीवित किया जा सकता है; बड़े संगठनों में ऐसी समझ की पुनर्रचना बार-बार होती रहती है
• LLM एक ओर विस्तृत mental model बनाने में बाधा डालते हैं, तो दूसरी ओर आंशिक समझ को जल्दी बनाने और उपयोग करने में मदद भी करते हैं; collaboration, कानूनी आवश्यकताएँ, security updates, और dependencies अपनाने जैसे काम भी code की समझ और अन्य मूल्यों के बीच समझौता मांगते हैं
• सटीक mental model आनंददायक और स्थिर development में मदद करता है, लेकिन यह कोई पूर्ण मानक नहीं है; व्यवहारिक काम में गति, कानूनी अनुपालन, और संगठनात्मक जरूरतों के लिए कभी-कभी पूर्ण समझ छोड़नी भी पड़ सकती है

---

पूर्ण समझ और आंशिक समझ

• छोटे codebase और कम team turnover वाले माहौल में यह मानना आसान है कि अच्छा काम करने के लिए पूरे सिस्टम को समझना जरूरी है
  • Redis या The Witness) जैसे projects इस श्रेणी में आते हैं
• Google web search backend या GitHub जैसे बड़े codebase, जहाँ लोगों का आना-जाना ज्यादा होता है, वहाँ पूरे सिस्टम को समझना संभव नहीं होता; इसलिए हर व्यक्ति अपने स्थानीय क्षेत्र को जितना हो सके उतना समझकर काम करता है
• दोनों वातावरण development methods, practices, और culture में बहुत अलग हैं, लेकिन online software engineering चर्चाओं में पूर्ण समझ को महत्व देने वाली पहली संस्कृति का अनुपातहीन प्रतिनिधित्व होता है
  • open source engineers के पास अपने काम को लिखकर साझा करने की प्रेरणा ज्यादा होती है, और बड़े proprietary systems की तुलना में शुद्ध engineering काम अधिक उभरकर दिखता है
  • proprietary systems को कानूनी कारणों से सार्वजनिक करना कठिन होता है, और अगर किया भी जा सके, तो बड़े codebase को समझाने के लिए अत्यधिक ठोस संदर्भ की जरूरत पड़ती है
• कई software environments में आंशिक समझ कोई गलत स्थिति नहीं है, और बड़े सिस्टम में यही व्यवहारिक रूप से हासिल की जा सकने वाली सर्वोत्तम अवस्था होती है
• यह अंतर Pure and impure software engineering में अलग की गई पूर्ण समझ की संस्कृति और आंशिक समझ की संस्कृति के टकराव तक पहुँचता है

Programming as Theory Building का तर्क

• Peter Naur का paper Programming as Theory Building यह मानता है कि programmer का मुख्य output code नहीं, बल्कि program के बारे में एक theory है
  • यह theory इस बात की सहज समझ से बनती है कि क्या हो रहा है और क्यों हो रहा है
  • code और documentation इस समझ को केवल आंशिक रूप से ही समेट सकते हैं
  • यदि code खो भी जाए, तो theory रखने वाली team program को फिर से लिख सकती है; लेकिन अगर team पूरी तरह बदल जाए और समझ खो जाए, तो मौजूदा code को समझना बहुत कठिन हो जाता है
• Naur के अनुसार documentation या code भर से पुरानी theory को फिर से निर्मित नहीं किया जा सकता, इसलिए मूल program को छोड़कर नई team को समस्या फिर से शुरुआत से हल करनी चाहिए
• Naur द्वारा उद्धृत Gilbert Ryle की The Concept of Mind theory building की सीमा को और व्यापक रूप से देखती है
  • वास्तव में कुछ करते समय theory या know-how स्वाभाविक रूप से बन सकता है
  • इसलिए code को खुद खंगालते हुए मौजूदा codebase को समझने की प्रक्रिया भी इस दृष्टिकोण के साथ संगत है

बड़े सिस्टम को शुरुआत से फिर नहीं लिखा जा सकने के कारण

• पर्याप्त रूप से बड़े, user-facing सिस्टम में हजारों exception cases और विचित्र व्यवहार जमा हो जाते हैं, जिन्हें दोबारा लागू करना कठिन होता है
• सिस्टम को अच्छी तरह जानने वाली टीम भी हर detail को एक साथ ध्यान में नहीं रख सकती, इसलिए पूरे सिस्टम को एक बार में फिर लिखना मुश्किल है
• सफल rewrite आम तौर पर मौजूदा codebase को छोटे, अलग-थलग हिस्सों में बाँटकर एक-एक भाग बदलने के रूप में आगे बढ़ती है
  • अंततः rewrite भी मौजूदा सिस्टम पर क्रमिक बदलावों की एक श्रृंखला ही होती है
  • यदि मौजूदा सिस्टम में बदलाव करना ही संभव न हो, तो उसे पूरी तरह नए सिस्टम से बदलना और भी कठिन होगा

छोड़े गए codebase को पुनर्जीवित करने का तरीका

• करोड़ों लाइनों के code और हजारों engineers वाली tech companies में यह दुर्लभ नहीं है कि किसी खास codebase को जानने वाला कोई भी व्यक्ति शेष न बचे
  • केवल इतना काफी है कि कुछ जिम्मेदार लोग गलत समय पर नौकरी छोड़ दें, या codebase एक साल तक maintain न किया जाए
• Naur का मानना था कि जिस program की पुरानी theory के बारे में थोड़ा भी जानने वाला कोई व्यक्ति न हो, उसके पुनर्प्राप्ति का काम नए programmers को सौंपना शायद ही कभी होगा; लेकिन बड़े संगठनों में यह वास्तव में होता है
• छोड़े गए codebase को भी समय देकर नई समझ विकसित की जा सकती है और उसे फिर से प्रभावी रूप से काम करने की स्थिति में लाया जा सकता है
  • पहले किसी एक processing flow को शुरुआत से अंत तक समझें
  • फिर सावधानी से बदलाव करते हुए उसी flow के आसपास के क्षेत्रों तक समझ का दायरा बढ़ाएँ

हर कोई अपूर्ण theory के साथ काम करता है

• आधुनिक बड़े software इतने विशाल हैं कि न कोई व्यक्ति, न पूरी team उसके हर व्यवहार को अपने दिमाग में रख सकती है
• पर्याप्त बड़े codebase में हर व्यक्ति program के बारे में कुछ हद तक अपूर्ण या आंशिक रूप से गलत theory के साथ ही काम करता है
• प्रभावी engineers उस व्यक्ति का इंतजार नहीं करते जिसके पास पूर्ण समझ हो; वे उपलब्ध जानकारी के आधार पर सबसे उचित निर्णय लेते हैं और फिर उसके परिणामों के अनुसार प्रतिक्रिया देते हैं
• ऐसे काम के लिए अनिश्चितता में भी स्थिति लेने की क्षमता और आत्मविश्वास की जरूरत होती है
• बड़े products के समग्र व्यवहार को कोई भी पूरी तरह न जानने की वास्तविकता वही है जिस पर Nobody knows how software products work में चर्चा की गई है

Naur के समय और आज के code का पैमाना

• जब Naur ने 1985 में यह paper लिखा, तब औसत program का पैमाना आज की तुलना में कई orders of magnitude छोटा रहा होगा
• Naur द्वारा दिया गया पहला बड़े program का उदाहरण 2 लाख lines वाला industrial monitoring program था, और दूसरा example compiler का था
• GCC का पहला version 1987 में लगभग 1 लाख lines का था, लेकिन 2015 तक यह बढ़कर 1.4 करोड़ lines से अधिक हो गया
• यदि मौजूदा tests को दोबारा उपयोग किया जा सके, तो 1 से 2 लाख lines वाले program को अपेक्षाकृत आसानी से फिर लिखा जा सकता है; लेकिन 10 से 20 लाख lines या उससे बड़े सिस्टम पर वही निष्कर्ष लागू करना कठिन है

LLM और theory building का द्वंद्व

• LLM को अक्सर इस आधार पर खराब tool माना जाता है कि वे सामान्य theory building process में बाधा डालते हैं
• लेकिन दूसरे software tools की तरह LLM की भी दोहरी प्रकृति है
  • software के बारे में विस्तृत mental model बनाना अधिक कठिन हो सकता है
  • आंशिक theory जल्दी बनाई जा सकती है
  • अपूर्ण समझ के आधार पर भी अधिक प्रभावी ढंग से काम करने में मदद मिल सकती है
• LLM और code की समझ का संबंध केवल फायदे-नुकसान की सरल सूची से नहीं समझा जा सकता; यह अब भी निर्णय मांगने वाला एक जटिल trade-off है

वे जरूरी विकल्प जो code की समझ को कठिन बनाते हैं

• codebase की सटीक theory बनाए रखना कठिन करने वाले कारण केवल LLM नहीं हैं
  • दूसरे लोगों को उसी codebase में code लिखने की अनुमति देना
  • accessibility या data protection जैसे कानूनी रूप से आवश्यक features लागू करना
  • सहकर्मियों को नौकरी छोड़ने या team बदलने की अनुमति देना
  • security patch के लिए software versions upgrade करना
  • libraries या अन्य dependencies अपनाना
• केवल इस वजह से कि कोई tool या practice theory building में बाधा डालता है, उसे खराब नहीं कहा जा सकता
• codebase की समझ, readability, maintainability, और correctness की तरह engineering के कई मूल्यों में से एक है
  • परिस्थिति के अनुसार सटीक समझ को प्राथमिकता देने के लिए अन्य मूल्यों का त्याग किया जा सकता है
  • उल्टा, गति, कानूनी अनुपालन, या संगठनात्मक राजनीति के कारण code की समझ में समझौता भी किया जा सकता है
• यह आपत्ति कि code की समझ बाकी सभी मूल्यों को संभव बनाने का केंद्र है, readability, maintainability, और correctness पर भी समान रूप से लागू होती है; व्यवहारिक काम में इन मूलभूत मूल्यों के साथ भी लगातार समझौता किया जाता है

व्यक्तिगत पसंद और पेशेवर जिम्मेदारी

• खासकर pure engineers सटीक mental model बनाए रखते हुए काम करना पसंद करते हैं
  • development अधिक मजेदार और कम तनावपूर्ण होता है
  • यह उन्हें अपने विचार में सच्ची engineering के ज्यादा करीब लगता है
• कई engineers अपने खाली समय में अकेले छोटे open source projects इसलिए बनाते हैं क्योंकि वहाँ वे codebase के बारे में सटीक Naur-शैली की theory बनाए रखते हुए काम कर सकते हैं
• कामकाजी माहौल में व्यक्ति को अपनी निजी engineering values से ज्यादा उन मूल्यों का पालन करना होता है जिनके लिए संगठन भुगतान कर रहा है और जिनकी वह अपेक्षा करता है
  • भले ही performance महत्वपूर्ण लगती हो, schedule पूरा करने या कठिन requirements स्वीकार करने के लिए धीमा code भी लिखा जा सकता है
  • codebase की पूर्ण समझ भी कोई ऐसा पूर्ण मानक नहीं है जिसे हर समय निभाना ही हो; यह काम के उद्देश्य के अनुसार अन्य मूल्यों के बदले चुना या छोड़ा जा सकने वाला विकल्प है

[ndrgrd]

इसीलिए हम abstraction से इतने चिपके रहते हैं

[GN⁺]

Lobste.rs की राय

• मूल लेख का शीर्षक अफसोस की बात है कि कुछ हद तक clickbait के करीब है, जबकि असली बात इससे ज़्यादा इस ओर है कि बड़े codebase को आंशिक रूप से समझते हुए भी प्रगति कर पाना चाहिए
  theory-building के नज़रिये से भी, अगर theory में breadth और depth दोनों माने जाएँ, तो यह लेख के मुख्य बिंदु से टकराता नहीं है। breadth का मतलब है सिस्टम के कितने हिस्से तक आप इतना समझते हैं कि सवालों के जवाब दे सकें और भरोसेमंद तरीके से बदलाव कर सकें, और depth का मतलब है किसी खास हिस्से के बारे में आप कितने जटिल सवालों का जवाब दे सकते हैं और integrity बनाए रखते हुए कितने जटिल बदलाव कर सकते हैं
  अगर code को module दर module फिर से लिखा जाए और transition period रखा जाए, तो इसका मतलब है कि उस module के बारे में संकीर्ण लेकिन गहरी theory बनाई जाए और उसी के आधार पर काम किया जाए। छोटे function में parameter या return value एक जोड़ देना ठीक हो सकता है, लेकिन scale बढ़ने पर कम-से-कम किसी खास module के लिए साफ स्थिति से फिर शुरू करना और बाकी हिस्सों को नई implementation को call करने के लिए जोड़ देना ज़्यादा तर्कसंगत होता है। मूल रूप से buggy implementation की correctness को धीरे-धीरे सुधारने की कोशिश अक्सर अच्छी तरह काम नहीं करती, और यही बात performance जैसी विशेषताओं पर भी अक्सर लागू होती है
  लेकिन जब Naur ने कहा कि “program को revive करने के बजाय मौजूदा program text को फेंक देना चाहिए और नई programmer team को दी गई समस्या को शुरुआत से हल करने देना चाहिए”, तो इस पर चर्चा की गुंजाइश है कि क्या उनका मतलब rewrite शुरू करने से पहले मौजूदा code को पहले delete कर देना था, या फिर यह कि नया program उचित replacement साबित होने के बाद उसे हटाया जा सकता है
  और वास्तविक दुनिया में तो वह दी गई समस्या खुद ही दी हुई नहीं होती। Naur मानते हैं कि मूल problem definition बची हुई है, लेकिन बड़े codebase में अक्सर ऐसा नहीं होता। उसके सबसे करीब आमतौर पर test suite होती है, इसलिए tests पास कराते हुए components बदले जा सकते हैं
  उस समय continuous deployment भी नहीं था। आज के समय में service चलते रहने के दौरान call duty संभालनी होती है, सवालों के जवाब देने होते हैं, और urgent bugs ठीक करने होते हैं, इसलिए rewrite का cost-benefit हिसाब भी बदल जाता है

• इस rebuttal में कुछ हिस्से अच्छी तरह व्यक्त किए गए हैं, लेकिन ज़्यादातर बातें self-evident लगती हैं। पर्याप्त बड़े system में आंशिक समझ ही एकमात्र स्थिति होती है, लेकिन संगठन को हमेशा अधिक गहरी समझ की ओर बढ़ना चाहिए
  “हमें काम करने के पैसे मिलते हैं” वाली दलील से अलग, बड़े software अक्सर users को संतुष्ट करने या business goals हासिल करने में नाकाम रहते हैं। Windows और OS X को भी जमा होती जटिलता के कारण सड़ता हुआ माना जा सकता है
  management भी अगर जादू की तरह complexity मिटा सकती, तो ऐसा करती। लेकिन यह अभी भी software engineering की एक अनसुलझी समस्या है, और यह कहना ज़्यादा सही होगा कि management खराब code release करना नहीं चाहती, बल्कि मौजूदा हालात में ऐसे trade-off स्वीकार करती है
  यह कहा जा सकता है कि “monopoly हो तो घटिया और bug से भरा software जारी कर देना काफी है”, लेकिन यह ज़रूरत से ज़्यादा nihilistic है। बहुत-सी software कंपनियाँ monopoly नहीं हैं या users को बाँधकर नहीं रख सकतीं, इसलिए वहाँ quality सच में मायने रखती है

  • मेरे अनुभव में management अक्सर अच्छी software development practices पर अविश्वास करती है, और तेज़ी से आगे बढ़ने के नाम पर इन्हें पहले ही छोड़ देने को कहती है। ज़्यादातर बार यह फैसला बिना verification के सिर्फ assumptions के आधार पर लिया जाता है
  • “हमेशा और ज़्यादा समझना चाहिए” वाला लक्ष्य इस हद तक misuse हो सकता है कि कुछ भी न कर पाने की स्थिति बन जाए। अगर पर्याप्त समझ नहीं बल्कि पूर्ण समझ की माँग की जाए, तो इंसान कुछ कर ही नहीं पाता और अंत में हार मान लेता है या निराश हो जाता है
    इस व्याख्या के तहत समझ की अवधारणा भी किसी तरह के gatekeeping जैसी लगने लगती है

• लेख में समझाया गया approach code के कुछ हिस्सों के बारे में local reasoning करने की क्षमता से गहराई से जुड़ा है
  आसपास की हर चीज़ समझे बिना बड़े codebase के किसी एक हिस्से को समझना, यानी local reasoning, computer science की शुरुआत से ही एक केंद्रीय विचार रहा है
  structured programming का एक बड़ा फायदा यही था कि local reasoning संभव हो सके, और global variables से बचने की सलाह भी अधिकतर इसी उद्देश्य से आई थी। functional programming side effects हटाकर local reasoning संभव बनाती है, और object-oriented programming के सिद्धांतों में से एक—data structure और उसे संभालने वाले code को साथ बाँधना—भी local reasoning का एक और साधन देता है
  इन बुनियादी विचारों की असली ताकत इस बात में है कि वे, भले यह आदर्श स्थिति न हो, पूरे codebase को समझे बिना छोटे हिस्सों पर reasoning और काम करना संभव बनाते हैं

• “codebase की हर line समझनी चाहिए” वाली सलाह के खिलाफ यह एक दिलचस्प rebuttal लगा, और लेख का केंद्रीय तर्क development practical practices से जुड़ता है, इसलिए मैंने #practices tag लगाया
  मुझे पता है कि यह community LLM को पसंद नहीं करती, लेकिन मुझे शक है कि यह लेख सच में #vibecoding के दायरे में आता है या नहीं

  • हो सकता है आप जानते हों, लेकिन lobste.rs में LLM उपयोग से जुड़ी हर तरह की content को broadly vibecoding के तहत रखा जाता है, और मैं इससे सहमत नहीं हूँ, फिर भी यही प्रचलन है। इस लेख का मुख्य सवाल भी LLM-assisted coding से काफ़ी करीब से जुड़ा है
    फिर भी मैं इस बात से सहमत हूँ कि केवल vibecoding ही एकमात्र tag नहीं होना चाहिए। लेख LLM को स्पष्ट रूप से आखिर में जाकर छूता है, और इसका केंद्रीय तर्क LLM से पहले के दौर में भी दिलचस्प और चर्चा-योग्य है। इसलिए मुझे लगा कि practices tag को वापस लाने के पर्याप्त आधार हैं, और मैंने खुद इसे बहाल किया; मैं दूसरों को भी यही करने की सलाह दूँगा
  • लेख का सार हर programmer के लिए मायने रखता है, खासकर उनके लिए जो विशाल codebase के साथ काम करना और यह समझना चाहते हैं कि यह छोटे projects से कैसे अलग है
    यह उस दुनिया में भी प्रासंगिक है जहाँ LLM का उपयोग codebase की पूर्ण समझ में बाधा डाल सकता है
    अगर tag का मतलब है “यह vibe coding में रुचि रखने वालों के लिए प्रासंगिक हो सकता है”, तो यह स्पष्ट रूप से उपयुक्त है। लेकिन अगर मतलब है “vibe coding में रुचि रखने वालों को छोड़कर बाकी सबके लिए अप्रासंगिक है”, तो यह उपयुक्त नहीं है। बाकी सारे tags पहले अर्थ में इस्तेमाल होते हैं, लेकिन Lobsters के काफ़ी users इस tag को ही दूसरे अर्थ में इस्तेमाल करते हैं, इसलिए अंततः वे इस लेख को मिस कर देते हैं

• 1985 से अलग आज के development की एक और विशेषता यह है कि भले आप 3 लाख लाइन वाले codebase के expert बन जाएँ, अगले हफ्ते आप किसी बिल्कुल अलग 3 लाख लाइन वाले codebase पर काम कर रहे हो सकते हैं
  अनुभवी working programmers इस बात के आदी होते हैं कि उन्हें किसी भी समय अनजान क्षेत्र में डाल दिया जा सकता है, और वे common idioms (Google C++ Style Guide), ऐसे automated tools जिनमें API का गलत उपयोग करने पर compiler error देता है, और बड़े program “कैसे संगठित होने चाहिए” इस बारे में intuition—इन सबके मिश्रण पर निर्भर करते हैं
  मैंने Bun के LLM rewrite को लेकर यह चर्चा भी देखी है कि “अब जब पूरे codebase के व्यवहार को समझने वाला कोई नहीं है, तो development कैसे चलता रहेगा?” लेकिन यह कुछ वैसा ही है जैसे पूछना कि लेखक न हो तो उपन्यास को कैसे समझा जा सकता है। आख़िरकार यह code ही है, पढ़ेंगे तो समझ आएगा। अगर कोई function समझ न आए, तो उसे कई टुकड़ों में बाँट सकते हैं, tests लिख सकते हैं, control flow को कागज़ पर लिख सकते हैं—जो भी मदद करे, वह किया जा सकता है
  जब projects नियमित रूप से बदलते रहते हैं, तो पुराने codebase की समझ बनाए रखने की कोई खास वजह भी नहीं रहती। एक समय के बाद सब कुछ कुछ-कुछ एक जैसा घुलमिल जाता है। अगर आपको ऐसी Scala code में मदद करनी पड़े जिसे कंपनी ने खरीदे गए startup से लिया है, और जो custom Thrift-based RPC protocol के जरिए Go में rewrite हो रही JSON-based Ruby service से बात करती है, तब भी आप Scala syntax reference और Thrift wire encoding को लगभग एक घंटे खोजकर शुरुआत कर सकते हैं
  expert बनने की भी ज़रूरत नहीं है। एक महीने बाद शायद आप Linux kernel के Go implementation में यह debug कर रहे हों कि JavaScript के लिए OCaml-based type checker crash क्यों हो रहा है। आख़िर में यह सब सिर्फ code ही है