Un problème, une solution
Un train quitte Paris à 6h et roule à 56km/h. Un autre train quitte Lyon à 8h et roule à 69km/h. Sachant que la distance entre Paris et Lyon est de 512km, à quelle heure les trains vont-ils se croiser ?
Ce problème est beau, trop beau. Aucune ambiguïté, une solution unique. C’est ce que l’on nous enseigne du CP jusqu’à la Terminale. Oui, il faut bien enseigner quelques bases mathématiques, apprendre à poser une équation, puis la résoudre. Et puis donner systématiquement une note. Ça, c’est plus discutable, mais là n’est pas le sujet.
Sauf que la vraie vie, c’est tout le contraire.
Sortir de la pensée scolaire
Votre quotidien, comme le mien, ressemble plutôt à cela :
- On sait qu’il y a un problème mais on n’arrive pas à mettre des mots dessus (exemple : satisfaire les exigences du RGPD sans casser la modularité à l’échelle du système) ;
- On ne sait pas s’il y a une solution. En fait, il y en a toujours une, et même plusieurs, mais qui ne satisfont pas toutes les contraintes et obligent à de sérieux compromis.
- Et donc on ne sait pas laquelle choisir.
Avec tout ça, on n’est pas rendus. Et le fait que les 2 trains se croisent à 11h12 ne va pas tellement nous aider !
Donc après des années à poser des bases qui restent essentielles, l’enjeu principal des études supérieures, c’est la déscolarisation. Comprenez : l’apprentissage d’un mode de pensée moins scolaire, histoire de se préparer à un monde VUCA.
Tout l’enjeu réside dans l’analyse du problème : identifier les composantes à l’œuvre, les leviers d’action, prioriser sur base des enjeux métier. Le pragmatisme devient alors une qualité incontournable.
Au final, on en revient toujours à Einstein, qui avait tout dit avant tout le monde :
« Si j’avais une heure pour résoudre un problème dont ma vie dépendait, je passerais les 55 premières minutes à chercher la meilleure question à me poser, et lorsque je l’aurais trouvée il me suffirait de 5 minutes pour y répondre. »
Prendre en compte la dimension collective
Ajoutons à ce stade la dimension collective. Peut-être la solution A est-elle meilleure que B dans l’absolu. Mais si elle ne fait pas consensus, elle ne sert à rien, et mieux vaut peut-être la solution B que pas de solution.
C’est très visible dans une codebase : pas de solution, ce sont des pratiques divergentes, « là le code de Martin » et « là le code de Martine ». Reprendre le code d’un tiers devient alors très difficile.
Mieux vaut donc une pratique perfectible mais partagée que des pratiques divergentes : ce sera toujours plus simple à refactorer. La meilleure solution est avant tout celle qui convient aux individus et à l’équipe.
Lorsque j’accompagne des équipes, je m’attache à faire émerger un consensus organisationnel et technique (indépendamment de l’avis que je pourrais avoir sur la question). Mon rôle est de faciliter la prise de décision même si cette dernière n’est pas celle que j’aurais le plus volontiers favorisée.
Qu’un développeur fasse du TDD (Test-Driven Development) « parce que le coach me l’a demandé » serait un échec pour moi (voir à ce sujet l’excellent article de Martin Fowler). Je préfère que l’on me dise « honnêtement, c’est pas mon truc » : au moins, la discussion est ouverte.