Peur de changer le code
[SOTA]
Souvent ce qui domine une équipe de développement, c’est la peur de changer le code.
Et avec raison. Ceux qui n’ont pas peur, c’est qu’ils manquent d’expérience. Ils n’ont pas encore vécu l’épreuve de remettre d’équerre une prod avec réunion de crise au C-level toutes les 2 heures.
Des histoires fantastiques à raconter dans 3 ou 5 ans, mais si navrantes et gênantes sur le moment.
Des bugs légendaires, qui persistent dans les mémoires longtemps après leur réparation.
Le risque de défaillance en production, on peut le décomposer en :
Probabilité : que l’une des ces 1,2 millions de lignes de code comporte une erreur, un défaut, qui mettra le système par terre.
Impact : le service au client, les données du client, le chiffre d’affaire du client, l’image de marque, la pression, l’effort d’analyser, contourner puis corriger tout ça… en changeant à nouveau le code.
Il y a un proverbe pour toutes les circonstances dans notre métier.
Le proverbe ici, la pépite de sagesse qui circule de génération en génération :
N’y Touche Plus, Ça Marche.
a.k.a “freeze”.
En décomposant l’impact, on trouve des coûts (tout finit par des coûts, donc des discussions de budget) : coûts des dommages, coût de correction.
En décomposant la probabilité, on trouve des éléments plus théoriques, et pour certaines équipes — celles qui ont peur, et à juste titre — des abstractions pures :
- nombre de comportements vérifiés du code (V)
- nombre total de comportements possibles du code (C)
Il existe bien d’autres composants, mais avec ce ratio, on disposerait déjà, si on avait le chiffre, d’une mesure très utile.
Pour couvrir ce risque, il existe une assurance dont le prix varie d’une équipe à l’autre. Pour certaines, c’est juste un “péage”, le coût minimal de la discipline qui consiste à écrire des vérifications du code lorsqu’on écrit du code. Pour d’autres, c’est le prix équivalent à une refonte du système.
- coût du contrat : aquisition du savoir-faire consistant à écrire des vérifications automatisées
- la prime : application systématique de cette pratique à l’ensemble du code que l’on écrit ou fait évoluer
Mais le surlendemain de l’accident, une fois la poussière retombée, les dégâts réparés, le client “géré”, face à ce coût, on fait quoi ?
On ne fait rien.
Il n’y a pas de moyen raisonnable de sécuriser ce code. Ça coûterait un bras et une jambe. Si tu continues d’insister ça va te coûter ton poste. On peut trouver — pour moins cher — des personnes moins concernées que toi par ce problème.
On continue. Parce qu’il est déjà trop tard. Donc on avance.
Et le problème grandit :
Nouvelles centaines de lignes de code — toutes fraîches du jour — qui augmentent le nombre de comportements non vérifiés du code.
Nouvelle probabilité de défauts, d’erreurs, qui croît non pas à mesure du nombre de lignes de code, mais à mesure d’une nombre d’interactions possibles entre des éléménts du code.
Le problème grandit…
Et l’on vit comme ça, jusqu’à la prochaine fois.
