Bus Number – ปลั๊กอิน GitHub ที่เพื่อนร่วมงานขอว่าอย่าเขียนมัน

• นักพัฒนาคนหนึ่งเคยเจอเหตุการณ์ที่การเลย์ออฟทำให้ ผู้มีส่วนร่วมเพียงคนเดียวของโค้ดที่สร้างรายได้ หายไป จึงอยากสร้างปลั๊กอิน truck factor บน GitHub Enterprise เพื่อหา “คนที่ห้ามเสียไป”
• เพื่อนร่วมงานกังวลว่าเมตริกนี้จะติดกับดัก Goodhart’s Law ในไม่ช้า และกลายเป็นเครื่องมือผู้บริหารสำหรับหาว่า “ใครที่ปลดออกได้” มากกว่าจะปกป้องคนสำคัญ
• แม้รีโพซิทอรีและข้อมูลของ Truck-Factor ต้นฉบับยังใช้งานได้ แต่วันที่เก็บข้อมูลไม่ชัดเจน และขั้นตอนใน README ก็ไม่สามารถทำซ้ำได้ตรง ๆ จึงต้องแก้ด้วยมือ
• การคำนวณใหม่ทำโดยโคลนหลาย GitHub repository ด้วย gnu parallel แล้วรันโค้ด Java; สำหรับ Linux kernel ได้ค่า truck factor 12 เมื่อไม่ใช้ตัวกรอง linguist และเหลือ 8 เมื่อใช้ตัวกรอง
• ผลลัพธ์ออกมาต่ำกว่าตัวเลขในงานวิจัยเดิมคือ preprint ปี 2015 ที่ 90 และ publication ฉบับสมบูรณ์ที่ 57 ทำให้ยากจะบอกว่า bus factor ของ Linux kernel ดีขึ้น

---

Bus Factor และไอเดียปลั๊กอินที่อันตราย

• Bus Factor หรือ Truck Factor คือจำนวนสมาชิกขั้นต่ำที่ต้องหายไปอย่างกะทันหันก่อนที่โปรเจ็กต์จะหยุดชะงักเพราะขาดคนที่มีความรู้
• จุดเริ่มต้นมาจากช่วงราวปี 2015 ระหว่างการเลย์ออฟในบริษัท ซึ่งมีกรณีที่ผู้มีส่วนร่วมเพียงคนเดียวของบางโค้ดเบสที่ทำเงินให้บริษัทถูกปลดออก
• หลังนึกถึง Truck Number ก็เกิดไอเดียทำปลั๊กอิน GitHub Enterprise เพื่อคำนวณว่า “ใครที่ห้ามปลด”
• เมื่อนำเสนอปลั๊กอินนี้ 5 นาทีใน lightning talk ช่วงบ่ายวันพฤหัสบดี เพื่อนร่วมงานมองว่าผู้บริหารอาจใช้มันเป็นเครื่องมือหา “คนที่ปลดได้”
• แกนของปฏิกิริยานี้คือ Goodhart’s Law

งานวิจัย Truck Factor เดิมและความพยายามทำซ้ำ

• งานวิจัยต้นฉบับคำนวณว่าในโปรเจ็กต์ GitHub ยอดนิยมหลายตัว ต้องมีคนหายไปกี่คนโปรเจ็กต์ถึงจะหยุดชะงัก
• ในกลุ่มตัวอย่างนั้นมี Linux kernel รวมอยู่ด้วย
• ตอนต้นบทความระบุว่า preprint แรกบอกว่า Linux ต้องมีคนออกไป 80 คนจึงจะหยุดชะงัก แต่ต่อมาสรุปว่าตัวเลขใน preprint ปี 2015 คือ 90 และใน full publication คือ 57
• ผู้เขียนกับ mclare จึงลองทำซ้ำผลลัพธ์เพื่อดูว่าหลังผ่านไปราว 10 ปี truck factor ดีขึ้นหรือไม่
• GitHub repository ของผู้เขียนต้นฉบับยังใช้งานได้อยู่

ข้อจำกัดของข้อมูลและสภาพแวดล้อมการรัน

• ข้อมูลงานวิจัยถูกให้มาในรูป JSON และภาพแสดงผลเดิมอิงกับ CSV ที่สามารถสแครปได้
• แต่ไม่สามารถรู้ได้ว่า เก็บข้อมูลเมื่อวันที่ใด
• คำแนะนำใน README ใช้งานไม่ได้ตรง ๆ จึงต้องอ้างอิง GitHub issue เพื่อแก้วิธีรัน
• มีการดึงรายชื่อ GitHub repository ทั้งหมดจากคอลัมน์แรกของ CSV ต้นฉบับแล้วโคลนทั้งหมด
• ใช้ gnu parallel เพื่อรันคำสั่ง git clone หลายชุดพร้อมกัน

จุดที่ติดขัดกับ gnu parallel, linguist และ NixOS

• แม้จะระบุ -j 8 ให้ gnu parallel แต่กลับพบว่าคอร์ทั้ง 32 คอร์ของโน้ตบุ๊กถูกใช้งาน
• จำนวนโปรเซส git clone ที่เห็นพร้อมกันมี 8 ตัว แต่มีโปรเซส git index-pack จำนวนมากที่ใช้คอร์ทั้งหมด
• สาเหตุที่เป็นไปได้คือ git index-pack เป็นโปรเซสลูกที่ถูก fork ออกมา ทำให้ parallel เริ่ม git clone ตัวใหม่ต่อได้
• โค้ด Truck Factor ใช้ linguist ของ GitHub เพื่อคัดไฟล์เอกสารออก
• ในสภาพแวดล้อม NixOS ผู้เขียนไม่มีประสบการณ์ Ruby จึงแก้การติดตั้ง Ruby Gems ไม่ทันเวลา และได้ขอวิธีติดตั้งปลั๊กอิน linguist ใน Nix flake หรือ pull request

ขั้นตอนการคำนวณใหม่จริง

• มีการ fork รีโพซิทอรีต้นฉบับและโคลนลงเครื่อง แล้วไล่ตาม README พร้อมปรับวิธีรันให้ตรง
• คอมไพล์ซอร์ส Java เป็น jar ด้วย mvn package
• ทดลองแต่ละขั้นตอนกับ GitHub repository ของ numpy ก่อน แล้วจึงคำนวณใหม่กับรีโพซิทอรีทั้งหมด
• mclare ดาวน์โหลด CSV ของภาพแสดงผลเดิม แล้วแปลงคอลัมน์แรกเป็น รายชื่อ GitHub repository
• ลำดับการทำงานเป็นดังนี้
  • โคลนรีโพซิทอรีด้วย parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt)
  • ย้ายไปยังไดเรกทอรี gittruckfactor/scripts เพื่อหลีกเลี่ยงข้อผิดพลาดของ awk
  • ใช้ commit_log_script.sh เพื่อดึงข้อมูล git commit ของแต่ละรีโพซิทอรี
  • รัน gittruckfactor-1.0.jar เพื่อประมวลผลข้อมูล commit ที่ดึงมา
• การโคลนรีโพซิทอรีทั้งหมดแบบต่อเนื่องบนอินเทอร์เน็ตกิกะบิตที่บ้านใช้เวลา 17.5 นาที
• การประมวลผลแต่ละรีโพซิทอรีก็ดูจะใช้เวลาราว 18 นาทีเช่นกัน

ผลการคำนวณ Linux kernel ใหม่

• ตัวอย่างเอาต์พุตของ Linux kernel คือ TF = 12, coverage = 49.98%
• ใน TF authors มี Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner, Krzysztof Kozlowski และคนอื่น ๆ
• Linus Torvalds ถูกแสดงว่าเกี่ยวข้องกับ 5,712 ไฟล์ หรือ 6.59%
• เมื่อไม่ใช้ปลั๊กอิน linguist และไม่กรองเอกสารกับไลบรารีจากภายนอกออก ผล truck factor ของ Linux kernel คือ 12
• หลังจาก mclare ติดตั้งปลั๊กอิน linguist บนระบบของตัวเองแล้ว ค่า truck factor ของ Linux kernel ที่ได้คือ 8

องค์ประกอบที่ยังไม่ถูกนับในการคำนวณและสิ่งที่ควรตรวจต่อ

• การคำนวณนี้ ไม่ได้สะท้อนกระบวนการรีวิว
• ยิ่งมีประสบการณ์มากขึ้น นักพัฒนามักต้องรีวิวมากกว่านั่งพิมพ์โค้ดเองโดยตรง
• สิ่งที่ควรตรวจเพิ่มมีดังนี้
  • การคำนวณ truck factor รองรับ co-authored-by และ reviewer header ของ git หรือไม่
  • ถ้ายังไม่รองรับ จะใส่ข้อมูลเหล่านี้เข้าไปในการคำนวณได้หรือไม่
  • เหตุใดค่าของ Linux หลังผ่านไป 10 ปีจึงต่างไปมาก
  • การที่ไม่ได้ใช้ Levenshtein distance 1 เพื่อรวม alias ของนักพัฒนาแบบในงานวิจัยเดิม ส่งผลต่อผลลัพธ์หรือไม่
  • หาก checkout รีโพซิทอรี Linux kernel ไปยังช่วงกลางปี 2015 โค้ดชุดเดิมจะยังได้ค่า 80 หรือไม่
  • เนื่องจากอัลกอริทึมถูกอัปเดตในปี 2016 จึงสามารถคำนวณค่าหลังจากนั้นใหม่ได้หรือไม่
• สามารถดู 156 citations ของงานวิจัยต้นฉบับเพื่อดูว่ามีวิธีคำนวณที่ดีกว่านี้หรือไม่
• โปรเจ็กต์ขนาดใหญ่ยุคใหม่อย่าง Rust ไม่ได้อยู่ในงานวิจัยปี 2015 จึงสามารถเปรียบเทียบโปรเจ็กต์ยอดนิยมปัจจุบันกับประวัติในอดีตได้
• ยังสามารถทำสคริปต์เพื่อหาค่า truck number รายปีสำหรับ git repository ใด ๆ ก็ได้

Bus Factor ที่ลดลงยิ่งกว่าเดิม

• คำถามที่ต้องการตรวจคือ truck factor ดีขึ้นตามกาลเวลาหรือไม่
• ผลลัพธ์ออกมาใกล้เคียงกับคำตอบว่า ไม่ได้ดีขึ้น และกลับแย่ลง
• Linux kernel ได้ค่าจากการรันครั้งนี้ต่ำกว่าตัวเลขในงานวิจัยเดิมมาก
• ขึ้นอยู่กับว่ากรองเอกสารและไลบรารีจากภายนอกหรือไม่ ผลของ Linux kernel ลดจาก 12 เหลือ 8
• สามารถดูภาพแสดงผลเพิ่มเติมและรายละเอียดอื่น ๆ ได้ใน บทความของ mclare

[GN⁺]

ความเห็นจาก Hacker News

• หนึ่งในฟีเจอร์ของ https://codescene.com/ ก็คือสิ่งนี้
  มันค้นหา เกาะความรู้ แล้วเชื่อมโยงกับโค้ดที่เปลี่ยนแปลงบ่อย เพื่อระบุ ฮอตสปอต ที่มีความเสี่ยง เพราะมีการเปลี่ยนแปลงมากแต่การกระจายความรู้น้อย
  ถ้ามีใครแจ้งความตั้งใจจะลาออก ก็จะเห็นโค้ดที่มีแค่คนนั้นรู้ได้ง่าย จึงวางแผนส่งมอบงานได้ง่ายขึ้นด้วย
  ไม่เคยคิดว่ามันอาจถูกนำไปใช้ในทางที่ผิด และเดิมทีมันเป็นเครื่องมือเพื่อการมองเห็นภาพรวม ผู้จัดการที่ใช้มันแบบนั้นคือผู้จัดการที่แย่ และถ้าเขาเป็นคนแบบนั้นอยู่แล้ว เครื่องมือนี้ก็ไม่ได้จะเปลี่ยนอะไร

  • อย่ามองคำว่า “ใช้ในทางที่ผิด” อย่างไร้เดียงสาเกินไป สมมติว่าคุณสังกัดหน่วยข่าวกรองของประเทศหนึ่ง สมมติว่าประเทศ Tussia ถูกกันไม่ให้เข้าถึงเคอร์เนลหลัก Kinux ที่ใช้ในยุทโธปกรณ์ทางทหารทั่วโลก แล้วคุณรู้ว่าคนในออฟฟิศข้าง ๆ เริ่มโปรเจกต์ fork เคอร์เนลนั้นสำหรับใช้ภายในประเทศของตน
    ถ้าคุณอยากได้เลื่อนตำแหน่ง ก็อาจขอ “เจ้าหน้าที่หญิง 8 คนที่ผ่านการฝึกพิเศษด้านการตีสนิทกับเนิร์ด” จากฝ่ายจัดหา และขอ polonium สำรองไว้ 8 โดส เผื่อกรณีล้มเหลว
    อาจฟังดูเหมือนเรื่องแต่งล้วน ๆ แต่ผมรู้จัก CEO ของสตาร์ทอัพยูนิคอร์นรายหนึ่งที่กำลังหา seed investment ซึ่งเคยเจอเรื่องที่ตรงกับส่วนต้น ๆ นี้จริง ๆ
  • ผมเคยอยู่ที่ทำงานที่นำ Pluralsight Flow มาใช้สามแห่ง และในสองแห่งนั้น ผู้จัดการเริ่มเอาเมตริกไปใช้กับ feedback, performance review และการตัดสินใจจ้างงานทันที
    ที่ทำงานแห่งที่สาม นักพัฒนามองเกมนี้ออกแต่ไกล จึงปฏิเสธทั้งการใช้เครื่องมือและการประเมินแบบนั้นเอง
    เครื่องมือพวกนี้ราคาแพงเกินเหตุ ดังนั้นฝ่ายที่อนุมัติก็ต้องพยายามดึง ROI ออกมาให้ได้ ไม่มีวิธีวัด productivity, output หรือ knowledge silo ได้อย่างถูกต้อง สุดท้ายจึงไหลไปเป็นแนว “สัปดาห์นี้ PR ของ Jose น้อยนะ” อะไรแบบนั้น
  • การใช้งานเพื่อ visibility เองนั้นยอดเยี่ยม แต่เฉพาะเมื่อมันอยู่ในขอบเขตนั้นได้เท่านั้น
    ปัญหาคือนักพัฒนาเองก็เห็นมันได้ และอาจพยายามย้ายไปยังโปรเจกต์หรือคอมโพเนนต์เป้าหมายเพื่อให้ตัวเองไปอยู่ใน รายชื่อพนักงานที่ไล่ออกไม่ได้ ตามอุดมคติแล้ว คนทำงานอาจร่วมกันเคลื่อนไหวจนทำให้ truck factor เป็น 0 เพื่อให้ไล่ใครออกได้ยาก
    แน่นอนว่าถ้าเป็นแบบนี้ก็แทบจะเป็นการเสียเวลาโดยสมบูรณ์ และพิสูจน์ประเด็นเดิมที่เพื่อนร่วมงานของบล็อกเกอร์พูดไว้ว่า “มันจะติด Goodhart’s Law ทันที”
  • บริษัทที่ปรึกษาภายนอกก็อาจใช้สิ่งนี้เพื่อช่วยบริษัททำ layoff ได้ ต่อให้ผู้จัดการจะยอดเยี่ยมแค่ไหนก็เป็นไปได้

• ที่ Amazon มีตัวเลขแบบนี้ให้ดูได้ง่าย ๆ จากระบบโค้ดในรูปแบบรายงานที่ผู้จัดการคนไหนก็รันได้ และยังมีวิธีอื่นอีกมากในการดูว่าทีมกำลังทำอะไรและมีความเสี่ยงอะไรบ้าง โดยส่วนตัวคิดว่ามีประโยชน์
  bus factor เป็นแค่มุมมองหนึ่ง และจากอีกมุมหนึ่ง มันช่วยให้ค้นหาและแก้ไข silo, วิศวกรที่ไม่ร่วมงานกับคนอื่น, และพื้นที่ที่ย้ายวิศวกรออกได้ยาก
  นักพัฒนาบางคนกลัวการถูกแทนที่ จึงคิดว่าระบบที่มีแต่ตัวเองรู้คือความมั่นคงในการจ้างงาน แต่ในทางกลับกัน นั่นคือความเสี่ยงทางเทคนิค และอาจเป็นปัจจัยที่ขัดขวางไม่ให้วิศวกรเก่ง ๆ ไปทำโปรเจกต์ที่สำคัญกว่าได้ นอกจากนี้ยังเป็นทางให้ไปทำอย่างอื่นได้เมื่อเบื่อระบบที่ไม่ชอบแล้ว

  • ผมไม่ได้กลัวการถูกแทนที่ ถ้าสถานที่ไหนไม่ต้องการผม ผมก็ไม่อยากอยู่ที่นั่นเหมือนกัน
    แต่แนวคิดเรื่อง การถูกแทนที่ได้ สร้าง overhead ขนาดใหญ่ และทำให้ใช้คนเก่งได้ไม่เต็มศักยภาพ เพราะพวกเขาแทนกันไม่ได้จริง ๆ
    ในบางที่มันจำเป็น แต่ในบางที่ process overhead กลายเป็นความเสี่ยงต่อความสำเร็จของโปรเจกต์มากกว่า bus factor มาก
  • ผมรู้จักนักพัฒนาคนหนึ่งที่ถูกปฏิเสธ การย้ายทีมและการเลื่อนตำแหน่ง ด้วยเหตุผลว่าไม่สามารถหาคนมาแทนได้ง่าย
    ตอนจบคือเขาลาออกภายใน 3 เดือน
  • “ถ้าคุณถูกแทนที่ไม่ได้ คุณก็เลื่อนตำแหน่งไม่ได้”
  • จากมุมมองของพนักงานที่ไม่ได้มีเป้าหมายหลักคือการเพิ่มกำไรของบริษัทให้สูงสุด ความคิดว่าระบบที่มีแต่ตัวเองรู้คือความมั่นคงในการจ้างงาน ก็เป็นกลยุทธ์ที่สมจริงเหมือนกัน
  • ตลอดอาชีพ ผมพยายามทำให้ตัวเองและนักพัฒนาคนอื่น ๆ ถูกแทนที่ได้ มากที่สุด ส่วนหนึ่งเพราะงานด้านดิจิทัลจำนวนมากเดิมทีก็เป็นงานแบบนั้นอยู่แล้ว และอีกส่วนเพราะการต้องรับมือกับ knowledge silo มันน่าหงุดหงิด
    เหตุผลหนึ่งที่ผมใช้ TypeScript ใน backend มาก ก็เพราะภาษาที่ทีมเล็ก ๆ ต้องรู้ลดเหลือภาษาเดียว ดังนั้นเวลานักพัฒนา frontend ไปพักร้อน เขาก็สามารถตัดขาดจากงานได้จริง และมีคนอื่น cover แทนได้ ถ้ามีใครย้ายงาน ความเจ็บปวดก็น้อยลง
    มันไม่เคยเป็นปัญหาเลย และผมมองว่าการถูกแทนที่ได้เป็นส่วนหนึ่งของระบบที่ดีต่อสุขภาพ หลังจากอยู่ฝั่ง management มาหลายปี สิ่งแรก ๆ ที่ได้เรียนรู้คือ “ทุกคนถูกแทนที่ได้ และมันเป็นแค่เรื่องต้นทุน” ดังนั้นถ้าระดับความรู้สูงเกินไป กลับอาจส่งผลเสีย เพราะฝ่ายบริหารจะพยายามลดความเสี่ยงนั้น โดยเฉพาะ layoff ที่เกิดจากเหตุผลทางเศรษฐกิจนั้นค่อนข้างสุ่มด้วย
    ถึงอย่างนั้น ผมก็ไม่อยากทำงานในที่ที่ใช้เมตริกน่าขันแบบนี้ ยิ่งมี red tape มากแค่ไหนในการทำงานดี ๆ โอกาสที่ผมจะอยากร่วมงานด้วยก็ยิ่งน้อยลง ของแบบนี้ทำให้คน เล่นเกมกับเมตริก มากกว่าทำงานดี ๆ ได้ง่าย และสร้างวัฒนธรรมที่ไม่ดีต่อ productivity และคุณภาพ

• gnu parallel กำลังรันงาน git clone พร้อมกัน 8 งานตามที่ร้องขอ และ git clone แต่ละตัวก็กำลังเริ่มเธรด index-pack จำนวนมากตามใจตัวเอง
  ในกรณีนี้ การตั้งค่า pack.threads ชั่วคราวเป็น 1 ด้วย git config จะช่วยได้

  • นี่เป็นปัญหาที่พบได้บ่อยขึ้นเรื่อย ๆ ทั้งสองชั้นต่างพยายามทำ parallelization ตามจำนวน CPU หรือคอร์เพื่อใช้เครื่องทั้งเครื่อง แล้วในชั้นด้านในก็เกิด เธรด/โปรเซสจำนวน N²
    เพราะมันเพิ่มแบบยกกำลังสอง ยิ่งมี CPU มากปัญหายิ่งหนักขึ้น ถ้าเป็น 32 คอร์ก็ 32² = 1024 และในความเป็นจริงตรงนี้กำหนดให้ Parallel เป็น 8 งาน จึงน่าจะหยุดอยู่แถว ๆ โปรเซส index-pack สูงสุดประมาณ 256 ตัว ถึงอย่างนั้นก็ต้องใช้หน่วยความจำมากเพื่อรับมือกับมัน และจริง ๆ แล้วไม่ได้ประโยชน์อะไรเลย
    วิธีแก้คือทำ parallelization แค่ชั้นใดชั้นหนึ่งเท่านั้น
    คำอธิบายใน man git-config เกี่ยวกับ pack.threads ระบุไว้แบบนี้: กำหนดจำนวนเธรดที่จะสร้างเมื่อค้นหาการจับคู่เดลตาที่เหมาะที่สุด และ git-pack-objects(1) ต้องถูกคอมไพล์มากับ pthreads ไม่เช่นนั้นจะถูกเพิกเฉยพร้อมคำเตือน ตัวเลือกนี้มีไว้เพื่อลดเวลาการแพ็กบนเครื่องที่มีหลายโปรเซสเซอร์ แต่หน่วยความจำที่ต้องใช้สำหรับหน้าต่างค้นหาเดลตาจะถูกคูณตามจำนวนเธรด หากกำหนดเป็น 0 Git จะตรวจจับจำนวน CPU อัตโนมัติแล้วตั้งจำนวนเธรดให้สอดคล้องกัน
  • แทนที่จะตั้งค่าชั่วคราวด้วย git config ก็ใช้ git -c pack.threads=1 clone ได้เลย: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

• การตีความแบบนี้ไม่ค่อยดีนัก ผมมองว่าบทความนี้เป็นบทความสำหรับผู้นำด้านวิศวกรรมทุกคน
  bus factor หมายถึงทีมจะเจ็บปวดแค่ไหนเมื่อมีใครสักคนในทีม หรือแม้แต่ตัวคุณเอง ถูกรถบัสชน
  bus factor ในอุดมคติสำหรับสมาชิกทุกคนในทีมคือ 0 ตอนแรกอาจฟังเหมือน “ทำให้ทุกคนเป็นของใช้แล้วทิ้ง” แต่จริง ๆ แล้วเกือบจะตรงกันข้าม และนั่นคือประเด็นสำคัญ
  ทีมควรดีพอที่จะ a) ทำงานได้ด้วยตัวเอง และ b) ไม่มีอะไรเป็นปริศนา ในสภาพอุดมคติ ทุกคนเข้าใจว่าทุกอย่างทำงานอย่างไร พนักงานใหม่ควรเริ่มสร้างคุณค่าได้ทันที และคนที่ออกไปก็ควรสบายใจได้ว่าไม่มีพื้นที่ลึกลับที่ถูกทิ้งไว้
  ทีมในอุดมคติที่ทุกคนมี BF เป็น 0 เป็นสิ่งที่พึงประสงค์ หมายความว่าสมาชิกทีมสามารถทดแทนกันได้ และถ้ามีใครป่วย ลาพักร้อน ออกไปจริง ๆ หรือถูกเอาออก สมาชิกทุกคนก็สามารถเติมเต็มช่องว่างนั้นได้
  สิ่งที่สำคัญกว่านั้นคือ BF 0 เป็นภาพสะท้อนของ ความเรียบง่าย ซอฟต์แวร์, pipeline สำหรับ build·test·deploy, เอกสาร และระบบ support ทั้งหมดควรมีความสอดประสานและสม่ำเสมอ การกักข้อมูลไว้ใน silo ภายในตัวสมาชิกทีมเป็นสิ่งไม่ดี และทุกคนควร build และ deploy ได้
  BF 0 เป็นตัวชี้วัดที่ดีต่อสุขภาพ แต่ไม่มีทางวัดได้จากจำนวนอีเมล จำนวน commit จำนวน PR จำนวนบรรทัดโค้ด ความเร็วในการตอบกลับ หรือ heatmap ของ GitHub ตัวชี้วัดพวกนั้นไม่ได้แสดงอะไรเลย แถมยังเป็นตัวชี้วัดที่เป็นอันตรายและเลวร้าย
  การประเมินคนด้วยตัวชี้วัดแบบนี้ก็ไม่ต่างจากลิงหน้าเครื่องพิมพ์ดีด สตาร์ทอัพควรได้ยินเรื่องนี้กันมากกว่านี้

  • ผมได้ยิน bus factor ในความหมายตรงกันข้ามมาตลอด คือ “ต้องมีคนกี่คนถูกรถบัสชน โปรเจกต์ถึงจะเดินต่อไม่ได้” และเข้าใจว่าค่าที่เหมาะสมคือเท่ากับจำนวนสมาชิกทีม
    ดูเหมือนจะพูดถึงแนวคิดเดียวกัน แต่ก็น่าประหลาดใจที่ตัวเลขนั้นไม่ได้ถูกใช้ไปในทิศทางเดียวกันเสมอ
  • ผมเคยทำงานในโปรเจกต์ที่มีคนซึ่งมีทักษะเฉพาะนั้นอยู่เพียงหยิบมือทั่วโลก ณ ตอนนั้น bus factor เป็น 1 อย่างแน่นอน
    ในโปรเจกต์ที่ผลักขอบเขตของความเป็นไปได้ บางครั้ง ความเรียบง่าย ก็ไม่ใช่ตัวเลือก แน่นอนว่าเป็นสัดส่วนเล็ก ๆ ของโปรเจกต์ซอฟต์แวร์ทั้งหมด แต่เมื่อทำสิ่งที่ไม่เคยมีมาก่อน ความกังวลที่ใหญ่กว่าการรักษาโค้ดให้เรียบง่ายที่สุดเท่าที่ทำได้คือ “แล้วจะทำสิ่งนี้ให้สำเร็จได้อย่างไร”
    ไม่ได้หมายความว่าคุณภาพโค้ดต่ำได้ เพียงแต่เมื่อทำเรื่องยาก บางครั้งก็ต้องใช้โค้ดที่ซับซ้อน และหลังจากผ่านไปหลายรุ่น รูปแบบการออกแบบจึงค่อยถูกจัดระเบียบจนทำให้เรื่องยากนั้นทำได้ด้วยโค้ดที่ซับซ้อนน้อยลง ซึ่งอาจเป็นอีก 10 ปีให้หลังก็ได้
  • ถ้าตั้งแต่วันแรกใคร ๆ ก็เข้าใจโค้ดได้ และทำแต่สิ่งที่ไม่ต้องใช้ความรู้ด้านโดเมน แล้ว value proposition ของผลิตภัณฑ์หรือทีมคืออะไร?
    ถ้าสิ่งที่ซับซ้อนที่สุดที่ทำได้มีแค่แอป todo ผมคิดว่ามันสร้างคุณค่าให้สังคมได้ไม่มากนัก
  • คนที่ทำงานเก่งและมั่นใจในตัวเองจะพยายามลด bus factor ของตัวเองอย่างจริงจัง
    การที่ bus factor สูงหมายความว่านายจ้างรั้งคุณไว้เพราะสิ่งที่คุณทำไว้ในอดีต มากกว่าศักยภาพในอนาคตของคุณ
  • กองทัพคิดแบบนั้น ถือเป็นสมมติฐานว่าต่อให้เสียคนไปก็ต้องเดินหน้าต่อได้

• ประเด็นหลักของบทความวิจัยต้นฉบับอยู่ตรงนี้
  “การประมาณของเราพึ่งพาสมมติฐานเรื่อง coverage หากกลุ่มผู้เขียนปัจจุบันครอบคลุมน้อยกว่า 50% ของชุดไฟล์ปัจจุบันของระบบ ระบบมีแนวโน้มสูงที่จะเกิดความล่าช้ารุนแรงหรือหยุดชะงัก”
  ในที่นี้ ผู้เขียนของไฟล์ถูกนิยามว่าเป็นผู้ใช้ที่มีส่วนร่วมอย่างมีนัยสำคัญต่อไฟล์นั้น ตามเกณฑ์น้ำหนักที่คำนวณไว้ล่วงหน้า

• ด้านหนึ่ง ถ้า dashboard metrics แบบนี้ยังไม่ได้อยู่ในซอฟต์แวร์ระดับองค์กรสักตัว ผมคงจะแปลกใจเสียมากกว่า ผู้บริหารในบริษัทเก่าของผมเคยถามจริง ๆ ว่าสามารถทำ รายงานประจำวัน ได้ไหมว่าใครในแผนกส่งและรับอีเมลมากที่สุด
  ผมปฏิเสธเพราะไม่ชอบทิศทางที่มันจะไหลไป แต่เพื่อนร่วมงานอีกคนทำมันขึ้นมา ตามคาด คนที่รับและส่งอีเมลมากที่สุดคือผู้ดูแลระบบ เพราะบัญชีของเขาถูกตั้งเป็นผู้ส่งอีเมลอัตโนมัติของเซิร์ฟเวอร์หลายเครื่อง เขาส่งอีเมลแจ้งเตือนวันละหลายร้อยฉบับถึงตัวเอง และยังมี newsletter กับอีเมลสรุปที่สมัครไว้เพิ่มเข้าไปอีก
  อีกด้านหนึ่ง ถ้าเพื่อนร่วมงานทุกคนขอว่าอย่าทำสิ่งที่อาจกระทบงานของพวกเขา แต่ยังดันทุรังทำเป็นโปรเจกต์งานอดิเรก ก็ฟังดูเป็นพฤติกรรมที่ค่อนข้างใจร้าย

  • ตอนที่เพื่อนร่วมงานบอกว่าอย่าทำในปี 2015 ผมก็ไม่ได้ทำ
    เพียงแต่ผมอยากดูว่าโอเพนซอร์สซอฟต์แวร์ที่ผมใช้กระจายความรู้ได้ดีพอจะเพิ่มโอกาสอยู่รอดหรือไม่
    พฤติกรรมใจร้ายนั้นผมปฏิเสธไปแล้ว
  • เป็นตัวชี้วัดที่เหลวไหลมาก

• ผมคิดว่าความเข้าใจผิดที่พบบ่อยในบริษัทเทคโนโลยีคือ “ยิ่งไต่ career ladder ขึ้นไป นักพัฒนาควรแตะคีย์บอร์ดน้อยลงและทำ review มากขึ้น”
  เราไม่ได้อยากเปลี่ยนนักพัฒนาที่ยอดเยี่ยมให้กลายเป็นผู้จัดการธรรมดา

  • ใช่ มี tech lead ที่เขียนโค้ดเก่งมาก แต่ทักษะอย่าง leadership หรือ feedback กลับแย่มาก
    เขาน่าจะเหมาะกับการเป็น senior developer มากกว่า tech lead มาก ลองจินตนาการไม่ออกเลยว่าถ้าเขาเป็นผู้จัดการ ทีมจะทุกข์ทรมานแค่ไหน
  • ถ้าคิดว่า code review คือ “การจัดการ” ก็น่าเป็นห่วงค่อนข้างหนัก

• ไอโรนีที่น่าเศร้าของเรื่องนี้คือ คำถามก็ยังผิดอยู่ดี
  เวลาสตาร์ทอัพจำเป็นต้องเลย์ออฟ คำถามไม่ใช่ “จะปลดใครออกไปแล้วธุรกิจเดิมยังเดินต่อได้” แต่คือ “ทีมไหนที่จะสร้างผลิตภัณฑ์เวอร์ชันถัดไปได้เร็วพอจนบริษัทไม่เจ๊ง”
  ทุกทางแยกสุดท้ายก็ยังเป็นทางแยก และมีบริษัทจำนวนมากที่ตายไปเพราะเลือกทางไม่เร็วพอ

• CPAN ติดตาม bus factor มานานแล้ว ตัวอย่างเช่น https://metacpan.org/pod/Moose แสดง Bus Factor 5 ในคอลัมน์ข้อมูลด้านซ้าย

  • ยังมีเอกสารอธิบายด้วยว่าคำนวณตัวเลขนั้นอย่างไร: https://www.olafalders.com/2021/06/30/cpan-bus-factor/

• เราชอบเรียกสิ่งนี้ว่า lottery factor
  หมายถึงว่า หากมีใครถูกลอตเตอรี่แล้วหนีไปอยู่เกาะเขตร้อนที่ไม่มีทั้งไฟฟ้าและเครือข่ายสื่อสาร โปรเจกต์ยังไปต่อได้ไหม
  เรียกแบบนี้แล้วฟังดูน่าขนลุกน้อยกว่า

  • คนที่ถูกลอตเตอรี่จะยื่นใบลาออกล่วงหน้า 2 สัปดาห์ และถ้าจำเป็นจริง ๆ ก็อาจโทรหาได้ภายหลัง
    คนที่ถูกรถบัสชนจะหายไปทันที มันไม่ใช่เรื่องเดียวกัน
  • พนักงานที่ดีจะพยายามส่งมอบโปรเจกต์ของตัวเองและคอยตอบคำถาม แต่เราก็ต้องเตรียมรับมือกรณีที่ทำแบบนั้นไม่ได้ด้วย
  • การใช้คำอ้อม ๆ ว่าการย้ายงานคือ sudden death ให้ความรู้สึกค้างคาไม่ดี
    บางคนไม่ชอบอุปมาอุปไมยจากกีฬา แต่ผมมองว่าอย่างน้อยก็ดีกว่าอุปมาอุปไมยทางทหาร
    อีกอย่าง โดยปกติก็มักมีหลายกรณีที่ไม่มีการส่งมอบงานอยู่แล้ว ดังนั้นความฉับพลันเองอาจไม่ใช่ปัจจัยสำคัญขนาดนั้น
  • การถูกรถบัสชนอาจเป็นเรื่องที่เกิดขึ้นได้ง่ายกว่า จึงควรสะท้อนความเป็นไปได้นั้นด้วย
  • ผมไม่รู้จักใครที่ถูกลอตเตอรี่รางวัลใหญ่หรือถูกรถบัสชน แต่รู้จักหลายคนที่ลาออกไปหลังจากกลายเป็น เศรษฐีคริปโต