Acheter du code de qualité, c'est choisir de ne pleurer qu'une seule fois

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.

Pourquoi achetons-nous sans cesse les mêmes T-shirts qui ne durent pas ? Pourquoi construisons-nous sans cesse les mêmes applications, elles aussi quasi jetables ? "La folie, c'est de faire toujours la même chose et de s'attendre à un résultat différent", disait A. Einstein. Serions-nous fous ?

Pas nécessairement : acheter un T-shirt à 20€, ou même 50€, c'est clairement plus d'argent à sortir maintenant. Autrement dit, c'est un problème de trésorerie. C'est le paradoxe de la pauvreté : payer moins cher dans l'instant condamne les individus à payer plus cher sur le long terme.

Le logiciel, c'est la même chose : vous trouverez sans difficulté des personnes prêtes à développer "à pas cher" l'application que vous avez en tête. Seulement, quand, ultérieurement, vous voudrez ajouter des fonctionnalités, vous découvrirez l'ampleur du désastre : le code est un enchevêtrement de dépendances indues, sans architecture apparente, sans modularité et bien sûr sans test. Ce phénomène de dette technique  est malheureusement chose courante.

Qu'il s'agisse de T-shirts ou de logiciels, le sujet est donc le même : il faut consentir à payer plus cher à t0, moyennant financement, pour y gagner à moyen terme. 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.

La plupart du temps, un décideur est sommé de payer plus cher sur base des dires d'un développeur qui lui certifie, en s'inspirant des langages hermétiques des Inconnus , 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." 

Le mieux, dites-vous ? Tout le monde veut le mieux, mais à quel prix ? À quel point est-ce mieux ? En quoi est-ce mieux ? Reconnaissons, à la décharge des décideurs, que le choix n'est pas évident dans ces conditions. L'informatique est immatérielle, pour ne pas dire invisible, en tout cas abstraite, donc difficile à appréhender .

Force est de reconnaître que nous, développeurs, ne faisons pas toujours l'effort d'expliquer notre travail, d'en rendre les enjeux compréhensibles par des personnes extérieures au métier. C'est ce que je m'emploie à faire chaque semaine au travers de cette newsletter. Mon message-clé est que l'informatique est un actif de l'entreprise, au même titre que d'autres actifs de production tels que des machines-outils.

En fait, les choses sont plus simples qu'il n'y paraît, car de bons développeurs savent avancer vite tout en posant des bases techniques saines et contrôler le niveau d'endettement technique (bien maîtrisée, la dette est une bonne chose). Avec l'expérience, programmer selon ces standards de qualité ne prend pas plus de temps.

Ce savoir-faire repose notamment sur des choix d'architecture qui laissent le maximum de portes ouvertes , n'obérant pas le futur. L'organisation du travail joue également un rôle prépondérant : la réalisation d'un Walking Skeleton , tôt sur le chemin qui mène au MVP, permettra de cadrer le travail des nouveaux développeurs, moins expérimentés, auxquels vous ferez appel pour soutenir l'effort de développement.

Bien sûr, 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 pas de miracle : accepter d'y mettre le prix suppose d'en percevoir la valeur.