Le meilleur marché est le plus cher (proverbe belge)

[Rediffusion d'un article originellement publié le 9 novembre 2022]

Quand on parle de qualité logicielle, c'est une évidence, mais apparemment il est des évidences qui gagnent à être répétées.

👉 Une newsletter avec de la polémique dedans, et quelques références cinématographiques.

C'est comme n'importe quel produit de la vie courante : achetez un T-shirt à 3€. Au premier lavage, il perd sa couleur, au deuxième il perd sa forme, au troisième vous pouvez le jeter. Donc vous achetez un deuxième T-shirt à 3€ et la même histoire se répète.

"La folie, c'est de faire toujours la même chose et de s'attendre à un résultat différent"
— A. Einstein.

Alors… serions-nous tous fous ?

Pas nécessairement, car oui le meilleur marché est le plus cher, mais cela s'entend sur le long terme.

Acheter un T-shirt à 20€, ou même 50€, c'est clairement plus d'argent à sortir maintenant. Autrement dit, cela peut être un problème de trésorerie.

Qui dit trésorerie dit financement. Il faut donc convaincre les décideurs que sur le long terme, ils seront gagnants.

Et là, c'est un problème d'éducation, de connaissance du code et de l'informatique. Autant quand vous comparez un T-shirt à 3€ et un autre à 50€, il y a des chances que la différence de qualité vous saute aux yeux, autant le code est invisible.

Cela veut dire que nos chers décideurs doivent accepter de payer plus cher sur base des dires d'un développeur qui lui certifie que :

"Si si, non mais là on fait les choses bien, prog fonctionnelle, TDD, BDD, DDD, tout le tralalala, tests d'API, tests e2e, CI/CD, le tout en monorepo, parce que c'est mieux, M. Gentil. Et puis on bosse en pair-programming, et sur certaines décisions un peu structurantes on passe en mob. C'est sûr c'est plus cher, mais c'est ce qu'il y a de mieux."

Source : les langages hermétiques.

Le mieux, dites-vous ? Tout le monde veut le meilleur, mais à quel prix ? En quoi est-ce mieux ? À quel point est-ce mieux ?

Reconnaissons donc, à la décharge de nos chers décideurs, que le choix n'est pas évident dans ces conditions.

Heureusement, les choses sont plus simples qu'il n'y paraît, car avec l'expérience, programmer selon ces standards de qualité ne prend pas plus de temps :

• Travailler en pair-programming c'est certes 2 personnes autour d'1 seul clavier, mais le code produit est de bien meilleure qualité. En pair-programming, on se surpasse, on se soutient, on confronte nos idées, on rebondit sur celles de l'autre. Seul… on va faire un tour sur l'Equipe. Je n'ai rien contre l'Equipe, vous m'avez compris.

• Faire du Test-driven development, c'est produire du code sans erreur, simple, 100% refactorable, documenté. Clairement, aujourd'hui je ne sais plus faire autrement qu'en TDD quand je m'attaque au domaine d'une application.

On pourrait multiplier les exemples.

Là où c'est moins vrai, c'est que ces compétences se payent :

"J'ai mis 10 ans pour être capable de faire ça en 10 minutes.
Payez-moi les 10 ans, pas les 10 minutes".

Vous connaissez.

Il n'y a donc pas de miracle : accepter d'y mettre le prix suppose d'en percevoir la valeur. Rares sont les managers qui la perçoivent. Question d'expérience, probablement 😝