कोड की एक लाइन बदलने में 6 दिन (2015)

 (edw519.posthaven.com)
2 पॉइंट द्वारा GN⁺ 2023-07-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फैक्टरी की utilization 10% घटने पर कंपनी ने layoffs की जगह peak season से पहले inventory जमा करने के लिए backlog बढ़ाने का फैसला किया, और इसी वजह से 3 महीने की backlog limit को 4 महीने करने का अनुरोध शुरू हुआ
  • IT प्रमुख को लगा कि core routine में सिर्फ एक hardcoded value बदलनी होगी, लेकिन उससे पहले ticket लिखना, business impact दर्ज करना, approval लेना और queue priority समायोजित करना ज़रूरी था
  • प्रोग्रामर ने Module ORP572 की line 1252 में MonthsOfBacklog का मान "3" से "4" कर दिया और test पास कर लिया, लेकिन code review में मौजूदा policy violation भी सुधार के दायरे में आ गए
  • बदलाव का दायरा Parameters file में record बनाना, debug command हटाना, unassigned variable warning, hardcoded Employee ID, access permission, test environment, test plan और user signature जैसी सहायक प्रक्रियाओं तक फैल गया
  • काम के लिहाज़ से ज़रूरी बदलाव सिर्फ 1 line·1 byte का था, लेकिन कुल elapsed time 6 दिन रहा, और आंतरिक प्रक्रियाओं व policies ने छोटे बदलाव की वास्तविक lead time को बहुत बढ़ा दिया

3 महीने की limit को 4 महीने करने का अनुरोध

  • अध्यक्ष Philip ने कहा कि फैक्टरी 10% idle है, इसलिए layoffs की बजाय backlog के लिए ज़्यादा उत्पादन करके peak season से पहले inventory जमा करना बेहतर होगा
  • operations manager Lee ने कहा कि कंपनी policy के अनुसार सिर्फ 3 महीने की backlog तक ही बनाई जा सकती है, इसलिए limit को 4 महीने करने पर पर्याप्त काम पैदा हो जाएगा
  • IT प्रमुख David ने सोचा कि legacy software की core routine में code की सिर्फ एक line बदलनी होगी, और IT Services में ticket जमा करने को कहा
  • IT manager Judy ने अनुरोध को Ticket# 129281 के रूप में assign किया, लेकिन कहा कि Business Impact section और Director approval ज़रूरी है
    • जब David ने संभावित layoffs का ज़िक्र किया, तो Judy ने खुद वह section भर दिया और इसे fast processing में डाल दिया
    • 2 दिन बाद भी यह अनुरोध Developer Queue में 14 Bug Report के बाद पहले Enhancement के रूप में पड़ा था
    • David ने अनुरोध को urgent mark करके Ed को सीधे भेजने का निर्देश दिया

एक लाइन का बदलाव कैसे प्रक्रिया-स्तरीय बदलाव बन गया

  • Ed ने Module ORP572 line 1252 में hardcoded variable MonthsOfBacklog को "3" से "4" कर दिया
    • unit test पास हुआ और batch test 2 बार चलाया गया
    • Operations work queue अपेक्षा के मुताबिक 10% बढ़ गई
    • बदलाव Code Review और Homer के User Acceptance Testing के लिए भेजा गया
  • code review संभालने वाली Shirley ने कहा कि hardcoded variable कंपनी policy के खिलाफ है, इसलिए इसे Parameters file के record में बदला जाना चाहिए
    • उसने यह भी कहा कि production में भेजने से पहले मौजूद 2 Debug command, unassigned variable warning और hardcoded Employee ID भी ठीक करने होंगे
    • उसका कहना था कि चूँकि ORP572 Ed को assign किया गया है, इसलिए नई कंपनी policy का उल्लंघन करने वाली पुरानी गलतियों की ज़िम्मेदारी भी उसी की है
  • test environment भी देरी का कारण बना
    • Homer month-end accounting close control test के कारण उपलब्ध नहीं था, इसलिए Marge का उपयोग करना पड़ा
    • Ed के पास Marge की access permission नहीं थी, और IT Security के Joe ने कहा कि David के signature के बिना access नहीं दी जा सकती
  • Parameters record का काम अतिरिक्त मांगों के कारण और बढ़ गया
    • MonthsOfDemand नाम विदेशी programmers के लिए समझना कठिन बताया गया, इसलिए बेहतर नाम चाहिए था
    • नए Parameter record में audit trail होना चाहिए था, लेकिन यह policy document नहीं थी और wiki update भी 3 महीने late था
    • Ed ने नाम बदलकर SelectedMonthsOfBacklogDemand किया और उस record व audit trail को बनाए रखने के लिए Module PAR634 जोड़ दिया
  • tester Tony ने बताया कि Marge में 129281 दिख रहा है, लेकिन Test Plan नहीं है
    • Ed ने कहा कि पुरानी और नई दोनों विधियों से चलाकर WorkOrdersHours report के total volume में बढ़ोतरी की पुष्टि कर लेना काफी होगा, लेकिन Tony ने कहा कि इसका असर पूरी फैक्टरी पर पड़ता है, इसलिए user-selected Test Cases, Expected Results, documented Test Runs और user sign-off चाहिए
    • 2 दिन बाद Philip ने David से कहा कि Tony, Ed के program को तुरंत production में ले जाए
  • कुल elapsed time 6 दिन था, जबकि mission critical code में बदलाव सिर्फ 1 line·1 byte का था
    • Excedrin की 24 गोलियाँ खप गईं
    • Hacker News पर झुंझलाहट में बिताया गया समय 14 घंटे बताया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-17
Hacker News राय

  • मुख्य बात यह है कि reviewer ने यह मांग की कि “इसे बदलने के लिए codebase की दूसरी unresolved समस्याएँ भी साथ में ठीक करनी होंगी”
    ऐसे समय में जवाब देना चाहिए: “code quality बेहतर करने की दिशा अच्छी है, लेकिन Y बदलने पर X/Y/Z approvals चाहिए होंगे और कुछ दिन और लगेंगे। आपने जो बात उठाई है उसे technical debt task बनाते हैं, और priority व capacity के हिसाब से follow-up PR में निपटाएँगे। अभी इस local PR को deploy करने के लिए क्या चाहिए, उसी पर ध्यान दें”
    सबसे बड़ा सबक यह था कि focused PR बनाओ, और जब reviewer scope बढ़ाने की कोशिश करे तो उसका प्रतिवाद करना सीखो। आम तौर पर दूसरे engineers ने इसे व्यावहारिक रूप से स्वीकार किया। इसका line count से कोई लेना-देना नहीं है। पूरे code की सिर्फ formatting बदली हो सकती है और logic change न हो, या केवल कुछ feature flags बदले गए हों लेकिन असर बड़ा हो सकता है। एक बार में सिर्फ एक focused change होना चाहिए

    • मैं इस बात से सहमत नहीं हूँ कि “इसे बदलने के लिए दूसरी unresolved समस्याएँ भी ठीक करनी होंगी” ही मुख्य बिंदु है। यहाँ सबसे बुरी बात यह है कि code की एक line बदलने में 6 दिन लगे, और उनमें से लगभग आधा समय तो engineer के issue देखने से पहले ही निकल गया
      अगर यह इतनी high-priority चीज़ थी कि तुरंत न करने पर कंपनी को लोगों को निकालना पड़ सकता था, तो किसी के देखने से पहले के 2~3 दिन बिल्कुल नहीं होने चाहिए थे। लेकिन इस development process में वही शायद “fast path” लगता है
      आख़िरी 2 दिन भी शायद इसलिए निकल गए कि test plan को अपर्याप्त माना गया और मानो कुछ हुआ ही नहीं। “इसे बदलने के लिए दूसरी unresolved समस्याएँ भी ठीक करनी होंगी” वाली बात ने यहाँ केवल 2 घंटे लिए, और उस हिस्से को देखे बिना भी इस process की core problem के रूप में बताने लायक कम से कम 2~3 और चीज़ें थीं
    • आम तौर पर मैं उस काम से सीधे संबंधित न होने वाले improvements से बचता हूँ जो अभी हाथ में है। सिर्फ एक missing semicolon जोड़ने पर भी कोई overzealous reviewer देख ले तो legacy fix rabbit hole में खींचा जा सकता है
      FIXME या TODO छोड़ने की बजाय मैं चुपचाप issue बना देता हूँ ताकि भूल न जाऊँ। review का यह हिस्सा टूटा हुआ है। technical debt को task completion की condition नहीं होना चाहिए; उसे अलग से plan करना चाहिए
    • scope creep करने वाले लोग यह नहीं समझते कि वे architecture को कितना नुकसान पहुँचा रहे हैं। अगर वे किसी एक code block पर ज़रूरत से ज़्यादा अटक जाएँ, तो लोग उसके आसपास से bypass करने लगते हैं
      ऐसी परतें जुड़ती जाएँ तो अंत में code की हालत नैतिक रूप से Atlanta, GA जैसी हो जाती है, जो अपनी बहुत सारी beltways के लिए बदनाम है
    • मुझे लगता है बेहतर समाधान नियमों को automate करना है
      जब कोई नया rule जोड़ा जाए, तो automation को पुराने सभी violation points पर rule-exception comments जोड़ने चाहिए और उन्हें track भी करना चाहिए। अगर जल्दी deploy होने वाले code को rule तोड़ना पड़े, तो exception comment जोड़ दो और बाद में उसे ठीक करने के ज़िम्मेदार व्यक्ति के रूप में अपना नाम लिख दो
      समय के साथ feature development से अलग इन rule violations को ठीक करने की culture बनाई जा सकती है
    • जब ऐसा हो, तो बस एक TODO ticket जोड़ दो। production block हट जाएगा, और system भी बदतर नहीं होगा

  • सही बात है। ज़्यादातर कंपनियों की code review process nitpicking और छोटी-मोटी टिप्पणियों से भरी होती है
    पहले मैंने सुझाव दिया था कि ऐसी टिप्पणियाँ हटाकर feedback को तेज़ करने के लिए static analysis tools का इस्तेमाल करें, लेकिन जवाब मिला कि ऐसी code review सबके लिए ज़रूरी है। इससे लोगों को promotion में मदद मिलती है, उन्हें लगता है कि उन्होंने code issues रोके हैं, और upper management reviewer comments की संख्या देखकर code review metrics अच्छे मान लेता है

    • मुझे इन tools का अत्यधिक इस्तेमाल पसंद नहीं है। बेवकूफ़ tools को खुश करने के लिए code को और खराब बना देना कोई दुर्लभ बात नहीं है
      असली समाधान यह मान लेना है कि हर code का ऐसा दिखना ज़रूरी नहीं जैसे मैंने खुद लिखा हो, और अपने-आप से पूछना है: “क्या यह comment code की objective error से जुड़ा है?” कई बार जवाब “नहीं” होता है
    • यहाँ कभी-कभी सचमुच prisoner’s dilemma होता है। जब कोई senior किसी junior का PR review करता है, तो उसमें कुछ चीज़ें बेहतर हो सकती हैं, लेकिन वे अक्सर महत्वपूर्ण नहीं होतीं
      अगर variable name थोड़ा verbose है या methods के बीच spacing एक-सी नहीं है, तो आदर्श स्थिति में यह “अगर यह pattern बन जाए तो अगली बार ध्यान रखने लायक feedback” होना चाहिए। लेकिन reviewer के नज़रिए से PR पर comments की संख्या इस बात का metric बन सकती है कि उसने कितना mentor किया, या उसे “इसे merge कैसे होने दिया?” जैसी प्रतिक्रिया का डर रहता है, इसलिए वह अंततः comment छोड़ देता है
      जिसे review मिल रहा है, वह भी comments address न करने पर feedback के प्रति कम responsive दिखने के डर से, या जवाबी तर्क देने पर reviewer से खराब मूल्यांकन मिलने के डर से बदलाव कर देता है। फिर updated version को दोबारा approval चाहिए होता है और delay cycle फिर से शुरू हो जाता है
    • कुछ environments में यह सही बात है। लेकिन review process बदलावों और codebase के बारे में shared knowledge और समझ बनाने में भी मदद करती है
    • nitpicking स्पष्ट रूप से वास्तविक है। शायद इसलिए कि लोगों को लगता है कि code में कुछ गलत ज़रूर ढूँढना चाहिए
      लेकिन कुछ समस्याएँ ऐसी भी होती हैं जिन्हें कोई व्यक्ति मामूली समझता है, जबकि वे वास्तव में बिल्कुल मामूली नहीं होतीं। ऐसा इसलिए हो सकता है क्योंकि वह अपनी आँखों से समस्या नहीं देख पा रहा, समस्या को समझ नहीं रहा, या अपनी भावनाएँ अलग रखकर अपने लिखे code पर फिर से विचार नहीं कर पा रहा
      हम सबने कभी न कभी अपने लिखे code से लगाव रखा है, और शायद उसे दुनिया का सबसे elegant code भी माना है। लेकिन कभी-कभी यह मानना पड़ता है कि मैं गलत था, और वह code पढ़ने में कठिन, दोषपूर्ण और codebase के लिए हानिकारक है
      मैंने अपने से अधिक senior व्यक्ति के code में ऐसी race condition बताई थी जो वास्तव में समस्या बन सकती थी, और मुझे nitpicker कहा गया। मेरे लिए race condition लिखे गए code की बुनियादी समस्या थी और उसे ठीक होना चाहिए था, लेकिन उस व्यक्ति के लिए यह तब तक स्वीकार्य स्थिति थी जब तक उसने उसे स्वाभाविक रूप से टूटते नहीं देखा था
    • static analysis tools और peer review अलग-अलग तरह की समस्याएँ पकड़ सकते हैं। जैसे static compiled languages कुछ bugs पकड़ लेते हैं जिन्हें dynamic languages नहीं पकड़ पातीं, लेकिन सब कुछ नहीं पकड़ पातीं
      मुझे peer review बहुत पसंद है, और मैं आम तौर पर इन बातों पर ध्यान देता हूँ: “यह code उम्मीद के मुताबिक काम नहीं करेगा”, “ऐसा करने से implementation अटक जाएगी या बहुत महँगी हो जाएगी”, “यह काम तो करता है लेकिन समझने में कठिन है, इसलिए maintenance पर बुरा असर पड़ेगा; किसी दूसरे तरीके या अतिरिक्त explanation पर विचार करो”, “code ठीक है, लेकिन इसे और बेहतर पढ़ने योग्य या काम करने वाला बनाया जा सकता है। यह review fail कराने लायक नहीं है, लेकिन अगले code में ध्यान रखने लायक बात है”

  • “Julie: IT सुरक्षा टीम के Joe से संपर्क करें। वे आपको access दे देंगे। 2 घंटे बाद।” पूरी तरह अवास्तविक है। सुरक्षा टीम इतनी जल्दी जवाब दे ही नहीं सकती

    • अगर “npm install” चलाने से P1 security alert उठ गया हो, तो वह अपवाद है
    • हमारी सुरक्षा टीम वास्तव में इससे भी तेज जवाब देती है। वे सभी requests अपने-आप reject कर देते हैं, लेकिन तुरंत reject करते हैं
    • जहाँ मैं काम करता हूँ, वहाँ अनुभव काफ़ी अलग है। अगर आप किसी के लिए किसी खास system का access माँगते हुए ticket डालें, तो priority कुछ भी हो, वह आम तौर पर कुछ ही मिनटों में निपटा दिया जाता है
      कभी-कभी लगता है कि helpdesk वाले ऐसे tickets आते ही झपट लेते हैं ताकि जल्दी close करके अपने personal metrics बढ़ा सकें
    • किसी को wiki edit permission के लिए ज़रूरी AD group में जोड़ने में कई हफ्ते लग जाते हैं

  • शीर्षक की तरह अगर कहें कि कोड की एक लाइन बदलने में 6 दिन लगे, तो यह डरावना लगता है
    लेकिन system कुछ मायनों में बेहतर हुआ। hardcoding की जगह settings को parameter table से configurable बनाया गया, और उन settings changes को track करने के लिए audit feature भी जोड़ दिया गया
    मैं bureaucracy का बचाव नहीं कर रहा। बड़े संगठनों की उस प्रवृत्ति से मुझे सच में नफ़रत है। बस यह कहना चाहता हूँ कि शुरुआती लक्ष्य के अलावा भी उन 6 दिनों में कुछ अतिरिक्त value बनी
    इसलिए estimates में कुछ overhead cost शामिल होनी चाहिए, और अगर story points दिए जा रहे हों, तो ऐसी procedural cost को भी ध्यान में रखना चाहिए

    • parameter table के उपयोगी होने की एकमात्र वजह यह थी कि code changes को रोकने वाली चीज़ें बहुत ज़्यादा थीं। उसी तरह इस setting के लिए audit भी अनावश्यक लगता है। पहले यह code में था, इसलिए source control ही audit trail था
      आखिरकार दो “उपलब्धियाँ” यह थीं कि code change के आसपास की अतिरिक्त रस्मों से बचा गया, और क्योंकि आगे यह बदलाव code में नहीं जाएगा, इसलिए पहली “उपलब्धि” में खोई functionality को वापस पाने की दूसरी “उपलब्धि” भी हासिल हुई
    • सही, लेकिन इसमें मूल request से कहीं ज़्यादा risky काम भी किया गया। तत्काल outage या वास्तविक production issue की स्थिति में hardcoded value को parameter में धकेलना मुझे मूर्खता लगता है। इसमें संभावित pitfalls कहीं ज़्यादा हैं
      यहाँ कहना चाहिए था, “यह urgent है, इसलिए एक-character PR accept कर लीजिए। आपने जो improvement माँगे हैं, उनके लिए tracking tickets बना दिए हैं। पहले production issue ठीक करते हैं, बाकी उसके बाद करेंगे”
      reviewer को बस “LGTM!” कहना था। अगर ज़्यादातर engineers rules और guidelines के बीच रास्ता नहीं निकाल सकते, तो वह organization पागल है, और ठीक ऐसे ही मौकों पर seniority की कीमत साबित होती है
    • पहला कदम असली priority तय करना है। सबको पता होना चाहिए कि यह काम कितना delay होने पर लोगों की jobs प्रभावित होंगी
      अगर एक हफ्ता लगने पर भी किसी की job पर असर नहीं पड़ता, तो process follow कीजिए या बस न्यूनतम बदलाव कीजिए। अगर IT की वजह से लोग unpaid leave पर हैं, तो समस्या सुलझने तक जिन-जिन की ज़रूरत है, वे सब एक ही room में होने चाहिए, चाहे physical हो या virtual
      यहाँ वह context नहीं है। लेकिन अगर Ed और पूरी approval line को वह context पता नहीं था, तो यह system failure है। अगर उन्हें पता होता कि किसी का किराया दाँव पर लगा है, तो कोई senior शायद तुरंत उसके बाद fix करने के लिए दूसरा ticket बनवाता। और अगर नहीं, तो वह भी management की सुलझाने वाली समस्या है
    • “कोड की एक लाइन बदलने में 6 दिन” बस एक तथ्य है। बीच में system बेहतर हुआ, यह हिस्सा mandatory requirement नहीं था
    • audit requirement शायद उस file की version history से पूरी हो सकती थी जिसमें वह hardcoded value थी। अगर version control ही नहीं था, तो फिर समस्या कहीं बड़ी थी

  • यह कहानी असल में hardcoded value की एक-line change के ठीक-ठाक तरीके से निकल जाने का मामला है
    आप ऐसा scenario सोच सकते हैं जहाँ किसी ने backlog months की संख्या को smart और clever दिखने के लिए 2-bit value में store किया हो। यानी सिर्फ़ 0, 1, 2, 3 ही संभव हों। testing के दौरान यह कई layers नीचे, किसी untested downstream service या low-code automation service में छिपा हो सकता है, इसलिए समस्या दिखे ही नहीं
    उस value को 4 करने पर backlog 0 हो सकता है। नतीजा क्या होगा, यह पता नहीं। वह service production queue के सारे jobs cancel कर सकती है, या customers को jobs cancel होने के emails भेज सकती है
    ऊपर से यह आसान change लग सकती है, लेकिन अगर policy change को urgent issue बनाकर software team तक पहुँचाया गया है, तो management को बेहतर planning करनी चाहिए, यूँ ही issue priority को हिलाना-डुलाना नहीं चाहिए

    • माँगे गए बदलाव में additional testing या risk reduction से जुड़ी कोई चीज़ नहीं थी
      उल्टा, change की “cost” के नाम पर आसपास के कई हिस्सों को refactor करने की माँग करके risk बढ़ा दिया गया
    • चीज़ें बिगड़ने के असंख्य तरीके हैं। असली सवाल शायद यह है कि बिगड़ने पर ज़िम्मेदारी कहाँ जाएगी
      अगर बड़ा boss कहे, “मैंने risk लेकर इसे आगे बढ़ाने का फैसला किया है, और नतीजा भी स्वीकार करूँगा,” तो अच्छा है। अगर programmers पर मार पड़े, तो अच्छा नहीं है
    • मेरा मानना है कि सही लोगों और process का पालन किया गया। लेकिन अगर leads को इकट्ठा करके meeting रखी जाती और काम की अहमियत व priority पर सहमति बना ली जाती, तो बहुत समय बच सकता था
      अगर यह core functionality के लिए time-sensitive और important update था, तो operations owner को software के average deployment time का पता होना चाहिए था, और उसे सामान्य development pipeline में high priority पर डालने के बजाय fast-track handling के लिए टीम बनानी चाहिए थी
    • Knight Capital याद आता है

  • code review अच्छी नीयत से शुरू होता है। लेकिन आखिर में कोई gatekeeper जम जाता है और तुच्छ कारणों से हर चीज़ reject करने लगता है
    वह कहता है कि उसे “code quality” बचाने की परवाह है। लेकिन ऐसा bug code जिसे fix किया जा चुका हो फिर भी लंबे समय तक पड़ा रहे, या ऐसी feature जो delay होती रहे और कोई इस्तेमाल ही न कर पाए, उससे बुरा कुछ नहीं
    मैं ऐसे process की सिफारिश करता हूँ जिसमें comments की अनुमति हो, लेकिन reviewer commit को block न कर सके। यह भरोसा होना चाहिए कि हर developer सावधानी से काम करेगा और काम के अनुरूप बदलाव करेगा। CI का इस्तेमाल भी किया जा सकता है, और टीम के हिसाब से यह सब काफ़ी अच्छा चल सकता है

    • तब engineering leader को उस व्यक्ति को रोकना चाहिए। dysfunction कई तरह से सामने आता है, और overzealous review भी उनमें से एक है
      process बदलकर pathological reviewer को ignore करने लायक बना देना ज़्यादा से ज़्यादा आधा-अधूरा उपाय है
      blocking को लेकर मेरी मिली-जुली भावना है। मैं समझता हूँ कि बड़ा लाल blocked चिन्ह परेशान करता है, इसलिए कई बार block करने के बजाय changes request करने वाला “soft block” करता हूँ। लेकिन जब PR पूरी तरह पटरी से उतर गया हो, आम तौर पर junior developer के मामले में, तब साफ़ संदेश देना उचित लगता है
    • यह तरीका तब काम करता है जब test coverage और testing quality ऊँची हो। और यह भी कोई जादू से पैदा नहीं होता सिर्फ़ इसलिए कि developers को उस speed से चलने दिया जाए जो manager अभी चाहता है
    • “हर code change के लिए reviewer ज़रूरी है” जैसे नियम से मुझे नफ़रत है। यह बहुत बड़ा अवरोध है, और ज़रूरी नहीं कि इससे code बेहतर ही बने

  • यह फ़ैक्टरी मज़दूरों और software developers के बारे में एक meta-स्तर की बात है
    इस कंपनी का लीडर 10% कम उपयोग होने पर भी फ़ैक्टरी मज़दूरों को निकालने को तैयार है। कुछ variables को adjust करके productivity बढ़ाई जा सकती है, लेकिन आखिरकार विकल्प पूरा उपयोग या बेरोज़गारी ही है। शायद यह इसलिए संभव है क्योंकि इन मज़दूरों को replace किया जा सकता है, peak season में फिर से hire किया जा सकता है, और प्रति कर्मचारी पैदा होने वाला profit inefficiency की अनुमति नहीं देता
    मैं software developer के रूप में काम करता हूँ। हमारी तरफ़ 90% से भी बहुत ज़्यादा underutilization होने पर ही किसी को निकालने का सोचा जाता है। बहुत से लोग हफ़्ते में सिर्फ़ 4 घंटे काम करते हैं। कोई भी हमारे मिनट-दर-मिनट समय या bathroom breaks वगैरह को manage नहीं करता
    अभी software के बड़े पैमाने पर capitalization का दौर है। यह हमेशा नहीं चलेगा। किसी दिन IT दुनिया का मुख्य infrastructure बन जाएगा और industry maintenance mode में चली जाएगी। तब हममें से ज़्यादातर की ज़रूरत नहीं रहेगी, हमें आसानी से replace किया जा सकेगा, और maintenance mode में हम जो profit पैदा करेंगे वह आज की तुलना में बहुत मामूली होगा
    फ़ैक्टरी मज़दूरों को अगर उनकी व्यक्तिगत productivity कम लगे तो आमतौर पर कुछ मिनटों या कुछ घंटों में निकाल दिया जाता है। मुझे लगता है कि हमारे जीवनकाल में software developers के साथ भी ऐसा शुरू हो जाएगा

    • “इन मज़दूरों को replace किया जा सकता है और peak season में फिर से hire किया जा सकता है” — यही असली फ़र्क है। फ़ैक्ट्रियाँ processes की systems के रूप में डिज़ाइन की जाती हैं, ताकि हर व्यक्ति से decision-making और variability हटाई जा सके
      आपको यह भी आँकना चाहिए कि आपकी अपनी skill set के साथ यह किस हद तक संभव है
      software के बड़े पैमाने पर capitalization के हमेशा न रहने वाली मूल बात से मैं सहमत हूँ। हर कंपनी को हमेशा नया software बनाने वाले engineers की ज़रूरत नहीं होती। यह IT से ज़्यादा film production जैसी creative business के करीब है, जहाँ boom और bust आते-जाते रहते हैं। अगर आप IT की बजाय development चुनते हैं, तो आपको यह जोखिम स्वीकार करना चाहिए। बस मुझे समझ नहीं आता कि अभी का समय ही peak क्यों होना चाहिए

  • व्यक्तिगत अनुभव से कहूँ तो, मैं कुछ सालों तक ऐसी टीम में काम करता रहा जहाँ formal code review था, फिर ऐसी टीम/कंपनी में चला गया जहाँ code review नहीं था। कोई भी किसी भी branch में freely commit और merge कर सकता था
    जॉइन करते समय मेरी भावनाएँ कुछ मिली-जुली थीं, लेकिन व्यवहार में यह बहुत ताज़गीभरा और empowering लगा, और मैं कुछ ही दिनों में productive हो गया

    • मैंने पहले एक ऐसी टीम में काम किया है जहाँ “Catholic code review” होता था, यानी push and pray
      टीम के goals को देखते हुए code review न होने वाला तरीका बहुत अच्छी तरह फिट बैठता था। वजह यह थी कि वह एक R&D group था, जिसका मुख्य लक्ष्य executives को “शानदार नए features” दिखाना था। short notice पर बहुत-सी requests आती थीं, लेकिन फेंक दिया जाने वाला code भी बहुत था
      demo के बाद executive कहते, “अच्छा लग रहा है, लेकिन business viability नहीं है,” और फिर repository को दोबारा छुआ ही नहीं जाता था। बेशक, कभी-कभी हमारी बनाई चीज़ product भी बन जाती थी, और तब एक downstream team उस scribble-जैसे code को production quality में बदलने की ज़िम्मेदारी लेती थी। वे लोग हमसे जलती हुई नफ़रत करते थे
    • मैंने देखा है कि high trust और लगभग 80% test coverage वाली छोटी टीमों में यह तरीका बहुत अच्छा काम करता है। process में PR नहीं था; tests pass हो जाएँ, जहाँ लागू हो वहाँ stakeholders को UX demo सफलतापूर्वक दिखा दिया जाए, और खुद संतुष्ट हो जाएँ, तो master में merge कर दिया जाता था
      नए team members को पहले 2–3 महीनों के लिए एक mentor दिया जाता था, जो उनके पास बैठता, अक्सर pair करता और उनका code देखता था
      यह 2.5 साल का project था, 20वें महीने में live गया, schedule और budget दोनों पर रहा, और मूल scope से ज़्यादा features दिए। कई दिनों में हम whiteboard के सामने 2–3 घंटे तक चर्चा करते थे। सब कुछ informal था और हमेशा सभी लोग शामिल नहीं होते थे
      अजीब बात यह थी कि इस project के दौरान तीन PM बदल गए। standup के अलावा email या contact न करने का सख़्त नियम था, और उन तीन में से दो इस setup में “काम” कर पाए। airport के IT chief को दो साल बाद जाकर समझ आया कि हमें PM की ज़रूरत ही नहीं थी
      नियम था कि codebase में कोई नया काम शुरू कर रहे हों तो कम-से-कम एक दूसरे developer से बात करनी होगी। हम एक बड़े private office में, जिसमें बड़ा whiteboard था, एक-दूसरे से बस कुछ फ़ीट की दूरी पर बैठते थे। stories को dedicated whiteboard पर index cards से manage किया जाता था, और अगर आप उसका सार वहाँ नहीं समझा सकते थे तो उसे छोटे हिस्सों में बाँटना पड़ता था
      हर व्यक्ति अपनी machine खुद बनाता था और जितने monitors चाहे इस्तेमाल कर सकता था। यह एक बड़े international airport का billing और charging system था, और accounting lead, director और दूसरे users बस कुछ office doors की दूरी पर थे। वे शायद ही कभी standup मिस करते थे, और real-time questions के लिए हमेशा उपलब्ध रहने की policy थी
      standup आमतौर पर status report नहीं होता था, बल्कि informal discussion, demo और Q&A होता था। status update के लिए whiteboard पर लगे cards देखना ही काफ़ी था
      final system ने पहले महीने से ही और उसके बाद हर महीने revenue में 8% सुधार किया। accounting director को airport authority board के सामने इसकी व्याख्या करनी पड़ी। airlines के साथ billing disputes और reconciliation प्रति माह 9 दिनों से घटकर 1 दिन रह गए, और monthly billing workload 18 दिनों से घटकर 5 दिन हो गया। मुख्य user की भूमिका senior accountant से हटाकर 3 साल अनुभव वाले एक junior accountant को दी जा सकी
      production bugs पहले साल में 6 थे, और गलत invoices 0 थे। उसके बाद का data नहीं है। इससे पहले rewrite की कोशिश 3 साल में असफल हो गई थी
    • ईमानदारी से कहूँ तो security और audit के नज़रिए से यह किसी डरावने सपने जैसा लगता है। फिर भी, छोटी projects करने वाली agency या वैसी किसी जगह पर यह चल सकता है

  • code review process का इस्तेमाल करके high-change, लगातार बदलती रहने वाली टीमों को तब तक बंधक बनाए रखना जब तक वे उसके हिसाब से फिट न हो जाएँ, यह dysfunction है
    “चलते-चलते upgrade” की policy आधे-अधूरे transition की लंबी tail छोड़ देती है, जिससे नए developers के लिए codebase के साथ सहज होना और मुश्किल हो जाता है। product focus इस बात की गारंटी नहीं देता कि codebase का हर हिस्सा नियमित रूप से छुआ जाएगा, इसलिए transition कभी ख़त्म ही नहीं होता। product के कुछ क्षेत्र सालों तक छोड़े रह जाते हैं
    अगर नई policy में transition करना महत्वपूर्ण है, तो इसे एक focused project के रूप में काटकर पूरा करना चाहिए; और अगर नहीं, तो फिर यह महत्वपूर्ण ही नहीं है

    • सही कहा। management का planning को लगभग छोड़ देना भयानक है
      वे उम्मीद कर रहे हैं कि codebase में बिखरे unplanned work के time bombs किसी random, unrelated काम के दौरान फट जाएँ
      अगर नया standard महत्वपूर्ण है, तो code update करना चाहिए; नहीं तो नहीं करना चाहिए। randomness पर भरोसा करके urgent work को धीमा करना कोई planning नहीं है

  • इसे code review की समस्या के रूप में पढ़ना ग़लत है। समस्या यह है कि कंपनी ने principles के ऊपर internal barriers से बने process को रख दिया
    हर process में एक escape hatch होना चाहिए। अगर कोई change किसी की नौकरी जाने से रोक सकता है, तो हर escape hatch सक्रिय हो जाना चाहिए