Saltar al contenido

Impacto: una mejor manera de medir el cambio de la base del código

Un ingeniero contribuye con 100 nuevas líneas de código en un solo archivo.

Compare eso con la contribución de otro ingeniero, que toca tres archivos, en múltiples puntos de inserción, donde agregan 16 líneas, mientras que eliminan 24 líneas.

Impacto: una mejor manera de medir el cambio de la base del código
Impacto: una mejor manera de medir el cambio de la base del código

El significado de cada contribución no puede reducirse a la cantidad de código que se registra. Incluso sin conocer los detalles, es probable que el segundo conjunto de cambios fuera más difícil de implementar, dado que implicaba varias modificaciones puntuales del código antiguo.

El camino del ingeniero probablemente se veía algo así:

  1. Lee el viejo código
  2. Invierte tiempo en comprender la intención original de ese código
  3. Comprobar si los cambios previstos pueden crear daños colaterales
  4. Hacer los cambios
  5. Quitar y limpiar cualquier código irrelevante
  6. La cordura comprueba el enfoque después

En comparación con el desarrollo de los campos verdes, que se salta más de la mitad de estos pasos, la segunda contribución conlleva una carga cognitiva mucho más alta. Esto también demuestra por qué las métricas simplistas fallan al describir el trabajo involucrado en la ingeniería de software.

“Medir el progreso de la programación por líneas de código es como medir el progreso de la construcción de aviones por peso”. – Bill Gates

Introduciendo el impacto

En su lugar, considere una forma de medir el significado de los cambios de código que respete los matices de la ingeniería de software. Se llama Impact.

El impacto intenta responder a la pregunta: “¿Aproximadamente cuánta carga cognitiva llevó el ingeniero al implementar estos cambios?”

El impacto tiene en cuenta lo siguiente:

  1. La cantidad de código en el cambio
  2. ¿Qué porcentaje de la obra se edita a código antiguo
  3. La superficie del cambio (piensa en el “número de lugares de edición”)
  4. El número de archivos afectados
  5. La gravedad de los cambios cuando se modifica el código antiguo
  6. Cómo se compara este cambio con otros de la historia del proyecto

En el ejemplo anterior, la segunda contribución es más impactante: El cambio modifica el trabajo anterior, las ediciones se realizaron en 4 lugares diferentes, y 3 archivos diferentes fueron afectados.

Incluso sin conocer la gravedad de los cambios o compararlos con los cambios históricos, es probablemente seguro asumir que la segunda contribución fue más “cara”, y por lo tanto conlleva una mayor puntuación de impacto.

Tres maneras de usar el Impact

Aquí hay algunas formas en que los equipos de ingeniería utilizan el impacto para medir las contribuciones y reconocer el rendimiento de la ingeniería:

1. ¿Han cambiado los cambios de personal?

Lanzar más cuerpos al desarrollo de software no garantiza que se mueva más rápido. Como Fred Brooks señaló, “añadir mano de obra a un proyecto de software tardío lo hace más tarde”. El impacto permite a los equipos entender y comunicar cómo los cambios de personal afectan al progreso.

En el transcurso de un año, una compañía amplió y dotó de personal a su equipo de ingeniería. Usando el impacto, este líder tenía datos concretos para la sala de juntas: