Saltar al contenido

Los ingenieros prolíficos toman pequeños bocados: Patrones en el impacto de los desarrolladores

Los patrones de trabajo de los ingenieros revelan cosas interesantes sobre su carácter, pero no es lo que se podría imaginar.

Nuestra hipótesis: Rápido vs. voluminoso

Los ingenieros prolíficos toman pequeños bocados: Patrones en el impacto de los desarrolladores
Los ingenieros prolíficos toman pequeños bocados: Patrones en el impacto de los desarrolladores

Para explorar esto, comenzamos con la hipótesis de que algunos ingenieros de un equipo son mejores para dar vuelta el trabajo rápidamente, mientras que otros son mejores para quemar mucho trabajo. Si es correcto, esto llevaría a una interesante distribución de los ingenieros en dos ejes: Frecuencia y Volumen, dando como resultado un gráfico que se veía algo así:

¿Pero qué significa “volumen”?

Encontrar $0027Grande$0027

Probamos todas las versiones de “grande” que se nos ocurrieron. Como Líneas de Código (LoC) es simple (¡aunque muy denigrado!), empezamos allí para obtener una línea de base. LoC no funciona realmente como una métrica operacional, por razones que exploramos más a fondo aquí, pero proporcionó un punto de partida para algo mejor.

El desafío es encontrar alguna métrica que tenga en cuenta el hecho de que eliminar 50 líneas de código y sustituirlas por 5 líneas de código más eficiente es posiblemente “más grande” (por ejemplo, más trabajo) que contribuir con 100 nuevas líneas de código prototipo sin editar: el trabajo puramente de campo es a menudo mucho más fácil que perseguir un molesto error que resulta en un cambio de 4 líneas.

Nos esforzamos por medir la “grandeza” del trabajo desde casi todos los demás ángulos concebibles: la huella global del código, líneas vivas en la base del código, líneas que se “pegan”, número de archivos golpeados, distintas ubicaciones de edición, prácticamente todo lo que podríamos medir.

Lo que terminó ayudándonos a romper esta nuez fue el impresionante cuerpo de investigación académica sobre el trabajo de ingeniería, en particular sobre la normalidad de los compromisos: hay, de hecho, algo así como un compromiso “normal”, y esto terminó siendo la semilla de un muy razonable proxy para el trabajo de ingeniería, algo que ahora llamamos “Impacto”.

Con el impacto, cruzamos varios puntos de datos en un intento de aproximar la carga cognitiva del trabajo de ingeniería y, después de un poco de ajuste, encontramos algo que mapea las intuiciones de los desarrolladores mucho mejor de lo que la LoC por sí sola podría hacer.

Aprender que rápido es grande

Al analizar millones de compromisos a través de miles de equipos, nuestra teoría inicial sobre cómo trabajan los ingenieros resultó ser completamente falsa.

El chequeo frecuentemente tiene una correlación tan estrecha con el impacto general de un individuo en la base de código que son equivalentes funcionales, lo que resulta en una banda que se ve así:

La frecuencia de compromiso se mueve al mismo ritmo que el impacto general en la base del código, por cualquier otra medida que se nos ocurra.

Esta correlación es tan fuerte, de hecho, al analizar más de 20 millones de compromisos entre miles de equipos, no encontramos ningún contra-ejemplo fuerte a esto.

Los ingenieros de alto impacto dan pequeñas y rápidas mordidas

Esto es algo fascinante en sí mismo, porque decir “tenemos que hacer más trabajo” es una manera un tanto cutre de enfocar la mejora del rendimiento de un equipo de ingeniería. La mayoría de los ingenieros ya están haciendo lo mejor que pueden, así que si el equipo necesita “hacer más trabajo”, no es inmediatamente obvio cómo va a suceder y sólo resulta en malos sentimientos.

Lo fascinante de este conjunto de datos en particular es que sugiere que puede haber cosas estructurales para cambiar la forma en que trabajamos que pueden dar lugar a aumentos de eficiencia.

Romper el trabajo en trozos granulares ya se considera una práctica óptima, pero estos datos sugieren que puede ser más que eso: fomentar esto (y desarrollar bucles de retroalimentación que ayuden a asegurarse de que está ocurriendo) parece ser un camino más factible para fomentar un mayor impacto individual.

“Dar pequeños mordiscos y revisar con frecuencia” es accionable y visible; decir “hacer más trabajo” sólo actúa como un factor estresante.

Y esto es una ganancia holística: además de ser generalmente bueno para la capacidad de un ingeniero de hacer un impacto personal, los compromisos más pequeños y más frecuentes producen otras externalidades positivas para el resto del equipo:

  • Más compromisos granulares hacen más fácil encontrar y rastrear los bichos cuando algo se rompe
  • Es más fácil retroceder cambios específicos en lugar de un conjunto de cambios gigantescos.
  • El trabajo más pequeño está enfocado y es más fácil de revisar e integrar para los compañeros de equipo
  • Menores gastos de proceso para todos con menos compromisos de fusión

Un cuadro exitoso de la actividad de ingeniería

Terminamos creando algo que dice mucho sobre el estilo de la ingeniería, pero resultó un poco diferente de lo que pensábamos. Tomamos todo lo que aprendimos sobre el impacto y lo enrollamos en un solo eje llamado rendimiento. Gracias a toda nuestra exploración, fuimos capaces de encontrar una forma de medir el impacto del código que deja atrás la visión excesivamente reduccionista del desarrollo de software (puedes leer más sobre cómo calculamos el impacto aquí).

En el otro eje, trazamos la tasa de rotación, es decir, cuánto se dedica un ingeniero a reelaborar el código reciente.

Trazar el resultado en un gráfico de dispersión puede revelar bastante sobre el patrón de trabajo de un ingeniero en un marco temporal específico en el contexto del resto del equipo.

1

El visual resultante ofrece pistas útiles sobre un equipo:

  • En el cuadrante inferior izquierdo, conservamos el “detector de atascos” que queríamos de nuestro diseño original.
  • La parte superior izquierda destaca a los ingenieros que están explorando una implementación – normalmente vemos ingenieros que están haciendo rápidamente un prototipo de una nueva característica en este cuadrante.
  • La parte inferior derecha alberga a los “perfeccionistas” que tienen la menor rotación del equipo, pero que se mueven un poco más lento en general.
  • Finalmente, en la parte superior derecha están los ingenieros que están revisando mucho trabajo, con poca necesidad de retrabajos – ¡generalmente es una buena idea evitar interrumpir a estas personas, porque están en llamas!

Notas:

  1. Gracias a Bobby Wallace por ayudar a renombrar el viejo cuadrante “Explorador”, ahora llamado “Descubrimiento”. ?