Bus Number – GitHub प्लगइन जिसे सहकर्मियों ने न लिखने को कहा

 (scannedinavian.com)
1 पॉइंट द्वारा GN⁺ 2024-11-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक डेवलपर ने छंटनी के दौरान रेवेन्यू-जनरेट करने वाले कोड के एकमात्र योगदानकर्ता के गायब हो जाने का अनुभव किया, और उसी से प्रेरित होकर GitHub Enterprise में “ऐसे लोगों” को खोजने के लिए truck factor प्लगइन बनाने की सोची जिन्हें खोना नहीं चाहिए
  • सहकर्मियों को चिंता थी कि यह मेट्रिक जल्दी ही Goodhart’s Law का शिकार हो जाएगा, और जिन लोगों की रक्षा करनी चाहिए उन्हें खोजने के बजाय यह “किन्हें निकालना चल सकता है” ढूंढने का प्रबंधन टूल बन सकता है
  • मूल Truck-Factor repository और डेटा अब भी उपयोग में लाए जा सकते थे, लेकिन डेटा कब इकट्ठा किया गया था यह स्पष्ट नहीं था, और README की प्रक्रिया भी ज्यों-की-त्यों दोहराई नहीं जा सकी, इसलिए मैन्युअल सुधार करने पड़े
  • पुनर्गणना कई GitHub repositories को gnu parallel से clone करके फिर Java code चलाने के तरीके से की गई, और Linux kernel के लिए linguist फ़िल्टर के बिना truck factor 12, जबकि फ़िल्टर लगाने पर 8 आया
  • 2015 के preprint में दिए गए 90 और आधिकारिक publication के 57 की तुलना में यह परिणाम और कम निकला, इसलिए यह कहना मुश्किल है कि Linux kernel का bus factor बेहतर हुआ है

Bus Factor और खतरनाक प्लगइन का विचार

  • Bus Factor या Truck Factor का मतलब है टीम के कम-से-कम कितने सदस्य अचानक गायब हो जाएँ तो ज्ञान रखने वाले लोगों की कमी से प्रोजेक्ट रुक जाए
  • इसकी शुरुआत लगभग 2015 में कंपनी की छंटनी प्रक्रिया के दौरान हुई, जब कंपनी के लिए कमाई करने वाले एक codebase के एकमात्र contributor को निकाल दिया गया
  • Truck Number का विचार आने के बाद, GitHub Enterprise प्लगइन के रूप में “किन्हें नहीं निकालना चाहिए” यह निकालने का आइडिया बना
  • गुरुवार दोपहर की lightning talk में 5 मिनट तक इस प्लगइन को दिखाने पर, सहकर्मियों ने कहा कि मैनेजर इसे “किन्हें निकाला जा सकता है” पता लगाने के टूल की तरह इस्तेमाल कर सकते हैं
  • इस प्रतिक्रिया का मूल बिंदु Goodhart’s Law था

मौजूदा Truck Factor शोध और उसे दोहराने की कोशिश

  • मूल शोध में कई लोकप्रिय GitHub projects के लिए यह गणना की गई थी कि प्रोजेक्ट रुकने के लिए कितने लोगों का गायब होना ज़रूरी होगा
  • इसमें Linux kernel भी शामिल था
  • लेख की शुरुआत में कहा गया है कि पहले preprint में Linux के लिए 80 लोगों के जाने पर रुकने की बात थी, जबकि आगे चलकर 2015 के preprint में 90 और full publication में 57 का आंकड़ा दिया गया है
  • mclare के साथ मिलकर लगभग 10 साल बाद यह देखने की कोशिश की गई कि truck factor बेहतर हुआ या नहीं
  • मूल लेखकों की GitHub repository अब भी इस्तेमाल की जा सकती थी

डेटा और execution environment की सीमाएँ

  • पेपर का डेटा JSON में दिया गया था, और मूल visualization scrape की जा सकने वाली CSV पर आधारित था
  • लेकिन डेटा संग्रह की तारीख पता नहीं चल सकी
  • README के निर्देश सीधे काम नहीं कर रहे थे, इसलिए GitHub issues देखकर चलाने की विधि ठीक करनी पड़ी
  • मूल CSV के पहले column से GitHub repositories की सूची निकाली गई और सभी repositories clone की गईं
  • gnu parallel से कई git clone commands एक साथ चलाई गईं

gnu parallel, linguist, और NixOS में अटके हिस्से

  • gnu parallel में -j 8 देने के बावजूद, लैपटॉप के सभी 32 cores इस्तेमाल होते दिखे
  • एक समय पर दिखने वाली git clone processes तो 8 थीं, लेकिन कई git index-pack processes सभी cores इस्तेमाल कर रही थीं
  • संभावित कारण यह माना गया कि git index-pack fork किए गए child processes थे, इसलिए parallel दूसरी git clone शुरू कर देता था
  • Truck Factor code, documentation files को बाहर रखने के लिए GitHub के linguist का उपयोग करता है
  • NixOS environment में Ruby का अनुभव न होने से Ruby Gems install करने का हल समय पर नहीं मिल सका, और Nix flake में linguist plugin install करने का तरीका या pull request मांगा गया

वास्तविक पुनर्गणना की प्रक्रिया

  • मूल repository को fork करके local में clone किया गया, फिर README के अनुसार execution method को समायोजित किया गया
  • mvn package से Java source को jar में compile किया गया
  • पहले numpy GitHub repository पर हर step आज़माया गया, फिर सभी repositories की पुनर्गणना की गई
  • mclare ने मूल visualization की CSV डाउनलोड कर उसके पहले column को GitHub repository list में बदल दिया
  • execution flow इस प्रकार था
    • parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt) से repositories clone की गईं
    • awk error से बचने के लिए gittruckfactor/scripts directory में जाया गया
    • commit_log_script.sh से हर repository की git commit जानकारी निकाली गई
    • gittruckfactor-1.0.jar चलाकर निकाले गए commit data को process किया गया
  • घर के तेज gigabit internet connection पर सभी repositories को sequentially clone करने में 17.5 मिनट लगे
  • हर repository को process करने में भी लगभग 18 मिनट लगे प्रतीत हुए

Linux kernel पुनर्गणना के परिणाम

  • Linux kernel के उदाहरण output में TF = 12, coverage = 49.98% था
  • TF authors में Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner, Krzysztof Kozlowski आदि शामिल थे
  • Linus Torvalds को 5,712 files और 6.59% के रूप में दिखाया गया
  • linguist plugin के बिना, यानी documentation और third-party libraries को फ़िल्टर किए बिना, Linux kernel truck factor 12 था
  • mclare ने अपने system पर linguist plugin install करने के बाद Linux kernel truck factor 8 पाया

गणना में छूटे तत्व और आगे जाँचने योग्य बातें

  • इस गणना में review process को शामिल नहीं किया गया
  • अनुभव बढ़ने के साथ डेवलपर के लिए keyboard पर सीधे code लिखने से ज़्यादा review करना पड़ता है, यह भी एक समस्या है
  • आगे जाँचने योग्य बातें ये थीं
    • क्या truck factor गणना git के co-authored-by और reviewer headers को शामिल करती है
    • अगर नहीं, तो क्या इन्हें गणना में जोड़ा जा सकता है
    • 10 साल बाद Linux के आंकड़े इतने अलग क्यों निकले
    • क्या मूल पेपर की तरह developer aliases मिलाने के लिए Levenshtein distance 1 लागू न करने से परिणाम प्रभावित हुआ
    • अगर Linux kernel repository को 2015 के मध्य समय-बिंदु पर checkout किया जाए, तो क्या वही code अब भी 80 देता है
    • 2016 में algorithm update होने के कारण क्या बाद के आंकड़े फिर से निकाले जा सकते हैं
  • मूल पेपर के 156 citations देखकर यह पता लगाया जा सकता है कि कोई बेहतर गणना विधि मौजूद है या नहीं
  • Rust जैसे हाल के बड़े projects 2015 के पेपर में शामिल नहीं थे, इसलिए आज के लोकप्रिय projects और पुराने इतिहास की तुलना की जा सकती है
  • किसी भी git repository के लिए साल-दर-साल truck number निकालने वाला script भी बनाया जा सकता है

और भी कम हुआ Bus Factor

  • जिस सवाल की जाँच करनी थी, वह यह था कि क्या truck factor समय के साथ बेहतर हुआ
  • परिणाम यह संकेत देते हैं कि यह बेहतर नहीं हुआ, बल्कि और खराब हुआ
  • Linux kernel का परिणाम मूल पेपर के आंकड़ों से काफी कम निकला
  • documentation और third-party libraries को फ़िल्टर करने या न करने के आधार पर Linux kernel का परिणाम 12 से घटकर 8 हो गया
  • अधिक visualizations और विवरण mclare की पोस्ट में देखे जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2024-11-13
Hacker News की राय

  • https://codescene.com/ की सुविधाओं में से एक ठीक यही है
    यह knowledge islands ढूंढकर उन्हें बार-बार बदलने वाले code से जोड़ता है, और ऐसे जोखिम भरे hotspots पहचानता है जहां बदलाव बहुत होते हैं लेकिन knowledge distribution कम होता है
    जब कोई इस्तीफा देने की मंशा बताता है, तो आसानी से देखा जा सकता है कि कौन-सा code सिर्फ वही व्यक्ति जानता है, इसलिए handover plan बनाना भी आसान हो जाता है
    मैंने कभी नहीं सोचा कि इसका दुरुपयोग हो सकता है; मूल रूप से यह visibility के लिए tool है। कोई manager इसे उस तरह इस्तेमाल करता है तो वह खराब manager है, और अगर वह पहले से ऐसा है तो यह tool उसे बदलने वाला नहीं है

    • “दुरुपयोग” को बहुत भोलेपन से नहीं देखना चाहिए। मान लीजिए आप किसी देश की intelligence agency से हैं। मान लें Tussia नाम का देश, जिसकी पहुंच दुनिया के military equipment में इस्तेमाल होने वाले प्रमुख kernel Kinux तक बंद है, और आपको पता चलता है कि बगल के office वाला व्यक्ति उस kernel को अपने देश के internal use के लिए fork करने का project शुरू कर चुका है
      अगर promotion की महत्वाकांक्षा है, तो acquisition/handling department से “nerds से नजदीकी बढ़ाने की special training पा चुकी 8 महिला agents” मांग सकते हैं, और failure की स्थिति के लिए polonium की 8 doses भी backup में मांग सकते हैं
      यह पूरी तरह काल्पनिक लग सकता है, लेकिन मैं एक unicorn startup CEO को जानता हूं जो seed investment ढूंढ रहा था और जिसने सचमुच शुरुआती हिस्से जैसी घटना झेली थी
    • मैंने तीन workplaces में Pluralsight Flow लागू होते देखा है, और उनमें से दो में managers ने तुरंत metrics को feedback, performance reviews और hiring/firing decisions में इस्तेमाल करना शुरू कर दिया
      तीसरे workplace में developers ने इस pattern को दूर से ही पहचान लिया और tool के उपयोग या evaluation को ही अस्वीकार कर दिया
      ऐसे tools की कीमत बेहिसाब ज्यादा होती है, इसलिए जिन्होंने approval दिया है उन्हें किसी न किसी तरह ROI निकालना पड़ता है। productivity, output और knowledge silos को सही तरीके से मापने का तरीका नहीं होता, इसलिए अंत में बात “इस हफ्ते Jose के PR कम थे” जैसी हो जाती है
    • visibility वाला use case अपने आप में शानदार है, लेकिन सिर्फ तब जब वह उसी दायरे में रह सके
      समस्या यह है कि developers भी इसे देखकर निकाले न जा सकने वाले कर्मचारियों की सूची में आने के लिए target projects या components की ओर move करने की कोशिश कर सकते हैं। आदर्श रूप से workers मिलकर truck factor को 0 बना सकते हैं, ताकि किसी को निकालना मुश्किल हो जाए
      बेशक, ऐसा होने पर यह लगभग पूरी तरह समय की बर्बादी बन जाएगा, और blogger के colleagues ने जो मूल बात कही थी—“यह तुरंत Goodhart’s Law में फंस जाएगा”—वह साबित हो जाएगी
    • कोई external consulting company कंपनी की layoffs में मदद करने के लिए भी इसका इस्तेमाल कर सकती है। manager कितना भी अच्छा हो, यह संभव है

  • Amazon में ऐसे numbers को code system से किसी भी manager द्वारा चलाए जा सकने वाले report के रूप में आसानी से देखा जा सकता है, और team क्या कर रही है तथा कौन-से risks हैं यह देखने के कई और तरीके भी हैं। व्यक्तिगत रूप से मुझे यह उपयोगी लगता है
    bus factor सिर्फ एक नजरिया है, और दूसरे नजरिये से यह silos, दूसरों के साथ collaborate न करने वाले engineers, और ऐसे areas पहचानने व सुधारने में मदद करता है जहां engineers को आसानी से move नहीं किया जा सकता
    कुछ developers replaceability से डरते हैं और सोचते हैं कि जो system सिर्फ वे जानते हैं वही job security है, लेकिन उल्टा यह technical risk भी है और किसी अच्छे engineer को ज्यादा महत्वपूर्ण projects पर जाने से रोकने वाला factor भी हो सकता है। जब आप किसी नापसंद system से तंग आ जाएं, तो यह दूसरी चीजें करने का रास्ता भी है

    • मुझे replaceability से डर नहीं है। अगर कोई जगह मुझे नहीं चाहती, तो मैं भी वहां रहना नहीं चाहूंगा
      लेकिन replaceability का विचार बड़ा overhead पैदा करता है और talented लोगों को उनकी पूरी capacity पर इस्तेमाल नहीं होने देता, क्योंकि वे वास्तव में replaceable नहीं होते
      कुछ जगहों पर इसकी जरूरत होती है, लेकिन दूसरी जगहों पर process overhead, bus factor की तुलना में project success के लिए कहीं बड़ा risk बन जाता है
    • मैं एक developer को जानता हूं जिसे सिर्फ इसलिए move और promotion से मना कर दिया गया क्योंकि उसका replacement आसानी से नहीं मिल सकता था
      नतीजा यह हुआ कि वह 3 महीने के अंदर कंपनी छोड़ गया
    • “अगर आपको replace नहीं किया जा सकता, तो आपको promote नहीं किया जा सकता”
    • किसी employee के नजरिये से, जिसका मुख्य लक्ष्य company के profits को optimize करना नहीं है, यह सोचना भी एक realistic strategy है कि जो system सिर्फ वही जानता है वही job security है
    • अपने पूरे career में मैंने खुद को और दूसरे developers को जितना हो सके replaceable बनाने की कोशिश की है। digitalization work का बड़ा हिस्सा मूल रूप से यही होता है, और knowledge silos से निपटना परेशान करने वाला भी है
      backend में TypeScript का काफी इस्तेमाल करने की एक वजह यह है कि छोटी team को जानने वाली languages की संख्या घटकर एक रह जाती है। इसलिए frontend developer छुट्टी पर जाए तो वह सच में disconnect कर सकता है, और कोई और cover कर सकता है। कोई नौकरी बदलकर चला जाए तो दर्द कम होता है
      यह मेरे लिए कभी समस्या नहीं बना, और मैं replaceability को healthy system का हिस्सा मानता हूं। management side में कुछ साल रहने पर सबसे पहले यही सीखने को मिला कि “हर कोई replaceable है, बस यह cost का सवाल है।” इसलिए knowledge level बहुत ज्यादा हो तो उल्टा management उस risk को कम करने की कोशिश करते हुए इसे आपके खिलाफ भी मान सकता है। खासकर economic reasons से होने वाले layoffs काफी random भी होते हैं
      फिर भी मैं ऐसी जगह काम नहीं करना चाहूंगा जो ऐसे हास्यास्पद metrics इस्तेमाल करती हो। अच्छा काम करने में जितनी ज्यादा red tape लगाई जाती है, उतनी कम संभावना होती है कि मैं वहां साथ काम करना चाहूं। ऐसी चीजें लोगों को अच्छा काम करने के बजाय metrics को game करने पर मजबूर करती हैं और productivity व quality के लिए खराब culture बनाना आसान कर देती हैं

  • gnu parallel अनुरोध के मुताबिक 8 git clone काम एक साथ चला रहा है, और हर git clone अपनी मर्जी से कई index-pack threads शुरू कर रहा है।
    यहां git config से pack.threads को अस्थायी रूप से 1 पर सेट करना मददगार होगा।

    • यह समस्या धीरे-धीरे आम होती जा रही है। दोनों layers CPU या cores की संख्या के बराबर parallelize करके पूरी machine इस्तेमाल करना चाहती हैं, और अंदरूनी layer में N² threads/processes बन जाते हैं।
      क्योंकि यह वर्ग के रूप में बढ़ता है, CPUs जितने ज्यादा होंगे समस्या उतनी गंभीर होगी। 32 cores पर 32² = 1024 होता है, और असल में Parallel में 8 निर्दिष्ट किए गए थे, इसलिए यह अधिकतम लगभग 256 index-pack processes पर रुका होगा। फिर भी इसे संभालने के लिए बहुत memory चाहिए, और असल में कोई फायदा नहीं मिलता।
      समाधान यह है कि दोनों layers में से केवल एक को parallelize किया जाए।
      pack.threads के बारे में man git-config का विवरण यह है: optimal delta matches खोजते समय बनाए जाने वाले threads की संख्या निर्दिष्ट करता है, और git-pack-objects(1) को pthreads के साथ compile किया गया होना चाहिए। वरना इसे warning के साथ ignore कर दिया जाता है। यह multi-processor machine पर packing time घटाने का विकल्प है, लेकिन delta search window के लिए जरूरी memory threads की संख्या से गुणा हो जाती है। 0 निर्दिष्ट करने पर Git CPU count को auto-detect करके उसी के अनुसार thread count सेट करता है।
    • git config से अस्थायी setting करने के बजाय बस git -c pack.threads=1 clone इस्तेमाल कर सकते हैं: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

  • यह व्याख्या बहुत अच्छी नहीं है। मुझे लगता है यह लेख सभी engineering leaders के लिए है।
    बस फैक्टर का मतलब है कि टीम में किसी को, या खुद आपको, बस टक्कर मार दे तो टीम को कितनी तकलीफ होगी।
    हर team member के लिए आदर्श बस फैक्टर 0 है। शुरू में यह “सबको expendable बना दो” जैसा लग सकता है, लेकिन असल में यह लगभग उसका उलटा है, और यही मुख्य बात है।
    टीम इतनी अच्छी होनी चाहिए कि वह a) autonomous हो और b) उसमें कोई mystery न हो। आदर्श स्थिति में हर कोई समझता है कि सब कुछ कैसे काम करता है। नए कर्मचारी को तुरंत value पैदा करना शुरू कर पाना चाहिए, और जाने वाले कर्मचारी को यह भरोसा होना चाहिए कि कोई अज्ञात क्षेत्र बाकी नहीं है।
    ऐसा आदर्श दल जिसमें सबका BF 0 हो, वांछनीय है। इसका मतलब है कि team members replaceable हैं, और कोई बीमार हो, छुट्टी पर जाए, सचमुच छोड़कर जाए या हटाया जाए, तो सभी team members खाली जगह भर सकते हैं।
    ज्यादा महत्वपूर्ण यह है कि 0 BF सरलता का प्रतिबिंब है। software, build·test·deploy pipelines, documentation और support system सब cohesive और consistent होने चाहिए। जानकारी को team members के भीतर silo करना खराब है, और सबको build और deploy कर पाना चाहिए।
    0 BF एक healthy metric है, लेकिन इसे emails की संख्या, commits की संख्या, PRs की संख्या, code lines, response speed, GitHub heatmap जैसी चीजों से कभी नहीं मापा जाता। ऐसे metrics कुछ नहीं दिखाते, बल्कि नुकसानदेह और भयानक metrics हैं।
    ऐसे metrics से लोगों का मूल्यांकन करना typewriter के सामने बंदर बैठाने से अलग नहीं है। और startups को यह बात सुननी चाहिए।

    • बस फैक्टर के बारे में मैंने हमेशा उलटा सुना है। जैसे, “project को आगे चलाना असंभव बनाने के लिए कितने लोगों को बस की टक्कर लगनी होगी,” और मैं समझता था कि optimal value team members की संख्या के बराबर होती है।
      लगता है वही concept है, लेकिन यह हैरान करने वाला है कि वह संख्या हमेशा एक ही दिशा में इस्तेमाल नहीं होती।
    • मैंने ऐसे project पर काम किया है जहां उस खास technology वाले लोग दुनिया भर में उंगलियों पर गिने जा सकते थे। उस समय bus factor निश्चित रूप से 1 था।
      जो projects संभावनाओं की सीमा को आगे धकेलते हैं, उनमें सरलता कभी-कभी विकल्प नहीं होती। बेशक कुल software projects में यह छोटी हिस्सेदारी है, लेकिन जब ऐसा काम किया जा रहा हो जो पहले कभी नहीं हुआ, तो code को जितना हो सके सरल रखने से ज्यादा बड़ी चिंता यह होती है कि “आखिर इसे करेंगे कैसे।”
      इसका मतलब यह नहीं कि code quality कम हो सकती है। बस, कठिन काम करते समय कभी-कभी complex code चाहिए होता है, और कई generations बाद ही design patterns व्यवस्थित होकर उस कठिन काम को कम complex code से संभव बना पाते हैं। यह 10 साल बाद भी हो सकता है।
    • अगर पहले दिन से कोई भी code समझ सकता है और domain knowledge की जरूरत ही नहीं है, तो उस product या team का value proposition क्या है?
      अगर सबसे complex चीज जो आप बना सकते हैं वह todo app भर है, तो मुझे नहीं लगता कि आप society के लिए ज्यादा value बना रहे हैं।
    • जो लोग अपना काम अच्छी तरह करते हैं और आत्मविश्वासी हैं, वे सक्रिय रूप से अपना बस फैक्टर घटाने की कोशिश करते हैं।
      bus factor ऊंचा होना इसका मतलब है कि employer आपको आपकी future potential से ज्यादा, अतीत में किए गए काम की वजह से पकड़े हुए है।
    • सेना ऐसा ही सोचती है। वह मानकर चलती है कि लोगों को खोने पर भी काम चलता रहना चाहिए।

  • मूल paper की मुख्य दलील यह हिस्सा है।
    “हमारा अनुमान coverage assumption पर निर्भर करता है। अगर मौजूदा authors का समूह system की मौजूदा files के 50% से कम को cover करता है, तो system को गंभीर delay झेलना पड़ेगा या उसके रुक जाने की संभावना अधिक है।”
    यहां file का author वह user माना गया है जिसने पहले से calculated weight के आधार पर उस file में meaningful contribution किया हो।

  • एक तरफ, अगर इस तरह के dashboard metrics पहले से किसी enterprise software में शामिल न हों तो मुझे उल्टा आश्चर्य होगा। मेरी पिछली company के management ने सच में पूछा था कि क्या department में किसने सबसे ज्यादा emails भेजे और पाए, इसकी daily report बनाई जा सकती है।
    मुझे यह पसंद नहीं था कि बात किस दिशा में जा सकती है, इसलिए मैंने मना कर दिया, लेकिन एक और colleague ने बना दिया। उम्मीद के मुताबिक, सबसे ज्यादा emails पाने और भेजने वाला व्यक्ति system administrator था, क्योंकि कई servers के automatic email sender के रूप में उसका account सेट था। वह रोज खुद को सैकड़ों notification emails भेज रहा था, और subscribed newsletters और summary mails भी उसमें जुड़ रहे थे।
    दूसरी तरफ, अगर colleagues ने सबने कहा हो कि ऐसा काम मत करो जिससे उनकी jobs पर असर पड़ सकता है, फिर भी कोई इसे hobby project के रूप में आगे बढ़ाए, तो यह काफी घटिया व्यवहार लगता है।

    • 2015 में जब colleagues ने कहा था कि मत करो, तब मैंने इसे नहीं बनाया।
      बस मैं देखना चाहता हूं कि जो open source software मैं इस्तेमाल करता हूं, उसने अपनी survivability बढ़ाने लायक knowledge अच्छे से फैलाई है या नहीं।
      उस घटिया हरकत से मैंने इनकार किया था।
    • यह बेतुका metric है।

  • “career ladder पर ऊपर चढ़ते हुए developers को सीधे keyboard पर code लिखना कम करना चाहिए और review ज्यादा करना चाहिए” — मुझे लगता है यह tech companies में आम गलतफहमी है।
    हम एक बेहतरीन developer को average manager में बदलना नहीं चाहते।

    • सही। ऐसे technical leads होते हैं जिनकी code लिखने की क्षमता शानदार होती है, लेकिन leadership या feedback जैसी capabilities बेहद खराब होती हैं।
      वह technical lead के बजाय senior developer के रूप में कहीं बेहतर रहेगा। अगर वह manager बन गया तो team कितनी परेशान होगी, इसकी कल्पना करना मुश्किल है।
    • अगर आप code review को “management” मानते हैं, तो यह काफी गंभीर चिंता की बात है।

  • इस काम की दुखद विडंबना यह है कि सवाल अब भी गलत है
    जब किसी startup को layoffs करने पड़ते हैं, तो सवाल यह नहीं होना चाहिए कि “किसे निकालने पर भी मौजूदा business चलाए रखा जा सकता है”, बल्कि यह कि “कौन-सी team इतनी तेज़ी से product का अगला version बना सकती है कि कंपनी डूबे नहीं”
    हर मोड़ आखिरकार एक मोड़ ही होता है, और कई कंपनियां इसलिए मर गईं क्योंकि वे पर्याप्त तेज़ी से रास्ता नहीं चुन सकीं

  • CPAN बहुत पहले से bus factor को track करता आया है। उदाहरण के लिए https://metacpan.org/pod/Moose बाईं तरफ की जानकारी वाली column में Bus Factor 5 दिखाता है

  • हम इसे lottery factor कहना पसंद करते हैं
    मतलब यह कि अगर कोई lottery जीतकर बिजली और telecom network से दूर किसी tropical island पर चला जाए, तो क्या project चलता रह सकता है
    ऐसा कहने पर यह कम डरावना लगता है

    • lottery जीतने वाला व्यक्ति 2 हफ्ते पहले resignation notice दे सकता है, और सच में जरूरत पड़े तो बाद में फोन भी किया जा सकता है
      bus से टकराया व्यक्ति तुरंत गायब हो जाता है। यह वही बात नहीं है
    • अच्छे कर्मचारी अपना project hand over करने और सवालों के जवाब देने की कोशिश करेंगे, लेकिन उन मामलों के लिए भी तैयार रहना चाहिए जहां वे ऐसा नहीं कर पाते
    • job change को sudden death कहकर नरम बनाना अच्छा स्वाद नहीं छोड़ता
      कुछ लोगों को sports metaphors भी पसंद नहीं होते, लेकिन कम से कम वे military metaphors से बेहतर हैं
      वैसे भी अक्सर proper handover नहीं होता, इसलिए suddenness खुद शायद उतना अहम factor न हो
    • bus से टकरा जाना शायद ज्यादा आसान घटना हो सकती है, इसलिए उस संभावना को भी reflect करना चाहिए
    • किसी बड़ी lottery के winner या bus से टकराए व्यक्ति को तो नहीं जानता, लेकिन cryptocurrency rich बनकर नौकरी छोड़ने वाले कई लोगों को जानता हूं