Nos procédés heuristiques, tout ce que nous trouvons dans nos livres, nos blogs et nos videos, dans nos conversations, ceux que nous essayés une fois ou deux comme ceux que nous utilisons depuis des années avec succès ; tous ces procédés sont aussi fiables et sûrs que peut l’être un procédé heuristique : une approche supposée produire dans les meilleurs délais la réponse à un problème donné, possiblement contredite par d’autres approches, et sans garantie de résultat.

Si vous contribuez de près ou de loin à un développement de logiciel, ce constat relativiste vous rendra peut être chagrin. Et si vous travaillez dans une de ces entreprises qui culturellement mettent au pilori l’incertitude et la lenteur, eh bien ça tombe mal.

Mauvaise nouvelle : votre logiciel lui-même, ce système fragile et complexe qui tourne en production et qui crée de la valeur, n’est pas en meilleure posture. Non seulement parce qu’il est bien sûr le fruit de ces approches heuristiques, mais en plus parce que la capacité de votre équipe à suivre et appliquer ces approches incertaines est elle-même chancelante. Que celui ou celle qui n’a jamais annulé une revue ou renoncé à écrire des tests parce que tout devenait urgent vous jette la première pierre.

Et après tout, en dépit du fait que vous écrivez peut être “méthode” (voire “méthodologie”) avec un M majuscule, si vous mettez un peu d’exigence dans votre travail, force est de constater que vous avez une plus grande certitude à propos des problèmes constatés dans vos programmes qu’à propos de leur fiabilité en général.

C’est ce que fait remarquer Taleb dans son livre Anti-Fragile, section “via negativa” : nous en savons plus à propos de ce qu’une chose n’est pas qu’à propos de ce qu’elle est.

Cela rappelle aussi la théorie de Karl Popper sur le fait que la connaissance scientifique repose sur des assertions falsifiables, et qu’en général, “lorsque nous proposons une solution à un problème, nous devrions essayer autant qu’il est possible de démolir notre solution plutôt que de la défendre. Peu d’entre nous malheureusement mettent ce précepte en pratique. Mais d’autres que nous, heureusement, nous apporterons la critique si nous ne pouvons le faire nous-mêmes”.

Concernant nos développements, la chose sur laquelle nous pouvons être véritablement factuels est la présence de défauts. (En supposant bien sûr un agrément des acteurs concernés sur ce qu’il convient de désigner par ce terme de “défaut”).

En somme, la connaissance que nous avons des problèmes dans nos programmes est plus solide que la connaissance de leur fonctionnement correct.

Il est impossible de quitter ces considérations sans citer le malicieux Knuth :

Beware of bugs in the above code; I have only proved it correct, not tried it.

Publié sur Linked In le 24/12/2024