Votre code est-il universalisable ?

Je viens d’une famille qui buvait les paroles d’un homme politique nommé René Dumont, dont le nom n’évoquera rien pour la plupart d’entre vous.
Ingénieur agronome, René Dumont parlait d’écologie à une époque où le mot n’avait pas cours. C’est-à-dire qu’il prêchait dans le désert. À l’élection présidentielle de 1974, sa candidature rassembla royalement 1,3 % des suffrages exprimés, avec des formules-chocs telles que « la voiture, ça pue, ça pollue et ça rend con »…
Ces valeurs, je les ai faites miennes, comme la radicalité.
Quel rapport avec la programmation et la qualité logicielle ?
Le rapport, c’est l’Universalisabilité kantienne : « Agis de telle sorte que la maxime de ton action puisse être érigée par ta volonté en une loi universelle ».
Ce seul principe est fondateur à la fois de l’écologie et de la qualité logicielle :
-
Prendre l’avion 4 fois l’an n’est clairement pas universalisable : si les 8 milliards d’êtres humains actuellement en vie faisaient ainsi, le réchauffement du climat serait tel que vous ne pourriez pas lire la fin de cette phrase. La question qui en découle est donc : pourquoi le faisons-nous, en dépit de toute rationalité ? (NDLR : à cause de la psychologie humaine, modélisée par le dilemme du prisonnier).
-
Écrire 600 lignes de code à la va-comme-je-te-pousse, sans test, en nommant les variables
toto,titiettata(eh oui, le nommage, c’est compliqué), en mêlant 95 responsabilités à cheval sur 3 contextes, cela n’est pas plus universalisable : si tous les développeurs travaillaient ainsi, il serait impossible de faire évoluer la moindre parcelle de code tant cela causerait de régressions. Ce code, autrement dit, serait du code jetable.
Ces deux domaines se rejoignent d’ailleurs dès que l’on parle de sobriété numérique, et plus spécifiquement d’éco-conception Web. En la matière, je recommande la lecture du référentiel des 115 bonnes pratiques élaboré par le collectif GreenIT. Il y aurait également beaucoup à dire sur l’optimisation des algorithmes, tant les implémentations naïves et gloutonnes sont courantes. Amis développeurs, par pitié penchez-vous sur la notation Big-O.
À dire vrai, j’évoque ce sujet pour mieux le laisser de côté. Car mon propos, avant cela, était bien de souligner les racines communes de l’écologie et de la qualité logicielle : une éthique et des valeurs communes. Si bien que l’on ne saurait imaginer un développeur produire un petit bijou de code, parfaitement architecturé, parfaitement lisible, parfaitement testé, et rouler en Hummer dans le même temps : ce serait irrationnel. La seule explication serait un défaut d’information. Mais vous conviendrez avec moi qu’en 2024, il n’est plus possible d’être naïf sur aucun de ces sujets.
D’ailleurs, le parallèle ne s’arrête pas là : la dette technique fait écho à la dette écologique (dans les deux cas, on reporte un coût sur les générations suivantes), de même que la notion d’externalité négative a cours dans les deux domaines (le mauvais code, comme la pollution, impose un coût à ceux qui ne l’ont pas produit), sans oublier la soutenabilité (sustainable pace de l’XP vs. développement durable).
Écologie et qualité logicielle reposent sur le même test : « et si tout le monde faisait comme moi ? » Un comportement qui échoue à ce test est un coût reporté sur les autres. Cela, nul ne peut l’ignorer.