बड़ी कंपनियों में सक्षम इंजीनियर खराब कोड क्यों लिखते हैं

• बड़ी tech कंपनियों में कम tenure और बार-बार होने वाले organizational re-org के कारण, कई इंजीनियर ऐसे codebase पर काम करते हैं जिनसे वे परिचित नहीं होते
• code changes का एक बड़ा हिस्सा वास्तव में जॉइन करने के 6 महीने के भीतर के ‘शुरुआती’ स्तर के इंजीनियरों द्वारा किया जाता है
• कुछ अनुभवी ‘old-hand’ इंजीनियर गुणवत्ता की कमी को संभालते हैं, लेकिन अत्यधिक workload और अनौपचारिक जिम्मेदारियों के कारण उनकी सीमाएँ होती हैं
• कंपनियाँ विशेषज्ञता से अधिक workforce mobility और legibility को प्राथमिकता देती हैं, और यह गुणवत्ता में जानबूझकर की गई गिरावट की कीमत है
• नतीजतन, किसी इंजीनियर की व्यक्तिगत क्षमता से अलग, अनजान सिस्टम में तेज़ delivery पर केंद्रित होकर काम करने की संरचनात्मक समस्या ही खराब code का मूल कारण है

---

बड़ी कंपनियों में खराब code बनने की संरचना

• बड़ी tech कंपनियाँ ऊँचे वेतन पर सक्षम इंजीनियरों को hire करती हैं, लेकिन उनका tenure अक्सर सिर्फ 1–2 साल होता है
  • stock compensation (share grant) 4 साल बाद पूरी तरह vest होती है, जिसके बाद वेतन प्रभावी रूप से आधा रह जाता है
  • कुछ annual refresh भी होते हैं, लेकिन वे guaranteed नहीं होते, इसलिए इंजीनियर नौकरी बदलना चुनते हैं
• आंतरिक transfer को शामिल करें तो, एक ही codebase पर 3 साल से अधिक टिके रहना दुर्लभ है
  • re-org हर साल, या उससे भी अधिक बार होते हैं
• दूसरी ओर, codebase अक्सर 10 साल या उससे अधिक समय तक चलती है, इसलिए ज़्यादातर इंजीनियर किसी नए सिस्टम को अभी ‘सीख ही रहे होते’ हैं
  • नतीजतन, code changes का बड़ा हिस्सा जॉइन करने के 6 महीने के भीतर के शुरुआती इंजीनियरों द्वारा किया जाता है

‘old-hand’ की भूमिका और सीमाएँ

• कुछ इंजीनियर किसी खास सिस्टम पर लंबे समय तक टिके रहकर गहरी विशेषज्ञता हासिल कर लेते हैं
  • वे code review के जरिए समस्याओं को शुरुआती चरण में पकड़ सकते हैं
• लेकिन यह संरचना अनौपचारिक है और संस्थागत नहीं है
  • कंपनियों की दीर्घकालिक विशेषज्ञता बनाए रखने में रुचि कम होती है, और वे अनुभवी लोगों को दूसरी टीमों में भेज देती हैं
• अनुभवी लोग हमेशा अत्यधिक workload झेलते हैं
  • हर बदलाव को खुद review करने का समय नहीं होता
  • अगर उनकी अपनी performance output घटे, तो उन्हें नुकसान उठाने का जोखिम भी रहता है

औसत productive इंजीनियर की वास्तविकता

• बड़ी कंपनी का औसत productive इंजीनियर आम तौर पर इन विशेषताओं वाला होता है
  • वह hiring bar पार करने लायक सक्षम होता है, लेकिन नए codebase या language से परिचित नहीं होता
  • साथ ही, वह कई projects की एक-दूसरे पर चढ़ी हुई deadlines के बीच काम कर रहा होता है
• नतीजतन, यह एक ऐसी संरचना बन जाती है जहाँ लोग गुणवत्ता से अधिक schedule-केंद्रित माहौल में अपना सर्वश्रेष्ठ देने की कोशिश करते हैं
  • उदाहरण: एक शुरुआती इंजीनियर अनजान code में bug को अस्थायी तरीके से ठीक करता है, और अनुभवी व्यक्ति हल्का review करके उसे deploy कर देता है
  • फिर कई साल बाद वही code दोबारा सामने आता है और सवाल उठता है, “ऐसा code आखिर लिखा ही क्यों गया था?”

कंपनियाँ इस संरचना को बनाए क्यों रखती हैं

• बड़ी कंपनियाँ उत्पादकता से अधिक आंतरिक legibility को महत्व देती हैं
  • वे ऐसी संरचना पसंद करती हैं जिसमें पता रहे कि कौन क्या कर रहा है, और जिसे किसी भी समय फिर से reassign किया जा सके
• यह विशेषज्ञता और code quality की कीमत पर किया गया एक जानबूझकर चयन है
  • skill loss स्वीकार करके, समस्या आने पर लोगों को तेज़ी से इधर-उधर लगाने की flexibility मिलती है
• खासकर AI जैसे नए क्षेत्रों की ओर तेज़ pivot महत्वपूर्ण होने पर, यह रणनीति कंपनियों के लिए फायदेमंद काम करती है
• लेकिन ऐसे माहौल में अनजान सिस्टम में जल्दबाज़ी में काम करने वाले इंजीनियरों की संख्या बढ़ना तय है

इंजीनियर की व्यक्तिगत सीमाएँ और ‘pure/impure’ engineering

• व्यक्तिगत इंजीनियर के पास इस संरचना को बदलने की शक्ति नहीं होती
  • 2025 तक शक्ति का केंद्र इंजीनियरों से management की ओर खिसक चुका है
  • व्यक्ति अधिकतम इतना कर सकता है कि किसी खास क्षेत्र का ‘old-hand’ बनकर न्यूनतम गुणवत्ता बनाए रखे
• लेकिन ज़रूरत से ज़्यादा दखल देने पर उल्टा कम performance के आधार पर PIP में डाले जाने का जोखिम भी होता है
• लेख ‘pure’ और ‘impure’ engineering का अंतर बताता है
  • pure engineering: स्वतंत्र technical projects (जैसे programming language development) पर केंद्रित
  • impure engineering: अनजान सिस्टम में schedule-केंद्रित वास्तविक कामकाजी वातावरण
• बड़ी कंपनियों के ज़्यादातर इंजीनियर impure engineering में आते हैं, और इस स्थिति में खराब code एक अपरिहार्य उप-उत्पाद बन जाता है
  • अगर सिस्टम पर्याप्त रूप से काम कर रहा है, तो project को सफल माना जाता है

निष्कर्ष: संरचनात्मक कारण के रूप में ‘अनजान codebase’

• बड़ी कंपनियों के पास इंजीनियरों को स्वतंत्र रूप से इधर-उधर ले जाने की शक्ति होती है, और यह विशेषज्ञता के नुकसान को स्वीकार करने वाला उनका अपना चयन है
• खराब code की जिम्मेदारी व्यक्ति पर नहीं, बल्कि संगठनात्मक संरचना और workforce संचालन के तरीके पर है
• सभी इंजीनियरों की क्षमता दोगुनी कर दी जाए, तब भी अनजान codebase में गलतियाँ होती रहेंगी
• मूल कारण यह है कि “ज़्यादातर इंजीनियरों को अपने अपरिचित code में ही ज़्यादातर काम करना पड़ता है”
• खराब code के उदाहरणों की ओर इशारा करना सुधार में मदद कर सकता है, लेकिन दोष इंजीनियरों का नहीं, सिस्टम का है

[sonnet]

मेरे अनुभव में, अगर CS, खासकर PLT, की बुनियाद मज़बूत हो तो आखिरकार किसी भी माहौल में अपेक्षाकृत बेहतर कोड लिखा जाता है।

बहुत गहरी जानकारी न भी हो, फिर भी जो व्यक्ति सबसे बुनियादी सिद्धांतों को समझता हो, उसके पास अगर पर्याप्त समय हो और कोड परिचित हो, तो वह अपने स्तर पर ठीक-ठाक code quality निकाल लेता है। n बार refactoring कर दें तो AI के लिखे कोड भी कुछ हद तक काफ़ी ठीक-ठाक लगने लगते हैं।

किसी एक source को चाहे जितने लंबे समय तक पकड़े रहें, फिर भी ऐसे बहुत से लोग होते हैं जो खुद को 20 साल का अनुभवी बताते हैं लेकिन spaghetti code के अलावा कुछ नहीं बना पाते, और यह भी नहीं जानते कि ऐसा क्यों नहीं करना चाहिए।

जब तक एकदम परफेक्ट माहौल में अनंत समय और बजट नहीं दिया जा सकता, यह मुझे काफ़ी हद तक खोखली बात लगती है जिसका बहुत बड़ा मतलब नहीं है। क्या किसी भी दौर में, किसी भी role में, बात आखिर यही नहीं रही है?

उसी system में बेहतर कोड लिख पाना स्पष्ट रूप से engineer की क्षमता है.

[sonnet]

अगर सिस्टम को अच्छी क्वालिटी देनी है, तो अच्छा होगा कि उसे कुछ गुंजाइश और लचीलापन रखते हुए बनाया जाए। और यह भी तय है कि संगठन इंजीनियरिंग और development methodology आज की तुलना में कम विकसित होने वाले दौर के मुकाबले, औसतन अब स्थिति बेहतर ही होगी.

लेकिन मेरी नज़र में यह ऐसे लगता है जैसे कोई व्यक्ति, जिसका इंजीनियर के रूप में अहं बहुत फूला हुआ है लेकिन संगठन के सदस्य के रूप में जिम्मेदारी की भावना कम है, यह सफाई दे रहा हो कि यह सब उसकी गलती नहीं बल्कि management की गलती है।

क्या architectural engineers, industrial designers, animators के पास deadline नहीं होती, और क्या उनका मूल्यांकन productivity के बजाय सिर्फ creativity और quality से होता है, जबकि केवल programmers के पास ही deadline होती है?

[wahihi]

सब कुछ कितना बेतुका फैला हुआ है.. बुरा code, अच्छा code जैसी बातें तो junior लोग करते हैं, उससे ज़्यादा अहम यह है कि उस उद्योग के हिसाब से software design अच्छी तरह करने वाला senior है या नहीं..

[sonnet]

यहाँ पोस्ट होने वाले लेख आमतौर पर घरेलू SI बाज़ार के कुछ दृष्टिकोणों या अनुभवों से कुछ अलग माहौल के हो सकते हैं, जहाँ OCP तक को नज़रअंदाज़ किया जाता है.

खैर, Linus Torvalds कोई जूनियर तो नहीं हैं...

[GN⁺]

Hacker News राय

• मैंने इस व्यक्ति की लिखी बातें कई बार पढ़ी हैं, और हर बार कोई असहज भावना रह जाती थी
  अब लगता है कि वजह समझ आ गई है। लिखे गए विश्लेषण अपने आप में तार्किक हैं, लेकिन उनकी बुनियाद में एक तरह का निहिलिज़्म बसा हुआ लगता है
  शायद यह कोई ऐसा व्यक्ति है जो कभी आदर्शवादी था, लेकिन बुरे अनुभवों के कारण अब यह समझाने की कोशिश कर रहा है कि ‘किसी चीज़ पर भरोसा करना व्यर्थ है’
  इसलिए ऐसे सवाल उठते हैं — बड़ी कंपनियों को ऐसा व्यवहार क्यों करना चाहिए, खराब कोड इंजीनियरों को इतना परेशान क्यों करता है, क्या वह भावना सच में गलत है, या यह उस आर्थिक ढांचे की समस्या है जिसमें हम रहते हैं, या फिर क्या विशाल शक्तियों के आगे समर्पण कर देना ही परिपक्वता है

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

• मुझे लगता है कि समस्या tenure की नहीं, बल्कि मोटिवेशन की है
  फिल्म Office Space की पंक्ति याद आती है: “अगर मेहनत का कोई इनाम नहीं मिलता, तो प्रेरणा भी पैदा नहीं होती”

  • बड़ी कंपनियों के इंजीनियर वास्तव में बहुत मोटिवेटेड होते हैं (मैं Google में इंजीनियर हूँ)
    लेकिन मैनेजमेंट अच्छे कोड से ज्यादा results को महत्व देता है
    वे maintenance की वैल्यू को माप नहीं सकते, इसलिए उस काम को पहचान नहीं मिलती
    आखिरकार वही व्यक्ति प्रमोशन पाता है जिसने ढीला-ढाला कोड deploy किया
  • सिर्फ मोटिवेशन काफी नहीं है
    मैं अपनी टीम और कोड की परवाह करते हुए बहुत ध्यान से काम करता था, लेकिन आखिर में मेरा मूल्यांकन PR की संख्या जैसे साधारण metrics से हुआ
    कोड की कठिनाई या टीम में योगदान को नजरअंदाज कर दिया गया, और सिर्फ “दिखने वाले नंबर” मायने रखते थे
    अंत में जिस मैनेजर ने मेरा मूल्यांकन किया था, उसे भी कुछ महीनों बाद निकाल दिया गया
    विडंबना यह है कि अगर मैं उदासीन होता, तो शायद ऐसी बातों से आहत भी नहीं होता

• बड़ी कंपनियाँ इंजीनियरों को आसानी से बदले जा सकने वाले संसाधन की तरह देखती हैं
  यह सिर्फ efficiency का सवाल नहीं है, बल्कि power balance को मैनेजमेंट की तरफ झुकाने की रणनीति भी है
  मकसद यह है कि अहम प्रोजेक्ट किसी खास इंजीनियर समूह पर निर्भर न हो जाएँ

  • पूंजी, कुछ efficiency छोड़कर भी, श्रम की ताकत को कमजोर करना चाहती है
    वह चाहती है कि हर कामगार को बदला जा सके
  • लेकिन व्यवहार में ऐसा कम ही होता है कि कंपनी जानबूझकर skilled इंजीनियरों को किसी दूसरी टीम में भेज दे
    अक्सर तो वे अच्छे इंजीनियरों को रोककर रखने की कोशिश ही करती हैं
  • सच तो यह है कि इंजीनियर भी आपस में “वह कोड जो सिर्फ Bob को पता है” जैसी चीज़ों की आलोचना करते हैं
    यानी यह संस्कृति सिर्फ मैनेजमेंट की समस्या नहीं है

• अक्सर ऐसा कोड दिखता है जिसकी syntax और structure तो किताबों जैसी होती है, लेकिन मूलभूत तरीका ही गलत होता है
  code review सिर्फ syntax पर केंद्रित रहता है, जबकि बिज़नेस समस्या या complexity पर चर्चा ही नहीं होती
  छोटे समय में यह ठीक लग सकता है, लेकिन लंबे समय में technical debt फट पड़ता है

  • इससे पूरी तरह सहमत हूँ। database schema जैसी चीज़ें पहले sprint में ही पत्थर की लकीर बन जाती हैं, और फिर कभी refactor नहीं होतीं
    नतीजा यह होता है कि मामूली code quality बहसों में PR कई-कई दिन अटके रहते हैं
  • बड़ी कंपनियों में भी यही देखता हूँ
    सब लोग ऊपरी स्तर की code cleanliness पर अटके रहते हैं
    तार्किक मजबूती या बड़ी तस्वीर देखना मुश्किल होता है, और कई बार reviewer को context ही नहीं पता होता
  • अगर requirements gathering, documentation, और product design अच्छे न हों, तो लंबे समय तक टिकाऊ design बनाना मुश्किल हो जाता है
    और अगर पूरी organization के पास ऐसे feedback को अपनाने की गुंजाइश न हो, तो आखिर में वह ‘जैसे-तैसे चलने वाले सिस्टम’ पर निर्भर हो जाती है
  • अगर आप code review में architecture की समस्या पकड़ रहे हैं, तो इसका मतलब है कि process के चरण में ही विफलता हो चुकी है
    बड़े design की समीक्षा code review से पहले होनी चाहिए
  • यह पैटर्न AI-generated code में भी अक्सर दिखता है
    यानी हम लंबे समय की लागत को automate कर रहे हैं

• बड़ी कंपनियों को कोड में खुद कोई दिलचस्पी नहीं होती
  कोड सिर्फ कंपनी को चलाने वाला एक माध्यम है
  आखिरकार जो सच में महत्वपूर्ण है, वह कोड नहीं बल्कि process है
  असली सवाल यह है कि जब सिस्टम टूट जाए, तो क्या उसे बहाल करने की प्रक्रिया मौजूद है

• हर उद्योग, जैसे-जैसे उसका आकार बढ़ता है, वैसे-वैसे ऐसे ही समझौते करता है
  परफेक्शन से ज्यादा ‘काफी अच्छा’ वाला स्तर ही मुनाफा देता है
  जैसे IKEA की कुर्सी और Herman Miller की कुर्सी में फर्क होता है, वैसे ही यहाँ सिर्फ constraints अलग हैं
  असली कौशल यह है कि कहाँ समझौता करना है, यह जानना
  बड़ी कंपनी की संरचना इंजीनियरों पर ऐसे समझौते थोपती है

• अच्छे senior इंजीनियर शुरू से खराब कोड नहीं लिखते
  असली समस्या short-term performance pressure और बुनियादी आधार की कमी है
  review छोड़ देना या architecture पर पर्याप्त विचार न करना ही असली वजह है

  • लेकिन हकीकत यह भी है कि कई बार स्थिति पहले से इतनी बिगड़ी होती है कि अच्छा कोड लिखना संभव ही नहीं रहता
    इस टिप्पणी में जैसा बताया गया है, लाखों लाइनों की जुगाड़ से भरे कोड के ऊपर आप कितना भी प्रयास कर लें, उसे साफ नहीं बना सकते
    आखिरकार यह पूरी स्पेगेटी को एक साथ उठाने जैसा बन जाता है
  • आखिर में दोनों बातें सही हैं
    senior इंजीनियर हमेशा ‘काम सही तरीके से करना’ और ‘जल्दी खत्म करना’ के बीच दुविधा में फँसा रहता है
  • अच्छा कोड context पर निर्भर होता है
    जटिल codebase को एक ही दिन में समझा नहीं जा सकता, और अगर organization knowledge accumulation को महत्व नहीं देती, तो quality गिरती ही जाती है
    नए कर्मचारियों को documentation या सफाई-सुधार वाला काम देना अच्छा रहता है, ताकि वे कोड की संरचना समझ सकें
  • एक और वजह compatibility बनाए रखने की आवश्यकता है
    पुराना जुगाड़ी कोड बहुत हो, तब भी उसे तोड़ा नहीं जा सकता, इसलिए हाथ नहीं लगाया जाता
  • मैंने जो सबसे खराब कोड लिखा, उसकी वजह बदलती requirements थीं
    चाहे design कितना भी शानदार हो, अगर उसकी नींव रेत पर है, तो वह ढह ही जाएगा

• लेखक का यह निष्कर्ष कि ‘readability, quality से ज्यादा महत्वपूर्ण है’, अगर सही है, तो इसका मतलब यह होना चाहिए कि हर बड़े कॉर्पोरेट प्रोजेक्ट में static analysis tools और automatic formatter अनिवार्य होने चाहिए
  लेकिन हकीकत ऐसी नहीं है
  ऐसे tools अपनाने का फैसला non-technical managers करते हैं, और उन्हें short-term cost पसंद नहीं होती
  आखिर में release schedule सब पर भारी पड़ता है

  • “दूसरा monitor जरूरी नहीं है” कहने वाले मैनेजर इसी संस्कृति का प्रतीक हैं

• एक बड़ी manufacturing कंपनी में consulting करते समय मैंने पूरे कोडबेस में अजीब object modeling pattern देखे
  वजह खोजने पर पता चला कि designer का मूल इरादा (blueprint–mold–product) development team ने पूरी तरह गलत समझ लिया था
  मैंने कहा कि इसे ठीक करना चाहिए, लेकिन जवाब मिला, “अब बहुत देर हो चुकी है”
  नतीजतन, 10 साल से भी ज्यादा समय तक वह गलत model बना रहा और उसने भारी technical debt पैदा कर दिया

  • मजाक में लोग यह तक कहने लगे थे, “चलो, उम्मीद है कि उस product से किसी की जान तो नहीं जाएगी?”

• बड़ी कंपनियों के कम औसत tenure वाले आँकड़े भ्रामक हो सकते हैं
  यह बस headcount में तेज़ बढ़ोतरी की वजह से median कम दिखने का असर है
  वास्तव में सटीक तस्वीर के लिए नौकरी छोड़ने वालों के आधार पर देखना चाहिए

  • इसी वजह से, वरिष्ठ डेवलपर्स का अनुपात भी कम करके आँका जाता है
    कारण सिर्फ इतना है कि पहले डेवलपर्स की संख्या कम थी