Bus Number – plugin GitHub mà đồng nghiệp bảo đừng viết
(scannedinavian.com)- Một nhà phát triển, sau trải nghiệm người đóng góp duy nhất cho đoạn mã tạo doanh thu biến mất vì đợt sa thải, đã muốn tạo một plugin truck factor trên GitHub Enterprise để tìm ra những người không được phép mất đi
- Đồng nghiệp lo ngại chỉ số này sẽ sớm vướng vào Goodhart’s Law, và trở thành công cụ quản lý để tìm ra “những người có thể sa thải” thay vì những người cần được bảo vệ
- Kho lưu trữ và dữ liệu Truck-Factor gốc vẫn còn dùng được, nhưng ngày thu thập dữ liệu không rõ ràng và quy trình trong README cũng không còn tái lập nguyên trạng, nên cần hiệu chỉnh thủ công
- Việc tính lại được thực hiện bằng cách clone nhiều kho GitHub với
gnu parallelrồi chạy mã Java; với Linux kernel, kết quả là truck factor 12 khi không dùng bộ lọc linguist, và 8 khi có áp dụng bộ lọc - Kết quả này còn thấp hơn các con số trong bài báo gốc là preprint năm 2015 là 90 và publication chính thức là 57, nên khó có thể nói bus factor của Linux kernel đã được cải thiện
Bus Factor và ý tưởng plugin đầy rủi ro
- Bus Factor hoặc Truck Factor là số lượng thành viên tối thiểu phải đột ngột biến mất trước khi một dự án bị đình trệ do thiếu người nắm kiến thức
- Điểm khởi đầu là trong một đợt sa thải ở công ty vào khoảng năm 2015, người đóng góp duy nhất cho một phần codebase kiếm ra tiền cho công ty đã bị cho nghỉ việc
- Sau khi nghĩ tới Truck Number, ý tưởng xuất hiện là tạo một plugin GitHub Enterprise để tính ra “những người không được sa thải”
- Khi tác giả giới thiệu plugin này trong 5 phút ở một buổi lightning talk chiều thứ Năm, đồng nghiệp cho rằng quản lý có thể dùng nó như công cụ để tìm ra “những người có thể sa thải”
- Trọng tâm của phản ứng này chính là Goodhart’s Law
Nghiên cứu Truck Factor trước đây và nỗ lực tái hiện
- Nghiên cứu gốc tính xem với nhiều dự án GitHub phổ biến, cần bao nhiêu người biến mất thì dự án mới đình trệ
- Linux kernel cũng nằm trong số đó
- Ở đầu bài viết có nói bản preprint đầu tiên cho rằng Linux sẽ dừng lại nếu 80 người rời đi, còn phía sau bài thì tổng kết con số trong preprint năm 2015 là 90 và trong full publication là 57
- Cùng với mclare, tác giả thử tái hiện kết quả để kiểm tra xem khoảng 10 năm sau truck factor có được cải thiện không
- Kho GitHub của các tác giả gốc vẫn còn sử dụng được
Hạn chế của dữ liệu và môi trường chạy
- Dữ liệu bài báo được cung cấp ở dạng JSON, còn phần trực quan hóa gốc dựa trên CSV có thể scrape được
- Tuy vậy, ngày thu thập dữ liệu thì không xác định được
- Hướng dẫn trong README không còn chạy nguyên vẹn, nên phải tham khảo GitHub issue để chỉnh lại cách thực thi
- Từ cột đầu tiên của CSV gốc, tác giả trích ra danh sách kho GitHub rồi clone toàn bộ kho
- Dùng
gnu parallelđể chạy đồng thời nhiều lệnhgit clone
gnu parallel, linguist, và chỗ mắc kẹt trên NixOS
- Dù đã chỉ định
-j 8chognu parallel, hiện tượng là toàn bộ 32 lõi của laptop vẫn bị sử dụng - Số tiến trình
git clonenhìn thấy cùng lúc là 8, nhưng có rất nhiều tiến trìnhgit index-packdùng hết các lõi - Một giả thuyết là
git index-packlà tiến trình con được fork ra, khiếnparalleltiếp tục khởi chạy thêm cácgit clonekhác - Mã Truck Factor dùng linguist của GitHub để loại trừ các tệp tài liệu
- Trong môi trường NixOS, do không có kinh nghiệm Ruby nên tác giả không giải quyết được việc cài Ruby Gems trong khung thời gian có sẵn, và mong được chỉ cách cài plugin linguist trong Nix flake hoặc gửi pull request
Quy trình tính lại thực tế
- Tác giả fork kho gốc, clone về máy cục bộ rồi điều chỉnh cách chạy theo README
- Dùng
mvn packageđể biên dịch mã Java thành file jar - Trước tiên thử từng bước với kho GitHub của numpy, sau đó mới tiến hành tính lại toàn bộ các kho
- mclare tải CSV của phần trực quan hóa gốc xuống và chuyển cột đầu tiên thành danh sách kho GitHub
- Luồng thực thi như sau
- Clone kho bằng
parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt) - Chuyển vào thư mục
gittruckfactor/scriptsđể tránh lỗi awk - Trích xuất thông tin git commit của từng kho bằng
commit_log_script.sh - Chạy
gittruckfactor-1.0.jarđể xử lý dữ liệu commit đã trích xuất
- Clone kho bằng
- Với đường truyền internet gigabit nhanh ở nhà, việc clone toàn bộ kho theo tuần tự mất 17,5 phút
- Việc xử lý từng kho dường như cũng mất khoảng 18 phút
Kết quả tính lại Linux kernel
- Kết quả ví dụ cho Linux kernel là TF = 12, coverage = 49.98%
- Các TF authors gồm Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner, Krzysztof Kozlowski và những người khác
- Linus Torvalds được hiển thị với 5.712 tệp, tương ứng 6,59%
- Khi không dùng plugin linguist để lọc tài liệu và thư viện bên thứ ba, truck factor của Linux kernel là 12
- Sau khi mclare cài plugin linguist trên hệ thống của mình, truck factor Linux kernel thu được là 8
Những yếu tố còn thiếu trong phép tính và các điểm cần kiểm tra tiếp
- Phép tính này không phản ánh quy trình review
- Khi thâm niên tăng lên, nhà phát triển thường phải review nhiều hơn là trực tiếp gõ mã bằng bàn phím
- Các mục cần kiểm tra thêm gồm
- Liệu phép tính truck factor có phản ánh
co-authored-byvà header reviewer của git hay không - Nếu không phản ánh, có thể đưa chúng vào phép tính hay không
- Vì sao con số của Linux lại thay đổi lớn sau 10 năm
- Việc không áp dụng Levenshtein distance 1 để gộp alias nhà phát triển như bài báo gốc có ảnh hưởng tới kết quả hay không
- Nếu checkout kho Linux kernel về thời điểm giữa năm 2015 thì cùng đoạn mã đó có còn cho ra 80 hay không
- Vì thuật toán đã được cập nhật vào năm 2016, có thể tính lại các con số sau đó hay không
- Liệu phép tính truck factor có phản ánh
- Có thể xem qua 156 citation của bài báo gốc để tìm phương pháp tính tốt hơn
- Các dự án lớn mới hơn như Rust không có trong bài báo năm 2015, nên có thể so sánh các dự án phổ biến ngày nay với lịch sử trước đó
- Cũng có thể tạo script để tìm truck number theo từng năm cho một kho git bất kỳ
Bus Factor còn thấp hơn
- Câu hỏi muốn kiểm chứng là liệu truck factor có tốt lên theo thời gian hay không
- Kết quả nghiêng nhiều về phía không tốt lên mà còn tệ hơn
- Linux kernel cho ra kết quả thấp hơn đáng kể so với con số trong bài báo gốc
- Tùy việc có lọc tài liệu và thư viện bên thứ ba hay không, kết quả Linux kernel còn giảm từ 12 xuống 8
- Có thể xem thêm trực quan hóa và chi tiết tại bài viết của mclare
1 bình luận
Ý kiến trên Hacker News
Một trong các tính năng của https://codescene.com/ chính là cái này
Nó tìm các đảo tri thức và liên kết chúng với những đoạn mã thường xuyên thay đổi, qua đó nhận diện các điểm nóng nguy hiểm: thay đổi nhiều nhưng mức độ phân tán tri thức thấp
Khi ai đó thông báo ý định nghỉ việc, có thể dễ dàng xem phần mã chỉ người đó biết, nên cũng dễ lập kế hoạch bàn giao
Tôi chưa từng nghĩ nó có thể bị lạm dụng; về bản chất đây là công cụ để tăng khả năng quan sát. Người quản lý dùng theo kiểu đó là quản lý tệ, và nếu họ đã là kiểu người như vậy thì công cụ này cũng không thay đổi được điều đó
Nếu muốn thăng tiến, bạn có thể yêu cầu bộ phận phụ trách tuyển mộ cung cấp “8 nữ đặc vụ được huấn luyện đặc biệt để trở nên thân thiết với dân nerd”, đồng thời xin dự phòng 8 liều polonium phòng trường hợp thất bại
Nghe có vẻ hoàn toàn hư cấu, nhưng tôi biết một CEO startup kỳ lân đang tìm seed funding đã thực sự trải qua phần đầu của câu chuyện này
Ở nơi thứ ba, các lập trình viên nhận ra xu hướng này từ xa và từ chối sử dụng công cụ hoặc cả việc đánh giá
Những công cụ kiểu này có giá phi lý, nên bên phê duyệt kiểu gì cũng phải vắt ra ROI. Vì không có cách đo đúng năng suất, đầu ra hay silo tri thức, cuối cùng mọi thứ trôi về kiểu “tuần này PR của Jose ít nhỉ”
Vấn đề là các lập trình viên cũng có thể nhìn vào đó rồi tìm cách chuyển sang các dự án hoặc component mục tiêu để lọt vào danh sách nhân viên không thể sa thải. Lý tưởng hơn nữa, người lao động có thể cùng nhau di chuyển để biến truck factor thành 0, khiến khó sa thải bất kỳ ai
Tất nhiên, nếu vậy thì gần như hoàn toàn lãng phí thời gian, và chứng minh đúng điểm ban đầu mà đồng nghiệp của blogger đã nói: “nó sẽ lập tức vướng vào Goodhart’s Law”
Ở Amazon, những con số kiểu này có thể dễ dàng được bất kỳ quản lý nào chạy dưới dạng báo cáo từ hệ thống mã, và còn có nhiều cách khác để xem nhóm đang làm gì cũng như có rủi ro nào. Cá nhân tôi thấy nó hữu ích
Bus factor chỉ là một góc nhìn; ở góc nhìn khác, nó giúp tìm và sửa các silo, các kỹ sư không cộng tác với người khác, và những mảng khó điều chuyển kỹ sư
Một số lập trình viên sợ bị thay thế nên nghĩ rằng hệ thống chỉ mình họ biết là bảo đảm việc làm, nhưng ngược lại, đó là rủi ro kỹ thuật và cũng có thể là yếu tố ngăn một kỹ sư giỏi chuyển sang dự án quan trọng hơn. Nó cũng là con đường để bạn làm việc khác khi đã chán ngấy một hệ thống mình ghét
Tuy nhiên, ý tưởng về khả năng thay thế tạo ra overhead lớn và khiến những người tài năng không được sử dụng ở mức năng lực tối đa. Vì trên thực tế họ không thể thay thế được
Ở một số nơi thì điều này cần thiết, nhưng ở những nơi khác, overhead quy trình lại là rủi ro lớn hơn nhiều đối với thành công của dự án so với bus factor
Kết cục là người đó nghỉ việc trong vòng 3 tháng
Một trong những lý do tôi dùng nhiều TypeScript cả ở backend là vì nó giảm số ngôn ngữ mà một nhóm nhỏ cần biết xuống còn một. Nhờ vậy khi lập trình viên frontend đi nghỉ, họ thực sự có thể ngắt kết nối, và người khác có thể cover. Khi ai đó chuyển việc thì cũng đỡ đau hơn
Điều đó chưa bao giờ trở thành vấn đề, và tôi xem khả năng thay thế là một phần của hệ thống lành mạnh. Sau vài năm ở phía quản lý, điều đầu tiên tôi học được là “mọi người đều có thể thay thế, chỉ là vấn đề chi phí”. Vì vậy nếu mức độ tri thức quá cao, đôi khi nó còn bất lợi, vì ban lãnh đạo sẽ muốn giảm rủi ro đó. Đặc biệt, các đợt cắt giảm nhân sự vì lý do kinh tế cũng khá ngẫu nhiên
Dù vậy, tôi không muốn làm ở nơi dùng các chỉ số lố bịch như thế này. Càng đặt nhiều giấy tờ, thủ tục rườm rà quanh việc làm tốt, khả năng tôi muốn làm việc cùng càng thấp. Những thứ này dễ khiến mọi người chơi trò với chỉ số thay vì làm tốt công việc, tạo ra văn hóa không tốt cho năng suất và chất lượng
gnu parallelđang chạy đồng thời 8 tác vụgit cloneđúng như được yêu cầu, và mỗigit clonelại tự ý khởi động rất nhiều luồngindex-packỞ đây, tạm thời đặt
pack.threadsthành 1 bằnggit configsẽ hữu íchVì tăng theo bình phương nên càng nhiều CPU thì vấn đề càng nghiêm trọng. Với 32 lõi thì 32² = 1024, và trên thực tế vì đã chỉ định 8 trong Parallel nên có lẽ nó đã dừng ở mức tối đa khoảng 256 tiến trình
index-pack. Dù vậy vẫn cần rất nhiều bộ nhớ để gánh, mà thực tế chẳng được lợi gìCách giải quyết là chỉ song song hóa một trong hai tầng
Về
pack.threads,man git-configmô tả như sau: chỉ định số luồng sẽ tạo khi tìm delta match tối ưu, vàgit-pack-objects(1)phải được biên dịch với pthreads. Nếu không, tùy chọn sẽ bị bỏ qua kèm cảnh báo. Đây là tùy chọn nhằm giảm thời gian đóng gói trên máy đa bộ xử lý, nhưng bộ nhớ cần cho cửa sổ tìm kiếm delta sẽ bị nhân lên theo số luồng. Nếu chỉ định 0, Git sẽ tự phát hiện số CPU và đặt số luồng tương ứnggit config, chỉ cần dùnggit -c pack.threads=1 clonelà được: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...Cách diễn giải này không hay lắm. Tôi cho rằng bài này dành cho mọi lãnh đạo kỹ thuật
Bus factor nghĩa là đội sẽ đau đớn đến mức nào nếu một người trong đội, hoặc chính bạn, bị xe buýt đâm
Bus factor lý tưởng cho mọi thành viên trong đội là 0. Ban đầu nghe có vẻ như “hãy biến mọi người thành đồ dùng một lần”, nhưng thực ra gần như ngược lại, và đó mới là điểm chính
Đội phải đủ tốt để a) tự chủ và b) không có điều bí ẩn nào. Ở trạng thái lý tưởng, mọi người đều hiểu mọi thứ vận hành ra sao. Nhân viên mới phải có thể bắt đầu tạo giá trị ngay, và nhân viên rời đi phải yên tâm rằng không còn vùng chưa biết nào bị bỏ lại
Một đội lý tưởng trong đó BF của tất cả mọi người đều là 0 là điều đáng mong muốn. Điều đó nghĩa là thành viên có thể thay thế cho nhau, và nếu ai đó ốm, đi nghỉ, thực sự rời đi hoặc bị loại khỏi đội, mọi thành viên đều có thể lấp chỗ trống
Quan trọng hơn, BF bằng 0 là sự phản ánh của tính đơn giản. Phần mềm, pipeline build·test·deploy, tài liệu và hệ thống hỗ trợ đều phải có tính gắn kết và nhất quán. Để thông tin bị silo trong từng thành viên là điều tệ hại, và mọi người đều phải có thể build và deploy
BF bằng 0 là một chỉ báo lành mạnh, nhưng tuyệt đối không được đo bằng số email, số commit, số PR, số dòng code, tốc độ phản hồi hay heatmap GitHub. Những chỉ số đó chẳng cho thấy gì cả, thậm chí còn là các chỉ số độc hại và khủng khiếp
Đánh giá con người bằng những chỉ số như vậy chẳng khác gì mấy con khỉ trước máy đánh chữ. Nhiều startup hơn cần nghe điều này
Có vẻ đang nói về cùng một khái niệm, nhưng thật ngạc nhiên là con số đó không phải lúc nào cũng được dùng theo cùng một chiều
Trong những dự án đẩy ranh giới của khả năng, tính đơn giản đôi khi không phải là một lựa chọn. Tất nhiên chúng chỉ chiếm tỷ lệ nhỏ trong toàn bộ các dự án phần mềm, nhưng khi làm điều chưa từng có, nỗi lo lớn hơn là “rốt cuộc làm sao thực hiện được việc này” chứ không phải giữ code đơn giản nhất có thể
Điều đó không có nghĩa là chất lượng code có thể thấp. Chỉ là khi làm việc khó, đôi khi cần code phức tạp, và có khi phải vài thế hệ sau các design pattern mới được hệ thống hóa để biến việc khó đó thành code ít phức tạp hơn. Chuyện đó có thể là 10 năm sau
Nếu thứ phức tạp nhất có thể tạo ra chỉ cỡ ứng dụng danh sách việc cần làm, tôi không nghĩ nó tạo được nhiều giá trị cho xã hội
Bus factor cao nghĩa là nhà tuyển dụng giữ bạn lại vì những gì bạn đã làm trong quá khứ hơn là vì tiềm năng tương lai của bạn
Luận điểm cốt lõi của bài báo gốc là phần này
“Ước tính của chúng tôi phụ thuộc vào giả định về độ bao phủ. Nếu tập hợp tác giả hiện tại bao phủ dưới 50% tập hợp file hiện tại của hệ thống, hệ thống rất có khả năng gặp chậm trễ nghiêm trọng hoặc bị dừng lại”
Ở đây, tác giả của một file được định nghĩa là người dùng đã có đóng góp có ý nghĩa cho file đó theo trọng số được tính trước
Một mặt, tôi còn thấy ngạc nhiên nếu loại chỉ số dashboard này chưa có sẵn trong phần mềm doanh nghiệp nào đó. Ban lãnh đạo ở công ty cũ của tôi từng thực sự hỏi liệu có thể tạo báo cáo hằng ngày về ai là người gửi và nhận nhiều email nhất trong bộ phận không
Tôi từ chối vì không thích hướng mà nó sẽ trôi tới, nhưng một đồng nghiệp khác đã làm. Đúng như dự đoán, người nhận và gửi nhiều email nhất là quản trị viên hệ thống, vì tài khoản của anh ấy được đặt làm người gửi email tự động cho nhiều máy chủ. Mỗi ngày anh ấy tự gửi cho mình hàng trăm email cảnh báo, cộng thêm các bản tin và email tổng hợp đã đăng ký
Mặt khác, nếu đồng nghiệp đều đã yêu cầu đừng làm việc gì có thể ảnh hưởng đến công việc của họ mà vẫn đẩy nó đi như một dự án sở thích, thì nghe khá là xấu tính
Chỉ là tôi muốn xem liệu phần mềm nguồn mở mà tôi dùng có phân tán tri thức đủ tốt để tăng khả năng sống sót hay không
Tôi đã từ chối hành động xấu tính đó
Tôi nghĩ “càng leo lên nấc thang sự nghiệp, lập trình viên càng nên ít trực tiếp gõ bàn phím hơn và review nhiều hơn” là một hiểu lầm phổ biến trong các công ty công nghệ
Chúng ta không muốn biến một lập trình viên xuất sắc thành một quản lý tầm thường
Anh ta sẽ phù hợp làm senior developer hơn tech lead rất nhiều. Khó tưởng tượng đội sẽ khổ sở thế nào nếu anh ta trở thành quản lý
Điều trớ trêu buồn của chuyện này là câu hỏi vẫn đang bị đặt sai
Khi một startup phải sa thải, câu hỏi không phải là “có thể cho ai nghỉ mà vẫn duy trì được hoạt động kinh doanh hiện tại”, mà là “đội ngũ nào sẽ xây dựng phiên bản tiếp theo của sản phẩm đủ nhanh để công ty không sụp đổ”
Mọi ngã rẽ rốt cuộc vẫn là ngã rẽ, và có nhiều công ty đã chết vì không chọn đường đủ nhanh
CPAN từ lâu đã theo dõi bus factor. Ví dụ https://metacpan.org/pod/Moose hiển thị Bus Factor 5 ở cột thông tin bên trái
Chúng tôi thích gọi cái này là lottery factor
Nghĩa là liệu dự án có thể tiếp tục hay không nếu ai đó trúng xổ số và rời đến một hòn đảo nhiệt đới không có cả điện lẫn mạng viễn thông
Gọi như vậy nghe đỡ rợn người hơn
Người bị xe buýt tông thì biến mất ngay lập tức. Hai chuyện đó không giống nhau
Có người không thích ẩn dụ thể thao, nhưng tôi cho rằng ít nhất nó vẫn tốt hơn ẩn dụ quân sự
Dù sao thì thường cũng có nhiều trường hợp không có bàn giao, nên bản thân yếu tố đột ngột có thể không quan trọng đến vậy