De l'adoption de bonnes pratiques de développement en entreprise

Salut !

Aujourd’hui, on discutait sur le Discord de ZdS d’un sujet malheureusement trop fréquent, les préjugés à cause desquels les managers refusent que leur équipe adopte de bonnes pratiques de développement, et avec @Spacefox, on s’est dit qu’il serait peut-être temps que l’on rédige un article rigoureusement sourcé pour démonter ces préjugés une bonne fois pour toutes, en espérant que cela puisse aider à faire bouger les choses dans le bon sens.

Afin de préparer cet article, j’aimerais que nous prenions le temps pour discuter de vos expériences, et notamment que nous prenions le temps de cibler ce sujet le plus précisément possible.

• Avez-vous déjà été confronté à un manager qui refusait de laisser votre équipe adopter de bonnes pratiques de développemment (tests automatisés, TDD, intégration continue, code reviews, pair programming…) ?
• Pouvez-vous nous raconter le plus précisément possible les arguments et/ou préjugés qu’ils vous ont opposés pour cela ?

On pourra bien sûr discuter des raisons pour lesquels ce sont des préjugés et de la bonne façon pour leur montrer qu’ils se trompent, de préférence en utilisant des sources solides et variées, mais l’objectif de ce thread est déjà de déterminer ce à quoi un tel article doit répondre.

Par exemple, l’un des préjugés qui revient assez souvent est que l’on "n’a pas le temps" de mettre en place des tests automatisés ou une CI, ce qui revient à ignorer que c’est tout le contraire, puisque la littérature (Kent Beck et Robert C. Martin, typiquement) a déjà permis de montrer que ce temps investi dans la mise en place de tests ou d’une CI est négligeable devant celui perdu à réparer des régressions qui ne sont détectées qu’en production en raison de leur absence…

Bref, c’est à vous !

Alors c’est pas des excuses, mais cet article d’Opquast sur les coûts de non-qualité liste pas mal d’arguments pour justifier la mise en place de process qualité.

Pas toujours facile de les évaluer, mais ça peut aider à trouver des arguments pour motiver les réfractaires

Dans mon boulot actuel, c’est le temps, l’argument principal. Pour être précis, le temps « là tout de suite » : il y a des trucs urgents à faire de suite, donc la mise au propre peut attendre. Bien sûr, l’urgent sera remplacé par d’autres trucs urgent, et il faut donc des mois pour améliorer un peu les pratiques. À modérer : les modifs faites ont apportés de tels avantages (automatisations, reproductibilité) que dès que du temps se libère, les changements sont effectivement faits (et appréciés).

L’autre truc qui revient, c’est l’estimation des conséquences. Concrètement, on distribue des logiciels, sans signature, sans hash, sur un site en http. Nous n’avons aucune certitude que le logiciel envoyé et celui reçu par le client soit le même. Sauf qu’améliorer ça risque d’apporter des contraintes au client (à minima, aller chercher notre clé ou des trucs comme ça), donc c’est non. Les avantages les surpassent largement, mais risque client + prend du temps pour être bien fait = reporté ad vitam eternam.

Dans mon précédant travail, en labo…

• La question du responsable. Le responsable, mainteneur à longs termes du logiciel n’est pas forcément celui qui code. Typiquement, maintenance par le chercheur, code par les doctorants. Donc on impose au codeur le sous-ensemble connu du mainteneur. Qui s’est arrêté au Fortran 77, parce qu’il manque de temps pour se former. C’est un vrai exemple.
• Le contournement est plus rapide que la résolution des problèmes à cause d’un historique catastrophique. Le logiciel maison ne compile que sur une machine, on n’a aucune idée de la raison, car les connaissances ont été perdues en cours de route, donc on déplace le codeur sur la machine plutôt que de chercher à pouvoir compiler partout.

L’idée sous-jacente derrière ces deux exemples est que la dette technique ne concerne pas que les logiciels, mais aussi ses mainteneurs. « C’est trop compliqué » est la réponse type quand on demande des trucs propres. Et les faire soi-même n’est pas acceptable, parce que pas de transfert de connaissances possible.

Ça rejoint un point que je retrouve aussi dans mon travail actuel, même s’il n’est pas verbalisé explicitement : « on a toujours fait comme ça. » Pourquoi utilisé Git, un truc compliqué, quand on peut faire du cp.old ? On a toujours fait comme ça, et ça marche.

Si je ne compte que les arguments que j’ai déjà entendus dans ma vie professionnelle contre la mise en place d’outils ou procédures de développement ou associés.

En fait on peut les regrouper en un petit nombre de catégories d’arguments, mais c’est intéressant d’avoir les arguments exacts parce que ça donne une idée de comment attaquer le problème.

1. La rentabilité de la bonne pratique n’est pas imaginée, pas comprise, ou imaginée seulement à trop long terme. Je parle ici de rentabilité purement financière directe (achat de licences), en temps de développement, en confort de développement (et donc en équipes qui restent). Ces deux derniers points se traduisant aussi en pertes financières, mais cette traduction peut elle-même être mal comprise.
   • « On a pas le temps ». Ça c’est le classique, en général sur un projet où la pile de trucs à faire est excessivement plus grande que les ressources affectées au projet, et où donc tout est urgent, donc toute décision qui n’a pas une rentabilité immédiate est ignorée (avec les effets délétères que ça implique).
   • « C’est trop cher » (à peu près tout ce qui nécessite de payer une licence, aussi peu chère soit-elle).
   • « On a déjà essayé et ça n’a pas fonctionné ». Je le met ici, mais ça peut entrer dans les catégories 2 et 3 selon pourquoi ça n’a pas fonctionné : est-ce que la pratique a été correctement mise en place ? Est-ce que les équipes ont été formées ? Ont-elles été impliquées ? Est-ce qu’une rentabilité instantanée a été attendue ?
2. Le but des outils et méthodes n’est pas compris. Comme la bonne pratique n’a pas de but réel identifié, on ne peut pas en déduire la rentabilité associée.
   • « Ça ne sert à rien », qui se passe de commentaires.
   • « On a déjà [type de test A], donc on a pas besoin de [type de test B] ». En particulier, l’intérêt des tests unitaires est très mal compris par les personnes qui ne les ont jamais pratiqué.
   • « On a pas besoin de [outil], on a déjà [truc qui en fait n’a rien à voir ou totalement obsolète] ». Extrêmement pénible quand l’interlocuteur commence la réunion en t’expliquant pourquoi en fait tu n’as pas besoin, selon lui, de l’outil, alors qu’il ne sait visiblement pas à quoi ça sert.
3. La croyance que le projet ou les équipes ne sont pas adaptés à la bonne pratique. Le décideur reconnaît l’intérêt de l’outil ou de la méthode, mais part du principe que ça ne sera jamais applicable au projet ou à l’équipe. Ça rejoint un peu le point 1 (la rentabilité) mais avec des angles d’attaque très différents. Je fais rentrer la résistance au changement dans cette catégorie.
   • « La structure du projet ne nous permet pas d’intégrer cette idée », surtout invoqué sur les projets anciens avec une grosse dette technique, et ça peut être assez vrai – essayez de TU du code spaghetti pour voir.
   • « On a pas le temps de créer tous ces tests », qui vient souvent avec une croyance qu’il faut immédiatement créer une tétrachiée de tests à la mise en place du framework de test sur le projet préexistant.
   • « L’équipe n’est pas prête pour ça »… et c’est malheureusement parfois vrai.
   • « On a toujours fait comme ça et ça marche très bien », et son petit frère vicieux : « Mais regarde, ce qu’on fait est déjà beaucoup mieux qu’avant ».
   • Le cas très toxique de la personne qui bloque systématiquement toute modification qui fait qu’elle ne devient plus indispensable dans le processus (comme toutes les automatisations de tâches qu’elle faisait manuellement avant).
4. Les facteurs externes pas vraiment maîtrisés (ou que l’on imagine ne pas maitriser).
   • « Mais ça ne tournera jamais sur les machines de l’équipe en outsourcing ». Parce qu’une partie du projet est développée dans un pays pas cher, sur des brouettes qui parviennent à peine à lancer un IDE avec un seul écran en 1366x768, accédées via le bureau à distance de Windows pour le télétravail.
   • « Les équipes d’installation chez le client ne sauront pas faire », pour les changements qui auraient des impacts sur le livrable final.

Et oui, tous les exemples sont réels…

Je rajoute que plus on monte dans la hiérarchie, plus c’est fréquent que les personnes aient du mal à comprendre autre chose que la rentabilité immédiate en argent. Or les problématiques de dégâts d’image (interne et externe à l’entreprise) et de démotivation des équipes (avec le turn-over et la perte de compétences, etc qui va avec) ont aussi un cout financier qui peut être énorme.

Je pense que ça peut être intéressant d’appuyer ces aspects, et de sortir des études qui montrent ces couts financiers.

L’idée vient de me traverser l’esprit que si l’article se veut convaincant, alors il va aussi nous appartenir de donner les conditions réelles et parfaitement valables dans lesquelles l’adoption de telle pratique ou tel outil n’aura que peu de chances d’être rentable ou d’avoir un impact positif mesurable.

De mon côté, je me suis plutôt retrouvé confronté à des cas classiques.

• "On n’a pas le temps de bien faire, ça doit être fait pour la semaine prochaine" (puis à la release, on se retrouve avec une prod qui ne fonctionne pas, donc une grosse interruption a posteriori, où l’on doit corriger la prod à chaud pour éteindre le feu, puis implémenter la "bonne" solution, mais cette fois dans l’urgence et/ou en heures supplémentaires pour stabiliser la prod).
• "Le TDD est une perte de temps parce que cela revient à écrire deux fois plus de code" (sauf que taper du code sur un clavier n’est pas le goulot d’étranglement dans le processus de développement, et par ailleurs lorsque l’on récrit plusieurs fois le même code pour le corriger jusqu’à ce qu’il finisse par passer des tests manuels ou répondre au besoin des utilisateurs qui a évolué entre temps, c’est beaucoup plus du double de lignes du code final que l’on finit par taper). I' est possible de trouver dans la littérature des résultats qui montrent que le TDD ne se contente pas de nous faire économiser du temps sur le long terme, mais dès la première demi-heure.
• "Le pair programming utilise deux fois plus de ressources pour le même résultat final, donc c’est du gaspillage" : c’est bien souvent une erreur de calcul, car le pair programming consiste simplement à réaliser le code review au même moment que le code est écrit, et requiert tout autant de ressources que ce dernier, avec pour avantage que cela se fait sans générer d’interruptions ni d’allers-retours fastidieux entre devs (qui finissent d’ailleurs par se mettre à deux devant le code pour discuter plus rapidement et se mettre d’accord pendant la review). Le temps écoulé entre l’écriture de la première ligne et la fin de l’étape de développement est de ce fait divisé par deux. C’est aussi un moyen imparable d’augmenter le bus factor de l’équipe (le nombre de personnes dont le départ est synonyme de perte de connaissances), et de former les développeurs.

J’ai un exemple un peu particulier puisque cette objection contre la mise en place de tests m’a été adressée par un manager technique qui lui-même codait encore : « le client ne comprend pas tout ça, il s’en fiche de savoir qu’on a 90 % de code coverage. Il ne paiera pas plus cher pour ça. »

Certes, le client ne comprendra peut-être pas code coverage, mais je suis sûr qu’il comprend et sera heureux d’entendre que son produit est testé, nous permettant par là-même de lui offrir des garanties concrètes quant au risque que les mise à jour successives cassent des fonctionnalités indispensables, impliquant le chômage technique jusqu’à résolution. (« Résolution » = hot fix en prod)

J’ai un exemple un peu particulier puisque cette objection contre la mise en place de tests m’a été adressée par un manager technique qui lui-même codait encore : « le client ne comprend pas tout ça, il s’en fiche de savoir qu’on a 90 % de code coverage. Il ne paiera pas plus cher pour ça. »

Oui le client ne sait pas ce qu’est le coverage, pas plus qu’il ne sait ce qu’est un thread ou une gateway. Par contre le client sait ce que c’est qu’un bug ou une panne, et le coverage est un outil qui permet de contrôler, dans une certaine mesure, la fréquence à laquelle ceux-ci vont se produire sous ses yeux (idéalement on la veut nulle).

Sur le coverage je pense qu’il faut également que l’on mentionne que ce n’est pas un KPI. Écrire des tests juste pour "faire du coverage" est un énorme piège, et une perte de temps. C’est simplement un indicateur : s’il est inférieur à 90% alors les tests ne couvrent pas assez le code, donc il reste trop de zones d’ombre. S’il est supérieur ou égal à 90% (ou même égal à 100%), alors les tests couvrent suffisamment le code mais ça ne suffit pas encore pour avoir confiance.

Se cacher derrière l’ignorance du client pour ne pas mettre en place des process qualité c’est vache…

C’est pas parce que je sais pas comment un moteur de voiture fonctionne en détails que j’ai pas envie qu’il y ait des tests en amont pour qu’il explose pas en route.

Et puis surtout, c’est pas des détails qui sont à remonter au client.

Pour moi les seuls cas où le client a son mot à dire là-dedans, c’est :

1. En cas de normes qualité ISO-machin spécifiques, ou
2. S’il est directement impliqué dans le processus de développement (ça peut arriver avec certaines méthodes agiles)

Je pense qu’il est aussi bon de préciser que dans un monde idéal, le manager n’aurait pas son mot à dire sur ces pratiques.

Son boulot c’est de s’assurer que les fonctionnalités désirées (le quoi) sortent en temps et en heure, le comment ne devrait pas être son problème, mais le devenir si la qualité n’était pas au rendez-vous : c’est justement quelque chose qu’il devrait déléguer à l’équipe de dev, tant que le résultat est là.

Cependant, si on en est là aujourd’hui, c’est parce que certaines équipes de devs continuent à ressentir le besoin de demander la permission, pour plein de raisons possibles (absence de seniors, micromanagement, produit en difficulté — parfois, ironiquement, à cause de la dette technique —…).

Il me semble que ce serait pas mal, donc, de nuancer en disant que le but de l’article n’est pas non plus que le manager se mette à imposer toutes les bonnes pratiques qui seront mentionnées à son équipe, mais plutôt de rétablir une relation de collaboration saine et de confiance : c’est aussi aux équipes de dev de prendre ce pouvoir de décision qui est censé être le leur, particulièrement quand ils bossent selon une méthodologie Agile, et c’est aussi aux devs d’adopter les pratiques avec lesquelles ils sont à l’aise, pas forcément toutes, ni toutes à la fois.

Je pense que ça peut être intéressant d’appuyer ces aspects, et de sortir des études qui montrent ces couts financiers.

Je viens de tomber sur cet article récent qui cite en intro une estimation assez lourde : le développeur moyen perd entre 23 et 42% de son temps à cause de la dette technique. Puis il explique la même chose que toi (en général les boites ne se rendent pas compte de ce coût) et propose une méthode de calcul de la dette technique. Il me reste encore à le dépiauter mais ca semble une source prometteuse.

Edit: Hmm en fait c’est un article qui fait la promo d’un soft, les remarques sont intéressantes mais je vais plutôt creuser du côté de ses sources.