Je vois que nos points de vue se rejoignent :)

Pour moi les points ‘non-régression’ et ‘qualité logicielle’ vont être matérialisé par la mesure que j’ai proposé : en la mettant en place, on va pouvoir valider cette assertion ‘le code de bonne qualité permet d’être plus productif’, l’intérêt d’une mesure est que cela evite les guerres de chapelle et on peut se baser sur du concret.
De même, on va pouvoir introduire des outils et mesurer leur efficacité.

Et n’oublions pas un autre point important : introduire d’autres mesures et ne pas se focaliser sur une une seule. La satisfaction des développeurs est évidemment une mesure très pertinente qu’il faut aussi prendre en compte, tout comme la confiance des programmeurs dans le code produit et bien d’autres, à nous de trouver les plus pertinents pour avoir une vue d’ensemble.

Merci William pour ces précisions.

Benoit

Ces trois thèmes sont essentiels à l’amélioration du code même si du point de vue managérial, ils ne sont que difficilement chiffrable.

1) la formation au ‘génie logiciel’. Avec l’embauche de nombreux prestataires par des sociétés de services, la formation au ‘bon code’ (celui qui va améliorer la qualité du logiciel) n’est plus assurée correctement et bon nombre de programmeurs se satisfont d’un malheureux copier/coller. Combien de codes en sont truffés? Y compris en Java. Seules les équipes qui savent gèrer la qualité du code peuvent en améliorer la productivité.

2) la non-régression. Lorsque les tests automatiques n’étaient pas encore à la mode, on parlait de non-régression. En général, pour obtenir une bonne qualité de non régression, les tests ne suffisent pas (à moins qu’ils puissent tout couvrir), c’est pourquoi je pense intimement que la qualité du code influe directement sur la réussite des tests automatiques. Et même si vous désirez garder cet indicateur sur les tests, vous devriez passer les tests avec succès du premier coup. N’oublions pas qu’il s’agit de productivité: le but étant de coder rapidement sans créer de régression ni de bug.

3) La satisfaction du programmeur: avec un code lisible, facile à maintenir et des tests de non-régression; le programmeur peut passer plus de temps à la machine à café. Et c’est vrai. Pour cela, il faut remanier le code et beaucoup de programmeurs préférent bidouiller un truc pour aller plus vite plutôt que de tout ré-écrire correctement (y compris des bouts de code sans rapport direct avec la fonctionnalité). Cette politique a deux inconvénients: déception du programmeur qui doit bidouiller et mauvaise maintenabilité donc perte de temps dans un avenir plus ou moins proche (souvent lors de la recette du produit).

4) les outils de travail. Combien de programmeurs écrivent ou effectuent les mêmes travaux répétitifs alors qu’ils pourraient écrire un outil (une macro, un script) qui leur simplifierait la vie? Sur presque tous les projets, j’ai du écrire mes propres outils (du plus simple au plus compliqué). Une fois ces outils en place la productivité a également augmenté.

Enfin, il faut savoir investir: la productivité se paye en investissement. Vous devez investir pour produire mieux: outils, création de tests de automatiques, formation, règles de codage, gestionnaire de sources, etc. Tout cela a un coût qu’il faut savoir payer pour gagner du temps ensuite, un temps précieux. De plus en plus précieux alors que les échéances de mise en production approchent…