Pourquoi les statistiques de validation des développeurs sont-elles nuisibles?

10

J'ai longtemps cru (et entendu d'autres personnes) que le suivi des statistiques de validation, comme le nombre de validations par développeur chaque jour, est nuisible au processus de développement. La raison semble évidente - les développeurs s'engageront par petits incréments, maximisant leur nombre de validations par jour, mais rendant plus difficile la bissectrice (peut-être que tous leurs correctifs intermédiaires ne laisseront pas le dépôt bien formé) et plus difficile de travailler avec l'historique des validations (un changement se produira soudainement en plusieurs validations, au lieu d'une seule, annuler un patch est plus difficile, etc.).

Existe-t-il des études montrant que les statistiques de validation sont nuisibles? Un article élégant et argumenté sur le sujet? Tout aussi applicable serait de savoir pourquoi mesurer la mauvaise chose conduit les gens à l'optimiser, ce dont ce problème n'est qu'un cas particulier.

Neil Mitchell
la source
8
"Tout article élégant et argumenté" ?? Votre question est élégante et bien argumentée. De quoi d'autre avez-vous besoin? Vous avez fourni de nombreuses preuves que les chiffres sont triviaux et donc inutiles. Que voulez-vous de plus que votre question élégante et argumentée?
S.Lott
Les développeurs doivent avoir essayé de trouver et de corriger les bogues dans les scénarios à grande et à petite validation pour voir la différence.e
Je ne pense pas que la collecte des statistiques soit nuisible en soi, mais l'utiliser pour évaluer les programmeurs le serait. Notre VCS rassemble ces informations, ainsi qu'une myriade de statistiques, si elles sont disponibles pour toute l'équipe, mais nous ne les consultons presque jamais. Donc non, la collecte des statistiques n'est pas nuisible.
MarkJ
Je ne discute pas ici des gros et petits commits (je suis personnellement un petit type de commit), simplement de la pression externe pour changer la taille du commit pour truquer une statistique (ce qui ne peut jamais être bon). Je cherche idéalement un endroit où je peux pointer les autres, donc je n'ai pas à argumenter moi-même :)
Neil Mitchell
2
Je crois que cette bande dessinée de Dilbert fait l'affaire ainsi que tout ce que j'ai jamais vu.
Ebneter

Réponses:

8

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

Est-ce le genre de chose que vous recherchez? Google propose des milliers d'articles "vous n'obtenez que ce que vous mesurez".

S.Lott
la source
1
Normalement, je ne voterais pas pour une réponse essentiellement liée uniquement à un lien + sans extrait, mais dans ce cas spécifique, je la trouve correcte, car «la réponse» serait de toute façon la question elle-même.
o0 '.
6

C'est une statistique amusante à mesurer, mais pas plus utile que d'enregistrer le nombre d'heures qu'un développeur a travaillé au cours de la semaine.

D'une part, il ne prend pas en compte la qualité du code. Un développeur peut s'engager continuellement alors qu'il continue de corriger les bogues dans son code. Cela afficherait un grand nombre de validations, par rapport à un développeur qui valide un morceau de code fini et poli. Vous ne penseriez pas que le gars avec le plus grand nombre de commit était le meilleur développeur.

De même, quelqu'un qui se relâche et surfe SO toute la journée uniquement pour valider une fois par jour aurait le même nombre de validations que le développeur dédié qui a passé toute la journée à coder pour effectuer une validation finale à la fin de la journée pour garder son code en sécurité.

Si vous avez un système où les lignes de code validées sont comptées, le gars qui passe par les fichiers source en «refactorisant» chaque parenthèse bouclée à son style préféré aura une valeur énorme. Le gars qui a fait le correctif de bogue sup-important sur une ligne apparaîtra à peine.

Donc, cela ne fait aucune statistique significative même si les développeurs ne jouent pas au système. Il ne devrait vous fournir rien d'autre qu'un joli graphique. Cependant, tout le monde aime les statistiques, donc je dirais de les garder, mais ne les utilisez pas pour autre chose que du plaisir.

gbjbaanb
la source
Bien que votre opinion soit intéressante, la vraie question semble être "y a-t-il des études ...?" que votre réponse ne traite pas.
Bryan Oakley
"nombre de lignes". Cela peut prendre plusieurs jours pour rechercher un problème qui entraînera éventuellement un patch sur une seule ligne.
5
juste un conte , mais un classique.
Wrikken
Ce "plusieurs jours" (ou au moins plusieurs heures) de recherche aboutissant à un correctif très important mais sur une seule ligne se produit assez souvent dans mon expérience.
Johan