L’entropie est une notion sympathique. Il y en a partout, puisque la nature a horreur du vide. C’est donc tout naturellement qu’on en trouve plein la boîte crânienne des architectes, qui manquent systématiquement une occasion de se taire. Petit cas concret.

Un logiciel a été commandé par le client, il va falloir le développer. Ce logiciel fera plein de choses magiques et intéressantes. La révolution est en marche, la singularité à portée de vue. Parmi toutes les activités de ce logiciel, il est en une particulièrement épineuse. Il va remplir des traces dans un format cryptique, par exemple les résultats de son auto-analyse. Oui, les logiciels fiables savent dire si tout se barre en sucette et qu’ils doivent être remplacés par la nouvelle génération. Sac-à-papier ! il va également falloir fournir un analyseur de traces alors ? Ça se complique méchamment.

Hé ! oui, ça se complique : ce n’est plus un logiciel qu’il faut fournir, mais deux. Et puis surtout, il va falloir trouver un moyen pour forcer le pinpin qui devra se servir de tout ça à utiliser l’analyseur de traces qui correspond au logiciel qui tourne. Imaginez, s’il cherche à lire les traces produites par la version B avec l’analyseur de la version A, ou le contraire … Il risque de détecter des erreurs qui n’en sont pas, nous pourrir en réunion, et on passera trop de temps à chercher des problèmes qui n’en sont pas. Non, vraiment, il faut garantir que l’analyse des traces soit consistante.

Aujourd’hui, c’est jour de chance. L’architecte a déjà pensé à tout. On va introduire des numéros de version dans les binaires, et modifier l’analyseur pour que la première chose qu’il fasse soit de comparer son numéro de version avec celle du logiciel qui a produit les traces, comme ça, ni une, ni deux, si c’est pas pareil, il refuse de travailler, et fini les soucis. À cette fascinante idée j’opposerai deux arguments :

1. Un bon numéro de version doit être unique. Il devrait donc être généré automagiquement, sinon il risque de mal vieillir. Et non, il ne faut pas juste un nouveau numéro à chaque livraison, mais bien à chaque production, sinon je ne sais pas trop comment les testeurs peuvent travailler. Ah ! tiens : subtilement, ce que l’on imaginait comme une activité pour le gestionnaire de configuration vient de vous échoir, là, pour vous, intégrateur ;
2. Est-ce que le client va vraiment se contenter d’un analyseur de traces muet ? Je suis d’accord, mieux vaut se taire que de dire n’importe quoi (non, même là, il n’a pas compris), mais pour autant on ne rend pas plus service. Pire, du point de vue du client, on ne respecte pas le contrat : on devait faire une analyse qu’on ne conduit pas de toute évidence avec notre outil muet.

Au final, j’ai proposé une solution alternative : et si on s’assurait plutôt de la rétrocompatibilité des traces ? C’est-à-dire que les traces de la version B n’auraient pas rien à voir avec les traces de la version A, mais seraient un sur-ensemble ? Et le tout stocké dans un format ultra-novateur, du genre (identifiant, valeur) ? Au pire, si l’identifiant est inconnu de l’analyseur, il afficherait la donnée binaire brute, histoire de mettre la puce à l’oreille.

Allez comprendre pourquoi, cette solution trop simple a déplu. Je m’en fiche, je n’assure pas le S.A.V., bonne chance à eux.