¿Por qué son perjudiciales las estadísticas de confirmación de desarrollador?

10

Durante mucho tiempo he creído (y escuchado de otros) que realizar un seguimiento de las estadísticas de confirmación, como cuántas confirmaciones hace cada desarrollador por día, es perjudicial para el proceso de desarrollo. La razón parece obvia: los desarrolladores se comprometerán en incrementos más pequeños, maximizando su número de confirmación por día, pero haciendo que sea más difícil de dividir (quizás todos sus parches intermedios no dejarán el repositorio bien formado) y más difícil trabajar con el historial de confirmación (un cambio de repente se realizará en múltiples confirmaciones, en lugar de solo una, revertir un parche es más difícil, etc.).

¿Hay algún estudio que muestre que las estadísticas de compromiso son perjudiciales? ¿Algún artículo elegante y bien discutido sobre el tema? Igualmente aplicable sería cualquier cosa sobre por qué medir lo incorrecto lleva a las personas a optimizar lo incorrecto, de lo que este problema es solo un caso especial.

version-control Neil Mitchell
fuente
8
"¿Algún artículo elegante y bien argumentado"? Su pregunta es elegante y bien argumentada. ¿Qué más necesitas? Usted proporcionó una amplia evidencia de que los números se juegan trivialmente y por lo tanto son inútiles. ¿Qué más quieres que tu pregunta elegante y bien discutida?
S.Lott
Los desarrolladores necesitan haber intentado trabajar con encontrar y corregir errores en gran comprometen y pequeñas-commits escenarios para ver la differenc.e
No creo que recopilar la estadística sea perjudicial en sí mismo, pero usarlo para evaluar a los programadores sí lo sería. Nuestro VCS recopila esa información, junto con una miríada de otras estadísticas, y está disponible para todo el equipo, pero casi nunca la miramos. Entonces no, recopilar la estadística no es dañino.
MarkJ
No estoy debatiendo compromisos grandes contra pequeños aquí (personalmente soy un tipo de tipo de compromiso pequeño), simplemente presión externa para cambiar el tamaño del compromiso para falsificar una estadística (lo que nunca puede ser bueno). Lo ideal es buscar un lugar en el que pueda señalar a otros, para no tener que discutir yo mismo :)
Neil Mitchell
2
Creo que este cómic de Dilbert presenta el caso tan bien como cualquier cosa que haya visto.
Ebneter

Respuestas:

8

http://www.mit.edu/~hauser/Papers/Hauser-Katz%20Measure%2004-98.pdf

¿Es este el tipo de cosas que estás buscando? Hay miles de artículos "solo obtienes lo que mides" encontrados por Google.

S.Lott
fuente
1
Normalmente no votaría una respuesta básicamente solo de enlace + sin extracto, pero en este caso específico me parece bien, ya que "la respuesta" sería la pregunta en sí misma de todos modos.
o0 '.
6

Es una estadística divertida de medir, pero no es más útil que registrar la cantidad de horas que trabajó un desarrollador durante la semana.

Por un lado, no tiene en cuenta la calidad del código. Un desarrollador puede estar cometiendo continuamente mientras sigue arreglando errores en su código. Esto mostraría una gran cantidad de confirmaciones, en comparación con un desarrollador que confirma una porción de código terminado y pulido. No pensarías que el tipo con el mayor número de confirmaciones fue el mejor desarrollador.

Del mismo modo, alguien que se afloja y navega SO todo el día solo para comprometerse una vez al día tendría el mismo recuento de confirmaciones que el desarrollador dedicado que pasó todo el día codificando solo para realizar una confirmación final al final del día para mantener su código seguro.

Si tiene un sistema donde se cuentan las líneas de código comprometidas, el tipo que revisa los archivos fuente 'refactorizando' cada soporte rizado a su estilo preferido tendrá un gran valor. El tipo que hizo la corrección de errores sup-importante de 1 línea apenas aparecerá.

Por lo tanto, no tiene ninguna estadística significativa, incluso si los desarrolladores no juegan con el sistema. No debería proporcionarle nada más que un bonito gráfico. Sin embargo, a todos les gustan las estadísticas, así que diría que las conserven, pero no las usen para otra cosa que no sea diversión.

gbjbaanb
fuente
Si bien su opinión es interesante, la pregunta real parece ser "¿hay algún estudio ...?" que su respuesta no aborda.
Bryan Oakley
"número de líneas". Puede llevar varios días investigar un problema que eventualmente resultará en un parche de una sola línea.
55
Solo un cuento , pero clásico.
Escrito el
Estos "varios días" (o al menos varias horas) de investigación que resultan en una solución muy importante pero de una sola línea ocurren con bastante frecuencia en mi experiencia.
Johan