El cómo se estructuran los equipos tiene una fuerte relación con los bugs del software

Hay un popular artículo de Microsoft Research, que creo que mucha gente, más, debería conocer. Se trata de un estudio estadístico (sin olvidar que hay que tener mucho cuidado con las estadísticas) para ver que influencia tenían ciertas características, métricas, factores, etc., a la hora de que un módulo software tuviera más errores, más bugs.

Para hacer el estudio se observó…

  • El «Code Churn», el número de cambios en el control de versiones de un módulo.
  • La complejidad del código, como el número de rutas de código, el número de funciones que se llaman internamente en el módulo, la profundidad de las jerarquías de herencia, el acoplamiento entre objetos, el número de subclases, etc.
  • Las dependencias. Que mide la cantidad de módulos externos que lo llaman, cuántos módulos externos está llamando, a cuántas capas está alejado un módulo del hardware, etc.
  • Cobertura de pruebas del código. 
  • Combinaciones de métricas: lines of code, halstead software metrics, nesting levels, cyclomatic complexity (te dejo post), knots, number of comparison operators, loops, etc.
  • Errores de pre-lanzamiento.

Pero, además de los anteriores, que son clásicos a la hora de obtener métricas de calidad de código, en el estudio también incluyeron una  métrica organizacional. Y esta métrica midió en función de:

  • El número de desarrolladores que trabajan en el módulo.
  • El número de ex desarrolladores que trabajaron.
  • Frecuencia en la que el código se edita. 
  • etc.

Te dejo abajo una tabla que he sacado del artículo con más detalle sobre la métrica organizacional.

Los resultados (en la tabla de más abajo), como te puedes imaginar, fueron que lo que más peso tuvo fue la parte organizacional. En los resultados hay dos columnas, «Precisión» que es la predicción correcta de fuentes propensos a error y «Recall» es la proporción de fuentes propensos a error que fueron identificado correctamente.

Tres cosas antes de terminar. La primera es obvia, la estructura organizativa tiene una importante influencia en cómo se detectan y evitan los errores, los bug en el software, y, si hacemos caso a estos datos, esto está por encima de muchas métricas, clásicas, de software.

Segunda, esto es un resumen que te he dejado en formato post, si quieres profundizar, léete el artículo original aquí o este resumen, que no está mal. Y tercero, las estadísticas son lo que son, son complicadas de extrapolar, pero analiza los datos y relacionados con tus sensaciones personales en tu lugar de trabajo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba