Bus Number: el plugin de GitHub que mis colegas me pidieron no escribir

• A partir de la experiencia de que, tras un despido, desapareciera el único contribuidor de código rentable, un desarrollador quiso crear en GitHub Enterprise un plugin de truck factor para encontrar a las personas que no se pueden perder
• Sus colegas temían que esta métrica terminara cayendo en la Ley de Goodhart y, en vez de proteger a las personas clave, se convirtiera en una herramienta de gestión para encontrar a quién sí se puede despedir
• El repositorio y los datos originales de Truck-Factor seguían siendo utilizables, pero la fecha de recolección de datos no estaba clara y el procedimiento del README ya no se podía reproducir tal cual, así que hizo falta corregirlo manualmente
• El recálculo consistió en clonar varios repositorios de GitHub con gnu parallel y luego ejecutar código Java; para Linux kernel, el truck factor dio 12 sin el filtro de linguist y 8 con el filtro aplicado
• Como el resultado quedó por debajo de las cifras del artículo original —90 en el preprint de 2015 y 57 en la publicación formal—, es difícil sostener que el bus factor de Linux kernel haya mejorado

---

Bus Factor y una idea de plugin peligrosa

• Bus Factor o Truck Factor se refiere al número mínimo de integrantes del equipo que tendrían que desaparecer de repente para que un proyecto se detenga por falta de conocimiento clave
• El punto de partida fue que, alrededor de 2015, durante una ronda de despidos en la empresa, despidieron al único contribuidor de una parte del código que generaba dinero para la compañía
• Después de pensar en el Truck Number, surgió la idea de un plugin para GitHub Enterprise que calculara a las personas a las que no se debe despedir
• Cuando presentó este plugin durante 5 minutos en una lightning talk un jueves por la tarde, sus colegas vieron que la gerencia podía usarlo como una herramienta para encontrar a quién sí se puede despedir
• El punto central de esa reacción fue la Ley de Goodhart

Investigación previa sobre Truck Factor e intento de reproducción

• El estudio original calculaba, en varios proyectos populares de GitHub, cuántas personas tendrían que desaparecer para que el proyecto se detuviera
• Entre los casos analizados estaba Linux kernel
• Al inicio del texto se dice que el primer preprint sostenía que Linux se detenía si se iban 80 personas; más adelante se resume que la cifra del preprint de 2015 era 90 y la de la publicación completa era 57
• Junto con mclare, intentó reproducir los resultados casi 10 años después para comprobar si el truck factor había mejorado
• El repositorio de GitHub de los autores originales seguía disponible y se podía usar

Limitaciones de los datos y del entorno de ejecución

• Los datos del artículo se ofrecían en JSON, y la visualización original se basaba en un CSV que todavía se podía scrapear
• Sin embargo, no se podía saber la fecha de recolección de los datos
• Las instrucciones del README ya no funcionaban tal cual, así que hubo que corregir la forma de ejecución consultando issues de GitHub
• A partir de la primera columna del CSV original se extrajo la lista de repositorios de GitHub para clonarlos todos
• Con gnu parallel se ejecutaron múltiples comandos git clone al mismo tiempo

gnu parallel, linguist y el atasco en NixOS

• Aunque se indicó -j 8 en gnu parallel, ocurrió que se usaron los 32 núcleos de la laptop
• Había 8 procesos git clone visibles al mismo tiempo, pero muchos procesos git index-pack estaban ocupando todos los núcleos
• Como posible causa, se planteó que git index-pack fuera un subproceso lanzado por fork, lo que hacía que parallel iniciara otros git clone
• El código de Truck Factor usa linguist de GitHub para excluir archivos de documentación
• En un entorno NixOS, como no había experiencia con Ruby, no se logró resolver a tiempo la instalación de Ruby Gems, así que se pidió ayuda para instalar el plugin linguist desde un flake de Nix o mediante un pull request

Procedimiento real del recálculo

• Se hizo un fork del repositorio original, se clonó localmente y se ajustó la ejecución siguiendo el README
• El código Java se compiló a un jar con mvn package
• Primero se probaron todas las etapas con el repositorio de GitHub de numpy, y después se recalcularon todos los repositorios
• mclare descargó el CSV de la visualización original y convirtió su primera columna en una lista de repositorios de GitHub
• El flujo de ejecución fue el siguiente
  • Se clonaron los repositorios con parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt)
  • Se cambió al directorio gittruckfactor/scripts para evitar errores de awk
  • Con commit_log_script.sh se extrajo la información de commits de cada repositorio
  • Se ejecutó gittruckfactor-1.0.jar para procesar los datos de commits extraídos
• Con una conexión doméstica rápida de internet gigabit, clonar todos los repositorios de manera secuencial tomó 17.5 minutos
• El procesamiento de cada repositorio también pareció tardar unos 18 minutos en promedio

Resultados del recálculo para Linux kernel

• La salida de ejemplo para Linux kernel fue TF = 12, coverage = 49.98%
• Entre los autores TF estaban Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner y Krzysztof Kozlowski
• Linus Torvalds aparecía con 5,712 archivos y 6.59%
• Sin el plugin linguist, es decir, sin filtrar documentación ni librerías de terceros, el truck factor de Linux kernel fue 12
• Después de que mclare instalara el plugin linguist en su sistema, el truck factor de Linux kernel que obtuvo fue 8

Elementos fuera del cálculo y siguientes verificaciones

• Este cálculo no refleja el proceso de revisión
• A medida que sube la experiencia, existe el problema de que los desarrolladores tienen que revisar más código que escribirlo directamente con el teclado
• Entre los puntos adicionales por comprobar están los siguientes
  • Si el cálculo del truck factor contempla co-authored-by y los headers de reviewers en git
  • Si no los contempla, si sería posible incorporarlos al cálculo
  • Por qué la cifra de Linux cambió tanto 10 años después
  • Si el hecho de no haber aplicado distancia de Levenshtein 1 para fusionar alias de desarrolladores, como hacía el artículo original, afectó el resultado
  • Si al hacer checkout del repositorio de Linux kernel a mediados de 2015 el mismo código seguiría dando 80
  • Si, dado que el algoritmo se actualizó en 2016, es posible volver a calcular cifras posteriores
• También se pueden revisar las 156 citas del artículo original para ver si existe un mejor método de cálculo
• Como proyectos grandes más recientes, como Rust, no estaban incluidos en el artículo de 2015, se pueden comparar proyectos populares actuales con su historial pasado
• Incluso se podría crear un script para encontrar el truck number por año para cualquier repositorio git

Un Bus Factor todavía más bajo

• La pregunta que se quería verificar era si el truck factor había mejorado con el paso del tiempo
• El resultado apunta más bien a que no mejoró, sino que empeoró
• En Linux kernel, el resultado de esta ejecución quedó muy por debajo de las cifras del artículo original
• Dependiendo de si se filtran o no la documentación y las librerías de terceros, el resultado para Linux kernel baja aún más, de 12 a 8
• Más visualizaciones y detalles se pueden consultar en el artículo de mclare

[GN⁺]

Opiniones de Hacker News

• Una de las funciones de https://codescene.com/ es justamente esto.
  Encuentra islas de conocimiento y las conecta con código que cambia con frecuencia, para identificar hotspots riesgosos: zonas con muchos cambios pero poca distribución del conocimiento.
  Si alguien anuncia que se va de la empresa, puedes ver fácilmente qué código solo conoce esa persona, lo que también facilita armar un plan de traspaso.
  Nunca se me había ocurrido que pudiera usarse de forma indebida; originalmente es una herramienta de visibilidad. Un gerente que la use así es un pésimo gerente, y si ya es así, esta herramienta no va a cambiarlo.

  • No hay que ver el “uso indebido” de forma demasiado ingenua. Supongamos que perteneces a una agencia de inteligencia de cierto país. Digamos que eres Tussia, un país al que se le bloqueó el acceso a Kinux, un kernel clave usado en equipamiento militar de todo el mundo, y te enteras de que la persona de la oficina de al lado inició un proyecto para hacer un fork de ese kernel para uso interno de su país.
    Si tienes ambiciones de ascenso, podrías pedirle al departamento encargado de captaciones “8 agentes mujeres con entrenamiento especial para acercarse a nerds” y, por si falla, pedir también 8 dosis de polonio como respaldo.
    Puede sonar como ficción total, pero sé de un CEO de una startup unicornio que buscaba inversión semilla y que realmente vivió la primera parte de algo así.
  • Estuve en tres lugares de trabajo donde se implementó Pluralsight Flow, y en dos de ellos los gerentes empezaron de inmediato a usar las métricas para feedback, evaluaciones de desempeño y decisiones de contratación.
    En el tercer lugar, los desarrolladores reconocieron esta dinámica desde lejos y se negaron a usar la herramienta o a ser evaluados con ella.
    Estas herramientas tienen precios absurdamente altos, así que quien las aprueba tiene que sacarles retorno de inversión como sea. Como no hay una buena forma de medir productividad, entregables o silos de conocimiento, al final termina derivando en cosas como “Jose tuvo pocos PR esta semana”.
  • El uso como visibilidad en sí es excelente, pero solo si puede mantenerse dentro de ese ámbito.
    El problema es que los desarrolladores también pueden verlo e intentar moverse hacia proyectos o componentes objetivo para entrar en la lista de empleados imposibles de despedir. Idealmente, los trabajadores podrían moverse en conjunto para llevar el truck factor a 0 y hacer que sea difícil despedir a cualquiera.
    Claro que eso se volvería una pérdida de tiempo casi total y probaría el punto original de los colegas del bloguero: “esto caería de inmediato en la ley de Goodhart”.
  • Una consultora externa también podría usar esto para ayudar a una empresa con despidos. Incluso si el gerente es excelente.

• En Amazon, este tipo de número se puede ver fácilmente en los sistemas de código como un reporte que cualquier gerente puede ejecutar, y también hay muchas otras formas de ver qué está haciendo un equipo y qué riesgos existen. Personalmente me parece útil.
  El bus factor es solo una perspectiva; desde otra, permite encontrar y corregir silos, ingenieros que no colaboran con otros y áreas donde es difícil mover ingenieros.
  Algunos desarrolladores temen ser reemplazables y creen que un sistema que solo ellos conocen es seguridad laboral, pero al revés: eso es un riesgo técnico y también puede impedir que un buen ingeniero pase a proyectos más importantes. También puede ser el camino para poder hacer otra cosa cuando ya estás harto de un sistema que detestas.

  • No me da miedo ser reemplazable. Si un lugar no me quiere, yo tampoco quiero estar ahí.
    Pero la idea de la reemplazabilidad genera mucho overhead y hace que no se aproveche al máximo a la gente talentosa. Porque en realidad no son reemplazables.
    En algunos lugares es necesario, pero en otros el overhead de proceso termina siendo un riesgo mucho mayor para el éxito del proyecto que el bus factor.
  • Conozco a un desarrollador al que le negaron movilidad y ascenso porque no podían cubrir fácilmente su puesto.
    El final fue que renunció en menos de 3 meses.
  • “Si no puedes ser reemplazado, no puedes ser promovido”.
  • Desde la perspectiva de un empleado cuyo objetivo principal no es optimizar las ganancias de la empresa, pensar que un sistema que solo él conoce le da seguridad laboral también es una estrategia realista.
  • Durante toda mi carrera intenté hacer que yo y otros desarrolladores fuéramos lo más reemplazables posible. Parte importante del trabajo de digitalización consiste justamente en eso, y también porque lidiar con silos de conocimiento es frustrante.
    Una de las razones por las que uso mucho TypeScript también en backend es que reduce a uno solo el lenguaje que un equipo pequeño necesita conocer. Así, si un desarrollador frontend se va de vacaciones, realmente puede desconectarse, y alguien más puede cubrirlo. Si alguien cambia de trabajo, duele menos.
    Nunca me causó problemas, y veo la reemplazabilidad como parte de un sistema sano. Después de pasar algunos años en gestión, una de las primeras cosas que se aprende es que “todos son reemplazables, solo es cuestión de costo”. Por eso, si el nivel de conocimiento de alguien es demasiado alto, incluso puede jugarle en contra, porque la gerencia intentará reducir ese riesgo. Además, los despidos por motivos económicos suelen ser bastante aleatorios.
    Dicho eso, no quisiera trabajar en un lugar que use métricas ridículas como estas. Mientras más burocracia pongas alrededor de hacer buen trabajo, menos probable es que quiera trabajar contigo. Estas cosas tienden a crear una cultura donde la gente juega con las métricas en vez de hacer buen trabajo, y eso no es bueno para la productividad ni la calidad.

• gnu parallel está ejecutando 8 tareas de git clone al mismo tiempo, tal como se le pidió, y cada git clone está iniciando por su cuenta un montón de hilos de index-pack.
  En este caso ayuda configurar temporalmente pack.threads en 1 con git config.

  • Es un problema cada vez más común. Ambas capas paralelizan según la cantidad de CPU o núcleos e intentan usar toda la máquina, y en la capa interna terminan apareciendo N² hilos/procesos.
    Como crece al cuadrado, mientras más CPU haya, peor se vuelve el problema. Con 32 núcleos, 32² = 1024, y en la práctica, como se especificaron 8 en Parallel, probablemente se habría detenido en algo así como un máximo de 256 procesos index-pack. Aun así, para soportar eso se necesita mucha memoria y, en realidad, no se gana nada.
    La solución es paralelizar solo una de las dos capas.
    Sobre pack.threads, man git-config lo explica así: especifica la cantidad de hilos que se crearán al buscar las mejores coincidencias delta, y git-pack-objects(1) debe estar compilado con pthreads. Si no, se ignora con una advertencia. Es una opción para reducir el tiempo de empaquetado en máquinas multiprocesador, pero la memoria necesaria para la ventana de búsqueda delta se multiplica por la cantidad de hilos. Si se especifica 0, Git detecta automáticamente la cantidad de CPU y ajusta la cantidad de hilos en consecuencia.
  • En vez de configurar algo temporal con git config, basta con usar git -c pack.threads=1 clone: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

• Esa interpretación no me convence. Creo que este artículo es para todos los líderes de ingeniería.
  El factor bus significa cuánto sufre un equipo si alguien del equipo, o uno mismo, es atropellado por un autobús.
  El factor bus ideal para todos los miembros del equipo es 0. Al principio puede sonar como “hacer que todos sean desechables”, pero en realidad es casi lo contrario, y ese es el punto.
  El equipo debe ser lo suficientemente bueno como para ser a) autónomo y b) no tener misterios. En el estado ideal, todos entienden cómo funciona todo. Un empleado nuevo debería poder empezar a generar valor de inmediato, y alguien que se va debería poder irse tranquilo sabiendo que no quedan zonas desconocidas.
  Un equipo ideal donde todos tienen BF 0 es deseable. Significa que los miembros del equipo son reemplazables, y que si alguien se enferma, se va de vacaciones, realmente se va o lo sacan, cualquier miembro del equipo puede cubrir el hueco.
  Más importante aún, un BF 0 es un reflejo de la simplicidad. El software, los pipelines de build, pruebas y despliegue, la documentación y los sistemas de soporte deben ser cohesionados y consistentes. Encerrar información en silos dentro de miembros del equipo es malo, y todos deberían poder compilar y desplegar.
  Un BF 0 es una señal saludable, pero jamás se mide con cantidad de correos, commits, PR, líneas de código, velocidad de respuesta o heatmaps de GitHub. Esas métricas no muestran nada y, peor aún, son métricas dañinas y horribles.
  Evaluar a las personas con esas métricas no es distinto de poner monos frente a una máquina de escribir. Más startups necesitan escuchar esto.

  • Siempre había escuchado el factor bus al revés. Algo como “¿cuántas personas tienen que ser atropelladas por un autobús para que el proyecto no pueda seguir?”, y entendía que el valor óptimo era igual al tamaño del equipo.
    Parece que hablamos del mismo concepto, pero me sorprende que ese número no siempre se use en la misma dirección.
  • Trabajé en un proyecto donde, en todo el mundo, había apenas un puñado de personas con cierta habilidad específica. En ese momento, el factor bus era claramente 1.
    En proyectos que empujan los límites de lo posible, a veces la simplicidad no es una opción. Claro que son una pequeña proporción de todos los proyectos de software, pero cuando haces algo que no se había hecho antes, la preocupación mayor no es mantener el código lo más simple posible, sino “cómo demonios hacemos esto”.
    Eso no significa que la calidad del código pueda ser baja. Solo que, al hacer cosas difíciles, a veces se necesita código complejo, y puede que solo varias generaciones después se ordenen los patrones de diseño y esa tarea difícil pueda hacerse con código menos complejo. Eso podría pasar dentro de 10 años.
  • Si desde el primer día cualquiera puede entender el código y no se requiere conocimiento del dominio, ¿cuál es la propuesta de valor de ese producto o equipo?
    Si lo más complejo que pueden construir es una app de tareas, no creo que estén creando mucho valor para la sociedad.
  • Las personas que hacen bien su trabajo y tienen confianza intentan activamente reducir su propio factor bus.
    Un factor bus alto significa que tu empleador te retiene por lo que hiciste en el pasado, no por tu potencial futuro.
  • El ejército piensa así. Parte de la premisa de que debe seguir funcionando aunque pierda gente.

• El argumento central del artículo original es esta parte:
  “Nuestra estimación depende de la suposición de cobertura. Si el conjunto actual de autores cubre menos del 50% del conjunto actual de archivos del sistema, es probable que el sistema sufra demoras graves o se detenga”.
  Aquí, el autor de un archivo se define como un usuario que hizo una contribución significativa a ese archivo según un peso precalculado.

• Por un lado, me sorprendería si este tipo de métricas de dashboard no estuviera ya incorporado en algún software empresarial. En una empresa anterior, la gerencia literalmente preguntó si se podía generar un informe diario de quién enviaba y recibía más correos en el departamento.
  Me negué porque no me gustaba hacia dónde podía ir eso, pero otro colega lo hizo. Como era de esperarse, la persona que más correos recibía y enviaba era el administrador de sistemas, porque su cuenta estaba configurada como remitente automático de correos de varios servidores. Se estaba enviando a sí mismo cientos de correos de alerta al día, además de newsletters y correos de resumen a los que estaba suscrito.
  Por otro lado, si tus colegas te pidieron que no hicieras algo que podría afectar sus empleos y aun así lo impulsas como proyecto personal, suena bastante malintencionado.

  • En 2015, cuando mis colegas me pidieron que no lo hiciera, no lo hice.
    Pero sí quería ver si el software open source que uso había difundido el conocimiento lo suficiente como para aumentar sus probabilidades de supervivencia.
    Rechacé hacer esa maldad.
  • Es una métrica absurda.

• Creo que “a medida que un desarrollador sube la escalera profesional, debería escribir menos código directamente y hacer más revisiones” es un malentendido común en las empresas tecnológicas.
  No queremos convertir a un gran desarrollador en un gerente mediocre.

  • Exacto. Hay un tech lead con excelente capacidad para escribir código, pero pésimas habilidades de liderazgo o feedback.
    Le iría mucho mejor como desarrollador sénior que como tech lead. Es difícil imaginar cuánto sufriría el equipo si se convirtiera en gerente.
  • Si consideras que la revisión de código es “gestión”, eso es bastante preocupante.

• La triste ironía de esto es que la pregunta sigue estando mal planteada
  Cuando una startup tiene que hacer despidos, la pregunta no es “a quién podemos despedir y aun así mantener el negocio actual”, sino “cuál es el equipo que puede crear la próxima versión del producto lo suficientemente rápido como para que la empresa no quiebre”
  Todas las encrucijadas, al final, son encrucijadas, y muchas empresas murieron por no elegir un camino lo suficientemente rápido

• CPAN lleva mucho tiempo siguiendo el factor bus. Por ejemplo, https://metacpan.org/pod/Moose muestra un Bus Factor 5 en la columna de información de la izquierda

  • También documentaron cómo se calcula ese número: https://www.olafalders.com/2021/06/30/cpan-bus-factor/

• A nosotros nos gusta llamarlo factor lotería
  Se refiere a si el proyecto puede continuar aunque alguien gane la lotería y se vaya a una isla tropical sin electricidad ni telecomunicaciones
  Así suena menos siniestro

  • Quien gana la lotería da aviso de renuncia con 2 semanas de anticipación y, si de verdad hace falta, se le puede llamar después
    La persona atropellada por un autobús desaparece de inmediato. No es lo mismo
  • Un buen empleado querrá hacer la transferencia de su proyecto y responder preguntas, pero también hay que prepararse para los casos en que no pueda hacerlo
  • Usar “muerte súbita” como eufemismo para cambiar de trabajo deja un mal sabor
    Hay gente a la que no le gustan las metáforas deportivas, pero al menos me parecen mejores que las metáforas militares
    De todos modos, muchas veces tampoco hay una transferencia de conocimiento normal, así que quizá lo repentino en sí no sea un factor tan importante
  • Puede que ser atropellado por un autobús sea lo más fácil, así que también hay que reflejar esa posibilidad
  • No sé de nadie que haya ganado una gran lotería o haya sido atropellado por un autobús, pero sí conozco a varias personas que renunciaron tras volverse ricas con criptomonedas