Existe-t-il des utilisations valides connues du SLOC pour mesurer la productivité?

J'ai eu une conversation inhabituelle et brève avec un architecte de très haut niveau sur les langages dynamiques et statiques. Il a déclaré que les données des entreprises montrent qu'il existe des preuves d'une productivité accrue lorsque des langages statiques sont utilisés. Notez, c'est une grande entreprise avec une longue histoire. À ma grande surprise (et d'autres), la métrique qu'il a utilisée était l'ajout de lignes de code.

Il a rapidement écarté les objections concernant la métrique, affirmant qu'au sein d'une même entreprise, avec une culture, un secteur d'activité et des données suffisantes, les différences (en ce qui concerne les situations uniques et les capacités des individus) se confondaient suffisamment pour que la métrique SLOC soit utile pour comparer la productivité des entreprises. outils et langages.

Bien que je ne pense pas que cette affirmation soit étayée par une analyse statistique rigoureuse, existe-t-il des preuves dans le secteur qui seraient en faveur de cette ligne de pensée?

L'argument de l'architecte principal pourrait signifier deux choses.

1. Cela peut signifier qu'un développeur moyen de l'entreprise produit plus de lignes de code lors de l'utilisation de langages statiques que lors de l'utilisation de langages dynamiques. Par exemple, si quinze développeurs travaillent avec Java pendant six mois, ils écriront 100 KLOC et si ces mêmes quinze développeurs travaillent avec Python pendant six mois, ils n'écriront que 50 KLOC.

   Il n'y a pas de corrélation entre LOC et productivité ici. Et si il fallait quatre fois plus de lignes de code en Java pour produire la même fonctionnalité qu'en Python? Si cela est vrai, l'utilisation de Python entraînerait une productivité deux fois plus grande, en fonction des mesures KLOC ci-dessus.

2. Il peut également signifier qu'un développeur moyen de l'entreprise produit moins de lignes de code lorsqu'il utilise des langages statiques que lorsqu'il utilise des langages dynamiques: quinze développeurs écriraient en six mois 100 KLOC en Java ou 200 KLOC en Python.

   Même si moins de lignes de code est généralement préférable (moins de code à écrire, à lire et à maintenir), il est encore difficile de savoir combien de fonctionnalités les développeurs Java ont produites par rapport à celles de Python. Peut-être ont-ils écrit des demi-lignes de code par rapport aux développeurs Python, mais ont également produit la moitié du nombre de fonctionnalités?

Dans les deux cas, LOC n'est pas une métrique précieuse, car une même fonctionnalité ne serait pas traduite dans le même nombre de lignes de code dans différentes langues . Certaines langues ont tendance à être plus verbeuses; d'autres, plus compacts. Bien que, dans certains cas, la compacité soit précieuse, il n’ya pas de règle générale pour cela. Un exemple extrême serait le langage Brainfuck qui est extrêmement compact, mais qui n’est pas populaire pour sa lisibilité. Comparer des langages similaires peut être délicat: par exemple, lorsqu'il s'agit d'accolades, Java suit le style K & R, tandis qu'en C #, l'accolade ouvrante est sur sa propre ligne dans la plupart des cas lorsqu'elle suit le style officiel, ce qui conduit à une augmentation des LDC pour C #. Et que se passe-t-il quand on compare un langage procédural avec un langage orienté objet ou avec un langage fonctionnel?

Au lieu d'utiliser une métrique sujette aux erreurs, l'architecte principal pourrait s'appuyer sur un groupe de métriques qui mesurent la productivité lorsqu'elles sont utilisées ensemble: le nombre de fonctionnalités développées par mois, le nombre de bogues introduits dans la base de code et le temps passé à résoudre ces bogues. , l’évolution de la dette technique, etc. Cette comparaison risque d’être délicate au début, car il faut tenir compte de la méconnaissance de l’équipe avec le nouveau langage. Une fois que l’équipe s’y familiarisera suffisamment, le choix devra être basé sur les métriques stables, ainsi que sur la préférence des membres de l’équipe eux-mêmes.

LOC a une valeur dans certaines situations étroites. Par exemple, cela pourrait donner un indice sur la taille du projet et des parties du projet (et correspond en moyenne à des points de fonction, tout en étant souvent plus facile à mesurer), ou pourrait indiquer les méthodes et les classes qui pourraient nécessiter une plus grande attention, de leur grande taille. Cependant, LOC doit être utilisé avec précaution, car il est trop souvent mal utilisé par les personnes qui imaginent une corrélation entre des choses non liées. L’utilisation la plus désastreuse des lettres de crédit était jadis la tentative de mesurer la productivité d’un développeur en fonction des lettres de crédit écrites chaque mois.

A propos de la productivité et du SLOC

Le problème avec le SLOC

Le problème avec la métrique SLOC est qu’elle mesure une approximation de la quantité de code écrite, sans prendre en compte:

• la qualité du code (c'est-à-dire si, pour 100 SLOC, vous devez en ajouter 90 de plus à cause de bugs, mais que vous ne savez pas pour le moment que votre code est livré?)
• les objectifs atteints avec le code (par exemple, le SLK 10K gère-t-il tous les cas d'utilisation ou histoires d'utilisateurs attendus? ou seulement un sous-ensemble minuscule?)
• la maintenabilité du code (c.-à-d. devrez-vous ajouter 1% ou 50% de code supplémentaire pour adapter le code aux exigences évolutives attendues?).

Autrement dit, la production de code spaghetti incertain et incontrôlable avec de nombreuses pièces copiées-collées sera considérée comme plus productive que le code réutilisable élaboré avec soin.

Le SLOC n’est donc définitivement pas le meilleur moyen de mesurer la productivité.

Quelle productivité envisageons-nous?

La productivité est mesurée pour un processus. Le SLOC pourrait donc être un indicateur parfaitement valable pour le processus de codage seul.

Si, par exemple, vous comprenez mal les exigences peu élevées, passez cinq mois à produire le logiciel, montrez-le à l'utilisateur, découvrez qu'il est tout à fait faux et passez encore cinq mois à le réécrire pour de bon, vous obtiendrez la même productivité dans SLOC. / mois, qu’une équipe écrivant le code correctement dès la première fois, par exemple parce qu’elle a utilisé un processus agile qui réduit les malentendus grâce à des retours fréquents. Cette productivité apparente égale cache d’énormes problèmes.

Ainsi, la productivité du développement logiciel doit prendre en compte l’ensemble du processus, y compris l’analyse des exigences, la conception des éléments à coder, le codage, les tests, le débogage et la vérification du respect des attentes de l’utilisateur. Comme toutes ces activités sont très différentes, la meilleure chose à faire est de mesurer le seul facteur qui compte: un logiciel fonctionnel, c’est-à-dire ce que le logiciel produit signifie pour l’utilisateur .

Comment mesurer les livrables logiciels?

Plusieurs approches existent:

• L'approche typique en génie logiciel classique est la fonction des points de fonction (FP). Les points de fonction sont mesurés en fonction des exigences à remplir (nombre de formulaires, nombre de champs dans chaque formulaire, etc.). La productivité est ensuite mesurée en PF par unité de temps et par personne. Certaines entreprises disposent même de données indiquant le nombre de points de fonction qu'un développeur peut produire par unité de temps dans une langue donnée pour un domaine donné. Le problème avec la PF est qu’elle nécessite d’abord des exigences très détaillées et prend beaucoup de temps.
• Une approche plus moderne et pragmatique est Story Point (SP). Ceux-ci sont utilisés pour évaluer la complexité du code à produire et sont couramment utilisés pour évaluer la vitesse des équipes de développement. Cependant, SP est une mesure d'estimation du travail effectué avant que tous les détails ne soient connus. Ce n'est pas une mesure finale de ce qui s'est réellement passé. Il faut donc faire preuve de prudence lors de son utilisation en tant que mesure de la productivité, car cela pourrait se retourner contre le processus d’estimation .

À propos de la productivité du typage statique et dynamique

Je dois avouer que je suis personnellement un fan des langages à typage statique, car je sais au fond de moi que c'est plus fiable (des années de codage m'ont prouvé cela).

Donc, une chose que je suis sûr de faire est que le langage à typage statique est capable d’éviter beaucoup plus d’erreurs / bogues au moment de la compilation (par exemple, des fautes de frappe, des différences dans les types attendus, etc.) par rapport aux langages à typage non statique. Mais en toute objectivité, je n'oserais pas généraliser abusivement ceci comme une productivité plus élevée.

Votre architecte a-t-il raison?

Peut-être peut-être pas.

Mais ses arguments ne semblent pas valables: le gain de productivité d’un langage à typage statique provient d’un nombre important d’erreurs que le compilateur a rattrapées d’emblée.

Par conséquent, il n'est pas possible de découvrir ce gain de productivité "plus élevé" en examinant uniquement le SLOC sans examiner les retouches nécessaires pour les langages à typage dynamique. Donc, sa comparaison ne peut pas être juste.

L'argument des circonstances comparables ne tient pas non plus. Certains langages à typage dynamique autorisent certaines constructions de niveau supérieur nécessitant moins de code que la même chose dans l’un des langages classiques à typage statique. Vous pourriez donc avoir besoin de moins de temps, écrire moins de code, mais ajouter les mêmes coûts d'analyse, de test et de vérification. Donc, mesurer la productivité par le SLOC diluerait les gains de productivité potentiels, créant ainsi un biais contre un langage typé dynamiquement.

Toute étude pour soutenir cette revendication?

Plusieurs études académiques récentes existent sur le sujet. Bien que certains d’entre eux voient un avantage au typage statique, celui-ci est généralement limité à un objectif spécifique (documentation, réutilisation de code ou d’API mal documenté, etc.). Une formulation prudente est également utilisée car les IDE modernes ont considérablement réduit les risques liés au typage dynamique:

• Comparaison empirique de systèmes de types statiques et dynamiques sur l'utilisation d'API en présence d'un IDE: Java vs groovy avec eclipse , 2014
• Prise en compte des effets sur la productivité des déclarations de type explicites , 2014, mais non concluants
• Une étude empirique de l'influence des systèmes de types statiques sur la facilité d'utilisation de logiciels non documentés

Voici un contre-exemple pour votre architecte principal: Supposons que je veuille écrire une hiérarchie de trois classes, dont deux dérivent de la troisième, implémentant certaines fonctions virtuelles définies par la classe de base.

Si j'écris ces trois classes en C ++, c'est assez simple. Je déclare les classes, utilise virtuel aux bons endroits, et je le fais.

Si j'écris ces trois classes en C, je devrai ajouter un peu de code: je dois définir structs pour les v-tables, je dois ajouter un pointeur de v-table à la classe de base, je dois ajouter Code aux constructeurs pour définir réellement les pointeurs v-table, je dois ajouter du code aux constructeurs pour appeler en réalité le constructeur de la classe de base, je dois ajouter du code pour effectuer une allocation de mémoire de manière explicite avant d'appeler un constructeur (ce que C ++ newfait en une seule étape ), de même, je dois séparer la destruction de l' free()appel suivant, etc., etc.

Le fait est que toutes ces choses supplémentaires sont plutôt stupides. Je peux les faire très vite. Donc, l'écriture de la version C ne prendra pas beaucoup plus de temps que celle dont j'ai besoin pour écrire la version C ++. Néanmoins, j'ai produit beaucoup plus de lignes de code C que de code C ++. À tel point que je semblerais avoir été plus productif en C en termes de SLOC.

Toute langue nécessitant une certaine quantité de code passe-partout apparaîtra plus productive en termes de SLOC qu'une langue ne nécessitant pas la même quantité de code passe-partout.

Vous voyez, l'argument du SLOC est tellement fondamentalement imparfait que je le verrais en fait l'inverse: je prendrais l'énoncé suivant: "les programmeurs ont tendance à produire plus de SLOC dans des langages statiques": "les langages statiques semblent exiger davantage code passe-partout, et donc réduire la productivité ".

Je serai le contrarian.

Nous suivons SLoC dans notre travail (bien que nous ne l'utilisions pas directement dans les décisions de dotation), et des personnes ont déjà contesté ce que la plupart des gens ont dit dans leurs réponses. En effet, "La LoC n'a pas d'importance parce que la technologie X nous permet de faire plus avec moins de code" ou "Les meilleurs développeurs écrivent un code plus court et de meilleure qualité, de sorte qu'ils n'écrivent pas plus que quiconque". D'après mon expérience (même si je n'ai pas de chiffres précis à l'appui), ces objections ne sont tout simplement pas correctes. À mon époque, nous avons constaté une nette corrélation entre le taux et la qualité de la production de code pour nos développeurs, par rapport à toutes les autres mesures significatives de leur "compétence" globale en tant qu'ingénieur. Pour donner quelques contre-exemples aux sortes d'arguments avancés ci-dessus:

1. Oui, certaines langues peuvent faire plus avec moins de code. En fait, nous avons construit un cadre complet qui "automatise" de grandes parties du développement pour nos problèmes métier particuliers (back-end uniquement). Le résultat de tout cela n'est pas que les gens écrivent moins de code, mais simplement que nous avons plus de temps pour écrire du code. En conséquence, dans notre entreprise, le taux global d’écriture de code est relativement constant d’une technologie à l’autre et dépend principalement du niveau de compétence de l’ingénieur.
2. L'idée selon laquelle un meilleur développeur produira moins de code parce qu'il écrit plus intelligemment n'est absolument pas vraie. Oui, un programme mieux conçu peut prendre moins de lignes de code. Cependant, j’ai personnellement constaté que les «meilleurs» développeurs écrivant du code plus efficace ne tardent pas à le planifier plus rapidement qu’un développeur plus junior qui écrit sur le long terme. En conséquence, les développeurs les plus expérimentés exécuteront leurs tâches de codage plus rapidement et écriront un code différent avec le même taux élevé.

Cette dernière partie est mon résumé général, BTW. Ce que j’ai constaté, c’est que, quels que soient la technologie et le type de projet, la plupart des développeurs ont leur propre rythme, qui est celui auquel ils opèrent. Si un langage comporte de nombreuses fonctionnalités qui rendent le code plus efficace pour les développeurs, cela représente un avantage considérable pour les entreprises, mais cela ne signifie pas qu'elles rédigeront moins de code. Au lieu de cela, ils obtiennent des fonctionnalités plus rapidement et passent rapidement au nouveau code. Là encore, le résultat final est qu’ils évaluent le code auquel ils codent dépend principalement de leurs compétences et moins de leur pile technologique. En fait, à cause de cela, je m'attendrais généralement à ce que la pile technologique fasse plus de différence en ce qui concerne le taux de développement des billets et des fonctionnalités que celui des codes.

Cela étant dit, ni le taux de rédaction des codes ni le taux de clôture des tickets ne constituent une mesure parfaite de la productivité. C'est pourquoi nous ne prenons pas directement de décisions de dotation sur la base de SLoC. Au lieu de cela, cela fait partie du processus et les évaluations des employés sont effectuées en utilisant autant de points de données que possible. Je dirais cependant que votre architecte n'est certainement pas fou.

Une exception

La seule exception avec laquelle je suis d’accord est la possibilité d’un code de plaque chauffante S'il y a beaucoup de copier-coller d'une classe (ou autre) à une autre pour la rendre opérationnelle, cela va évidemment fausser les métriques. Cela est également vrai si vous avez des outils capables de générer automatiquement de grandes quantités de code pour vous. Cependant, je pense que ce sera souvent l'exception plutôt que la règle. Si vos développeurs passent du temps à copier le code de la plaque de chaudière pour commencer, vous utilisez le mauvais ensemble de technologies. S'ils écrivent le code, même s'il est assez répétitif, je m'attends à ce que cela ne biaise que peu les mesures: lors de l'écriture du code, nous sommes généralement limités par la rapidité avec laquelle nous pouvons résoudre le problème. que la vitesse à laquelle nous pouvons taper. Même en écrivant du code relativement répétitif,

Évidemment, tout ce qui précède est basé sur ma propre expérience personnelle. Votre kilométrage peut varier et je suis évidemment minoritaire. N'hésitez pas à être en désaccord. En résumé cependant:

Je trouve que le taux de codage dépend plus de la rapidité avec laquelle vous pouvez résoudre vos problèmes, plus que d’autre chose. En conséquence, j’ai constaté que le taux de codage est une mesure décente de la productivité, même dans l’ensemble des technologies, à quelques exceptions près.

Bien que je saute dans le train en marche. Je pense que l'impact sur le comportement des programmeurs doit être souligné.

L'utilisation du SLOC comme mesure de la productivité a un effet toxique sur le moral du programmeur. Au moment où un ingénieur de votre équipe / entreprise réalise qu'il est mesuré sur le SLOC, plusieurs choses se passent:

1. Ils commencent à écrire du code beaucoup plus long pour faire la même chose
2. ils se soucient moins de la qualité de leur code
3. ils cesseront de faire d'autres choses qui aident votre équipe (recrutement, débogage, aide aux juniors)
4. ils détesteront leur travail et partiront probablement

Je ne saurais trop insister sur le fait que le moral du personnel est corrosif, comme je l'ai déjà vu se produire deux fois dans deux entreprises différentes. Quels que soient vos cas d'utilisation apparemment valables, je soutiens qu'il est peu probable que l'impact sur votre équipe / votre entreprise en vaille la peine, même s'il n'y a que très peu de chances que son utilisation soit découverte. Même s'il existe dans certains cas une corrélation entre le nombre de lignes écrites et le nombre de fonctionnalités utiles, cela encourage tous les mauvais comportements de vos programmeurs et envoie le message que la qualité n'est pas importante.

Ce n'est généralement pas considéré comme un moyen valable de mesurer la productivité. Un code plus petit est généralement préférable à un code plus volumineux. Ainsi, un développeur plus productif produit généralement moins de code. La productivité prend son plus grand succès en débogage; Les développeurs efficaces passent peu de temps à déboguer.

Les langages statiquement typés sont plus productifs (si vous contrôlez toutes les autres différences entre les langages), car utilisés judicieusement, ils réduisent le temps de débogage, en rattrapant les erreurs en phase de compilation, où elles sont plus rapides à corriger.

La seule mesure que vous pouvez utiliser pour comparer la productivité des développeurs entre les langues est une mesure qui ne compare pas le code entre les langues. Certaines langues sont notoirement verbeuses (COBOL pour la victoire héritée), et d'autres nécessitent plusieurs étapes pour faire quelque chose que vous pouvez faire dans une seule ligne de code (assembleur par rapport à à peu près tout le reste). Même si vous ne comparez que les lignes de code actives (en d'autres termes, ne comptez pas les déclarations et ne comptez que le code comportant des actions), vous pouvez toujours biaiser vos résultats.

Vous pourrez peut-être faire valoir un argument en faveur des taux de changement. C'est-à-dire des lignes de code ajoutées, comparant la pente de productivité sur la même période. Toutefois, cela ne prend pas en compte les modifications négatives des lignes de code. Par exemple, vous héritez d'un projet comportant un copier-coller de code partout. Vous effectuez quelques refactorisations rapides et faciles pour réduire le nombre de blocs de code répétés - par définition, vous avez une pente négative.

Plus sérieusement, comparer la productivité des équipes / des langues n'a pas de sens, car de nombreux facteurs supplémentaires affectant la productivité d'une équipe ne permettent pas de tirer des conclusions significatives.

J'ai travaillé sur un projet où l'infrastructure était très fragile et les outils obsolètes. Le projet a été construit sur Java avec une application de page unique, mais hébergé dans un conteneur de portlets sans aucun avantage apparent. Le temps qu'il a fallu pour effectuer des changements, même simples, était ridiculement long. Si vous basiez toutes vos conclusions sur ce projet particulier, vous pourriez en conclure que Java était mauvais ou que les applications à une seule page étaient mauvaises. Ni sont vrais. Le système que le vilain projet était censé remplacer a été construit sur C # et WebForms. Lorsque nous avons analysé la rentabilité de l'extension de l'application existante pour répondre aux besoins des clients, notre productivité a explosé. Cela signifie-t-il qu'une application WebForms étroitement couplée est supérieure? Vous ne pouvez tirer cette conclusion que dans ce cas particulieret cela ne s'étend pas au monde entier. Et cela n'a de sens que parce qu'il y avait une application existante avec une maturité suffisante pour s'étendre.

Même comparer les taux de résolution des problèmes dans le système de suivi des problèmes est erroné, en ce sens que vous comparez des infrastructures de projet complètes les unes aux autres. Les bibliothèques et les cadres utilisés peuvent soit accélérer, soit ralentir les progrès. Vous êtes peut-être en phase de démarrage avec très peu d'inertie à surmonter, alors que le projet pour lequel vous êtes "meilleur que" se trouve dans une phase de maintenance où le nombre de nouveaux tickets est relativement faible. Il ne s'agit jamais de comparer des choses semblables.