Saltar al contenido

3 Conceptos erróneos sobre el Code Churn

El código de la rotación es un concepto aparentemente sencillo que también se suele malinterpretar. Dado que puede ser visto como “tirar el código”, no es sorprendente que el término pueda llevar una buena cantidad de temor y equipaje.

Puede ser útil desempacar el término aquí, ya que la comprensión de los matices del cambio de código da a los líderes de la ingeniería una percepción sin precedentes de cómo operan sus equipos.

3 Conceptos erróneos sobre el Code Churn
3 Conceptos erróneos sobre el Code Churn

Después de trabajar con cientos de clientes y analizar más de 40 millones de compromisos de desarrolladores de software profesionales, aquí están los 3 principales conceptos erróneos que los líderes de la ingeniería tienen sobre el Code Churn.

Mito #1: El código Churn es “malo”

La realidad: El Código Churn no es ni bueno ni malo… es una señal útil.

Las pruebas y la reelaboración son partes naturales del proceso de desarrollo de software. Sin embargo, los niveles de Code Churn que se desvían significativamente más alto o más bajo que las normas esperadas pueden representar el humo que es un indicador de un incendio potencial.

Por ejemplo, un elevado Code Churn podría ser un indicador de que su equipo recibió requisitos poco claros, o que el propietario de un producto está enviando a su ingeniero a correr en círculos (véase 6 Causas del Code Churn por razones adicionales). Por ejemplo, es probable que usted espere ver un aumento significativo en el Churn al comienzo de un proyecto ambicioso, una señal de que su equipo está experimentando con diferentes caminos de implementación.

El código Churn puede ser interpretado sólo como eso: otro punto de datos. No es ni bueno ni malo, es una señal de datos que ayuda a pintar un cuadro completo del rendimiento de la ingeniería. Cuando entiendes lo que está pasando en la base de código, entiendes mejor a tu equipo.

Mito #2: No hay tal cosa como la mantequera “normal”

La realidad: En la evaluación comparativa de los patrones de contribución de código de más de 85.000 ingenieros de software, el equipo de ciencia de datos de GitPrime identificó que los niveles de Code Churn con mayor frecuencia se encuentran entre el 13-30% de todo el código comprometido (es decir, 70-87% de eficiencia), donde un equipo típico puede esperar operar en el vecindario del 75% de eficiencia.

Por supuesto, los niveles de Code Churn variarán entre los individuos, los tipos de proyectos y, a lo largo del ciclo de vida del software. La idea aquí es familiarizarse con los niveles de Code Churn de base en sus proyectos típicos para que pueda a) identificar cuándo su equipo puede estar colgado y necesitar ayuda, o b) mantenerse al margen de su equipo cuando esté en un flujo saludable.

El cerebro humano es un fantástico dispositivo de coincidencia de patrones. Nos inclinamos naturalmente a llenar los vacíos en la información que tenemos. Y aunque es una habilidad increíble, puede causar sesgos perjudiciales (y culpar) para emerger cuando tenemos una perspectiva limitada – o cuando usamos datos sin contexto.

La intención no es encontrar El Perfecto Way™ que todo el mundo debería operar. El propósito es instrumentar sistemas de software de registro y dar a los gerentes ricos datos sobre sus equipos, para que puedan entender las diferentes “normales” y saber cuando las cosas cambian.

Mito #3: La rotación debe ser consistente a través del ciclo de vida de un proyecto

La realidad: El Código Churn puede ser abultado. Un proyecto sano puede tener un Churn elevado al principio del proyecto y un Churn más bajo hacia el final. Medir el Code Churn a través de varios equipos y proyectos te ayudará a identificar qué fluctuaciones son naturales, y cuáles son indicadores de que algo está mal.

Como se mencionó en el Mito #1, se puede esperar ver un elevado “batido exploratorio” hacia el comienzo de un proyecto, especialmente cuando un equipo es pionero en una nueva característica. Un nivel de “Churn” inusualmente alto (o bajo) podría ser un indicador temprano de que un proyecto no está progresando como se planeó.

Si nota un gran revuelo en el trabajo que lleva a una liberación, habría justificado una razón para preocuparse. Sabrás que la liberación está llegando en caliente, o tienes un aviso previo de que la liberación va a resbalar.

Pero con los datos, se puede detectar a tiempo, comunicarse con las partes interesadas y tomar una decisión informada sobre el envío. Cuando la gente sabe que las cosas están por venir, generalmente son capaces de sentirse cómodos con ello. Es cuando el lanzamiento se debe hacer hoy a las 4:00 pm, y a las 3:59 pm se anuncia que el lanzamiento va a ser tarde – es cuando Ingeniería comienza a perder la confianza y el respeto.

Tener los datos correctos para poder predecir nuestro trabajo de forma fiable da más peso a la ingeniería. Este tipo de poder de predicción ayuda a la Ingeniería a construir el respeto de otras organizaciones en la empresa.

El objetivo de adoptar métricas

Los líderes de ingeniería han estado corriendo con señales limitadas durante demasiado tiempo.

Imagina que estás conduciendo un coche, pero no puedes mirar afuera. De vez en cuando, recibes un ping que dice “gira a la izquierda”. Ese es un mundo de información empobrecido. Y ese es exactamente el mundo en el que la ingeniería ha estado trabajando.

El objetivo de monitorear el Code Churn y otros KPIs de ingeniería es complementar su motor de intuición con datos concretos. Ya han pasado los días de la recolección manual y las largas cadenas de informes. Los bucles de retroalimentación basados en datos le ayudan a encontrar oportunidades de mejora de los procesos y a ajustar los flujos de trabajo de ingeniería en tiempo real.

Con los datos correctos en la mezcla, los gerentes de ingeniería pueden obtener una lectura real de su equipo y notar cuando las cosas son anormales. La próxima ola de liderazgo efectivo de Ingeniería se define por el uso de datos concretos para determinar lo que funciona, identificar el riesgo y celebrar las victorias. Los datos están ayudando a los líderes de ingeniería a nivelar su equipo con mejores decisiones, tomadas más rápidamente, para apoyar, guiar y desafiar eficazmente a sus equipos a hacer el mejor trabajo de sus carreras.