Codeur vs développeur : "Do your own research"

Avant d'aborder le sujet, je voudrai sensibiliser tout le monde sur plusieurs faits très bien documentés, apparemment sans lien, et pourtant vous allez voir, il y a de la similitude.

Le concept du "mâle alpha" a été imaginé par erreur par son créateur et démenti par la personne qui a établi cette théorie, elle sert encore aujourd'hui à trop de monde. Tout le monde retenu son premier papier de recherche, seuls certains chercheurs ont noté le second, pourtant arrivé quelques années à peine après le premier. En gros, la personne a réalisé que les "alphas" des loups sont en fait le couple au centre de la meute, pas du tout le gros bras dominateur de service et la garce agressive et dirigiste que le commun des mortels aime retenir. Du coup, pas de dirigeant par la violence mais uniquement une famille qui se gère avec des amis éventuels. Ça change un peu la donne, non ?

On a tous appris à l'école que l'humanité (ou au moins les européens, coucou les cours d'histoire avec point de vue biaisé) croyait pendant des millénaires que la Terre était plate et au centre de tout que des gens comme Copernic et Galilée sont morts pour enseigner à tout le monde la terrible erreur dans laquelle tout le monde vivait. Sauf qu'en fait, rien n'atteste que les gens pensaient que la Terre était plate. Oui oui, rien. Voltaire a parlé dans un de ses écrits de l'époque où on croyait que la Terre était plate, ce qui n'est en fait jamais arrivé. C'était très certainement de la rhétorique, Voltaire n'était pas historien. Peut-être qu'il y croyait mais à priori c'est impossible à dire. Et de fait, l'humanité sait depuis au moins l'antiquité que la Terre est ronde, les habitants de villes portuaires constatent depuis "toujours" que c'est le sommet du mât des bateaux qu'on voit en dernier quand le bateau s'éloigne, ce qui n'arriverait pas si la terre était plate (déso pas déso les platistes), et on se rappellera qu'un certains mathématicien grec vaguement célèbre sur les bords avait calculé la circonférence de la Terre, et ne s'était pas trompé de beaucoup. De mémoire plusieurs chercheurs du monde Arabe du Moyen-Âge (et certainement plusieurs dans plusieurs pays différents à des siècles d'écart, juste pour rappel pour certains, le Moyen Âge a duré plus de 1000 ans...) ont repris ses travaux et les ont vérifiés. Christophe Colomb n'a absolument pas révolutionné la pensée de son temps en affirmant que la Terre était ronde et n'a absolument pas été embêté par l'Eglise pour ça d'ailleurs. On a appris tout ça d'une part pour des questions de romans national et d'autre part à cause de la confiance aveugle placée par certains dans les textes de Voltaire (qui globalement était plutôt apprécié pour le bien fondé de ces écrits) et ce qui était certainement une métaphore a fini par être pris au pied de la lettre, sans aucune vérification de qui que ce soit (jusqu'à ce que certains historiens s'en mêlent relativement récemment, et ils peinent à se faire entendre). Là aussi, tout le monde a retenu un résultat faux.

Sur un autre sujet, si je dis Viking, il y a des chances élevées que la majorité imagine de grands barbares qui portent des casques à cornes. Je n'insiste pas sur le reste de l'imaginaire sur les vikings, qui aura au moins, contrairement à ce point, le mérite d'être vaguement basé sur quelque chose qui pourrait avoir un lien historique, même unique. Mais pas les casques à cornes. Les casques à corne ont été associés aux vikings sur un malentendu dans un opéra du XIX° siècle et sont encore considéré à travers une part énorme de la planète comme une représentation fidèle des vikings. Et c'est d'autant plus bête qu'ils devraient être associés à plusieurs autres civilisations de zones géographiques ou temporelles proches (provinces germaniques antiques ou début du moyen-âge, Scandinavie antique, îles britanniques antiques, etc.) au moins pour des usages religieux, dont certains auraient pu être associés aux "prédécesseurs" d'Odin (comprendre, les divinités vénérées par les peuples datant d'avant les vikings, dont les représentations ont pu devenir des figures mythologiques telles qu'Odin et les autres dieux d'Asgard au fil des siècles), mais le monde moderne ne les retiendra que pour les vikings. Une belle erreur, relativement facile à vérifier aujourd'hui, ce que la majorité ne prend pas la peine de faire. Dans le cas particulier des croyances populaires sur les vikings j'en aurai encore énormément à dire, mais au moins la majorité de ces idées ont pu être basée sur un point vaguement historique (par exemple, non ce n'étaient pas de gros bourrins barbares assoiffés de sang et d'hydromel, même si des gens comme ça ont dû exister parmi eux) et ça nécessiterait des bouquins entiers, j'ai encore un ou deux cas que j'aimerai évoquer.

Apparemment l'idée que la Grande Muraille de Chine serait visible depuis la Lune viendrait d'un antiquaire anglais du XVIII° siècle, William Stukeley, qui aurait écrit dans une lettre "Le mur d'Hadrien n'est dépassé que par la muraille de Chine, qui dessine une formidable figure sur le globe terrestre et pourrait bien être visible depuis la Lune". C'est clairement une supposition non vérifiée (et non vérifiable à son époque) qu'on est pourtant nombreux à avoir appris à l'école. Et d'ailleurs plusieurs personnes ayant voyagé dans l'espace dont Thomas Pesquet ont bel et bien confirmé que c'est faux. Mais on l'a quand même enseigné pendant longtemps, et je ne serai pas surpris que l'info continue à être transmise.

Bon, là tous mes exemples sont historiques. Je vais en prendre un autre qui va peut-être en surprendre plus d'un. Vous savez combien ça fait 5 divisé par 2 ? Vous devriez être nombreux à répondre "2,5" (ou 2.5 pour les anglophones 😉). Et vous seriez d'accord pour dire que 5 / 2 = 2,5. Ou, si je voulais l'écrire en C ou plein de langages de programmation, 5 / 2 == 2.5

Right ?

Et bien mathématiquement parlant yes of course. Pourtant si vous mettez ce calcul dans un if, la majorité des programmes n'exécuteront pas le bloc "then" mais bien le "else".

Allez-y, faites le test. Peu importe votre langage, le seul dont je suis sûr qu'il ne produira pas le résultat que je viens de décrire, c'est OCaML (et les autres dialectes ML) qui simplement ne compileront pas (on ne compare pas un int et un float en ML, ça ne passe pas la compilation).

Et vous pouvez tourner le test dans d'autres sens : if (2.5 2 == 5) renverra false, et ce n'est pas une question de parenthèses, if ((2.5 2) == 5) se comportera exactement pareil.

Bon, j'ai assez tourné autour du pot, les gens de mon âge ou plus qui ont appris la programmation ou d'autres métiers de l'informatique à l'école attendent que je passe à la suite vu qu'ils savent déjà ça depuis longtemps, les plus jeunes ou ceux qui ont appris sur le tas ou par des formations très courtes sont peut-être perplexes (et surtout si c'est le cas faites le test !), ce n'est pas les maths qui ont tort, c'est la représentation des nombres en machine qui provoque ça (s'il y en a que ça intéresse, un petit MP ou commentaire et on en parle, sinon l'explication détaillée se trouve facilement via le moteur de recherche de votre choix).

Moi ce qui m'intéresse là ce n'est pas tant le résultat que la méthode. Au début de l'article je mentionnais principalement des connaissances fausses mais ayant peu d'impact sur notre vie au quotidien. La dernière pourrait avoir un impact dans la vie des gens qui codent. J'avais prévu d'écrire un autre exemple un peu entre les deux, à propos de la notation hongroise à partir de ce qu'on m'en a appris et en faisant ce que je décris ici j'ai réalisé que la réalité est beaucoup moins ironique que ce que j'en avais appris. Je m'explique (et oui, cette partie est vraiment différente de celle que j'avais prévu, ce n'est ni un effet de style ni une mauvaise blague, ça arrive de changer son fusil d'épaule quand on écrit ou quand on produit et j'ajouterai que c'est même beaucoup plus sain que de s'enfoncer dans un truc faux).

A la fac on m'avait appris qu'une personne de nationalité hongroise dont j'avais oublié le nom avait écrit il y a plusieurs décennies un bouquin de programmation dans lequel il parle d'un système de nommage des variables en les préfixant d'une lettre indiquant leur type. Il avait fait ça en expliquant que ça parait être une bonne idée au moment où on code mais qu'en fait c'était une mauvaise idée parce que quand je créé un int je vais le préfixer de la lettre i mais le jour où j'ai besoin d'en faire un float parce que j'avais mal estimé au départ, statistiquement je vais juste changer la déclaration et oublier de changer la première lettre du nom, ma variable va donc me dire que c'est un int alors que c'est un float, ce qui serait trompeur. Sauf que la communauté ne se serait rappelé que de la convention et pas de l'explication disant qu'il ne fallait pas l'utiliser, du coup elle avait été mise en place partout et foutu le bronx dans plein de boite. Belle histoire, mais en fait pas vraie du tout, juste déformée par le temps.

En faisant des recherches très rapides dessus pour vérifier les détails, il s'avère que la convention hongroise c'est sensiblement plus riche que juste le typage par la première lettre (plusieurs façons différentes de nommer une variable selon l'intention et le contexte, le type n'en étant qu'une possible parmi plusieurs), et que non, son auteur (effectivement hongrois) ne l'a pas prise en exemple de ce qu'il ne fallait pas faire, mais plutôt comme un exemple de ce qu'on peut peut-être faire pour arriver à travailler mieux à une époque où les compilateurs et les IDE étaient moins évolués qu'aujourd'hui. Et il n'y a pas forcément eu une adoption massive de cette convention, même si elle a été poussée par plusieurs grosses boites dont Microsoft, l'auteur ayant obtenu un poste important là-bas et l'ayant fait adopter par ses équipes. Tout le monde n'approuvera pas cette convention, certains la trouvant bien en C mais inadaptée aux langages orientés objets, d'autres la trouvant bien uniquement dans les langages où le type n'est pas explicite, bref, on est bien loin d'une description aussi tranchée et incisive que celle que j'avais appris à la fac.

Un résultat beaucoup plus nuancés et intéressant au final d'ailleurs, mais passons.

Qu'est-ce que j'ai fait ? J'ai tapé "notation hongroise" dans mon moteur de recherche, j'ai lu quelques résultats en commençant par Wikipédia VF, et en quelques minutes le sujet était clos. Ce n'était même pas pour traquer une fake news, c'était juste pour vérifier ce dont je voulais parler. No big deal, quelques minutes, basta, merci, au revoir. J'ai mis plus de temps à écrire cette petite partie qu'à faire cette recherche, croiser les sources (dont une bonne partie encore disponible sur le site de Microsoft), lire un extrait de quelques avis sur le sujet, notamment de grands noms de la programmation (au hasard, Linus Torvalds, Bjarne Stroustrup, quelques autres), certains négatifs et d'autres positifs...

En très peu de temps et juste un peu de curiosité et un soupçon de rigueur j'ai pu m'assurer d'une information.

Quand est-il maintenant quand l'information à vérifier est une histoire de technique ? Il y a des tonnes de débats ou de grandes phrases toutes faites. Alors dans ce cas il y a plusieurs options et une contrainte forte.

Je vais tout de suite évacuer la contrainte, à savoir que pour toute les recherches il faut impérativement vérifier les numéros de versions, années de sortie, etc. de ce qu'on veut vérifier, vu que dans les métiers de la tech tout change tout le temps. Les premières versions de Java étaient réputées lentes, beaucoup de travail a été investi pour accélérer les JVM jusqu'au jour où les perfs étaient largement acceptables mais la réputation de lenteur a continué pendant longtemps à ternir l'image de Java. Quelqu'un qui aurait fait des recherches sur un des débats types Java vs C++ ou Java vs Delphi aux alentours de 2005-2008 serait forcément tombé sur une phrase mentionnant les lenteurs alors qu'elles n'auraient peut-être plus été d'actualité (Java restant plus lent que C++ mais sans que ce soit forcément bloquant pour énormément d'applications). Donc on retiendra ça, quand on chercher des infos, on note les années, numéros de sortie, etc.

Maintenant au niveau des options, on peut bien sûr faire une recherche rapide comme j'ai fait. Parfois cela peut donner quelque chose, mais très souvent soit on va avoir droit à des guerres de chapelle sans réels arguments objectifs (ex : "bouh <langage 1>, il est nul, <langage 2> est beauuuuuuuuuuucoup mieux"), ou alors on va juste avoir droit à une description d'un élément ("<langage 1> sait faire ça, on déclare les variables comme ça, le typage est comme ci, etc."). C'est souvent assez difficile que ce soit pour des choix macros (langage, framework, sgbd, lib, etc.) ou des choix micros (une méthode ou une autre) de trouver une comparaison réellement objective. Du coup, que fait-on et comment pour choisir ou pour savoir si une idée peut être bonne ?

Déjà je vais partager une phrase pleine de bon sens que j'ai entendu récemment dans une conférence : « je plaisante parfois pour dire que certes la blockchain est la solution, mais pas celle de ce problème, plutôt celle d’un problème que nous n’avons pas encore identifié ». On n'essaie pas d'insérer un truc qui a l'air super cool là où on n'a pas identifié un besoin réel de ça, et pas d'autre chose.

Ensuite, pour répondre à cette question de besoin identifié, il faut déjà avoir identifié ce qu'on cherche. Et attention, cette question est plus subtile qu'elle n'en a l'air. Je parle ici de notions abstraites, pas d'un outil pour boucher un trou. Je n'ai pas besoin de Postgresql ou de MongoDB, j'ai besoin de stocker de la donnée, et soit de la retrouver à partir de différents éléments la constituant (ce qui pourrait être une façon de définir le SQL parmi d'autres) ou je peux avoir besoin de stocker de la donnée brute à ressortir telle qu'obtenue, indépendamment de savoir comment elle est constituée (un des avantages aux bases NoSQL simples telles que MongoDb). Et précisons un truc important, on a très rarement un seul besoin, surtout quand on parle d'éléments très structurants comme une base de données ou un framework. Quand on parle d'un bout de code ou d'une lib par contre, les choses sont plus simples.

Une chose faisable et je dirai absolument à faire, c'est de tester tout ce qu'on peut. Il y a plusieurs exemples que je donnais toujours à mes étudiants, très simples à réaliser et qui illustrent vraiment bien ce sujet. Par exemple, écrire le code de comparaison des perfs entre un string.Concat, un StringBuilder et une simple concaténation directe par l'opérateur + en C#. Dit comme ça, certains se disent que ça a l'air compliqué, qu'on sait pas trop, c'est pas simple. Et quand je dis "certains" je précise que j'ai déjà entendu ça de la part d'étudiants bien sûr, et aussi de collègues de travail, donc de professionnels du développement. Et on ne se moque pas s'il vous plaît, il y a plein de biais cognitifs qui peuvent faire croire qu'effectivement, c'est pas simple d'être sûr de cette info.

Un exemple de code permettant de savoir s'il vaut mieux faire du +, du concat ou du stringBuilder en C#, qu'on peut produire en mode porcasse en moins de 10 minutes sans se presser avec les résultats ci-dessous. Et je précise que s'appuyer sur DateTime n'est pas aussi précis que d'autres méthodes, puisque l'activité de mon ordi pourrait parasiter les résultats, mais à cette échelle il y a un truc qui devrait être sans appel pour tout le monde, c'est l'ordre de grandeur des résultats.

Entre le + et le concat, les résultats sont du même ordre de grandeur, avec concat qui est indiscutablement plus rapide que +, mais si on compare à StringBuilder c'est un écart de folie

Sauf que c'est curieux, moi je me souvenais que concat avait des perfs comparables au stringbuilder. Alors réessayons avec une petite modif

Ah tiens, maintenant qu'on a supprimé 10.000 affectations de variable, concat va même plus vite que le stringBuilder ! On peut supposer avec ça que la petite différence correspond aux deux affectations de variable en plus côté StringBuilder et imaginer que la méthode + est lente également à cause des nombreuses affectations de variables qu'elle inclut. Mais s'il n'y avait que ça, les deux premières méthodes devraient mettre le même temps, et même si l'ordre de grandeur est similaire, la valeur ne l'est pas. Il y a tout de même un autre élément de lenteur facile à trouver en trois coups de recherche en ligne, à savoir que myVar += "a" implique la création d'un nouveau string à chaque concaténation et la recopie du premier dans le deuxième au lieu de rajouter à la fin du premier.

Du coup, pourquoi expérimenter plutôt que de se contenter de chercher ? On aurait pu se dire "on peut lire partout qu'il faut utiliser le StringBuilder, que c'est la solution à tout alors pourquoi on se casse les pieds à l'expérimenter ?". Avant toute autre chose, sauf cas très particuliers, IL N'EXISTE PAS UNE SOLUTION UNIVERSELLE QUI EST LA MEILLEURE TOUT LE TEMPS, TOUT EST UNE QUESTION DE CONTEXTE. C'est assez clair là ? Je le répète à chaque post, à chaque article et je l'entends et l'entendrai trop souvent, "c'est quoi la bonne façon de faire ?" Elle n'existe pas "LA" bonne façon ! Dans ton cas particulier, là elle existe peut-être (et encore, souvent il y en a tout de même plusieurs de possibles équivalentes), mais cette bonne façon de faire sera peut-être moins bonne dans un autre contexte et la seule façon de s'y retrouver c'est d'apprendre pourquoi certaines sont efficaces dans un certain contexte et moins bonnes dans d'autres. Et pour ça, l'expérimentation rapide reste une façon de faire très efficace, surtout si on réfléchit à ce qu'on fait quelques minutes et qu'on partage ça avec les collègues.

Quelques minutes d'expérience, ça coûte pas cher et ça donne des résultats ! Mais pour y arriver, il fallait déjà se dire qu'on peut le faire, que ça prend pas longtemps et qu'on a surement une info utile à en retirer. Et donc ne pas être dans la course à chaque minute de production gagnée, mais bien à la recherche d'un peu d'efficacité.

Maintenant, comment je sais si mon test est pertinent et cohérent ? Qu'il n'est pas mal codé, qu'il couvre bien le besoin que je veux expérimenter, etc. ? C'est un peu subtil, mais comment sait-on que le code qu'on écrit remplit un besoin, en général ? On le teste, on en parle aux collègues ou si on est tout seul on demande à quelqu'un qui connait le métier si le résultat est bon. En expérimentation c'est exactement pareil.

Quand je débutais on m'a demandé de tester un outil lié à la base de données. Long story short, je me suis retrouvé à esquiver malgré moi les cours de bases de données à la fac, du coup je n'y connaissais rien en BDD (mais vraiment le zéro de chez zéro). J'applique la notice de l'outil (en gros, appli web générée à partir d'un ORM dont les tables sont auto-mappées sur une base existante), on voulait voir comment afficher autre chose que des tables comme des requêtes avec jointures dont on n'affiche que certaines colonnes, si l'outil gérait bien la pagination, éventuellement du cache, des transactions SQL, etc. Que des trucs que je ne connaissais pas donc. Si moi qui n'ait que la doc j'arrive à faire tout ça avec un temps de traitement tout à fait acceptable c'est bon signe. Très vite la question des perfs arrive. Moi qui n'y connait rien de chez queudalle en bdd, je teste avec "plusieurs pages" (probablement 30 ou 100 lignes en base, je ne me rappelle plus, ça commence à être vieux – dans tous les cas je n'avais pas la moindre idée de e que c'était un volume important de données). On me demande

"Est-ce que c'est rapide ?

- Bah oui, je change de page sur l'appli en une seconde.

- Mais elle est pleine ta table ?

- Ça veut dire quoi "pleine" ?

- Il y a un million de lignes ?

- Mais j'en ai pour des heures à taper ça !

- À moins de 100.000 lignes dans ta table je ne veux même pas en entendre parler, mais un ou deux millions ce serait mieux pour tester.

- euh... ok, je vais voir ce que j'arrive à faire."

Pour la blague, ça m'a permis d'apprendre que le sgbd qu'on utilisait à l'époque avait une protection contre l'injection brutale de données, si je rentrais trop de fois des lignes similaires, je me prenais des exceptions dans la tête. Je me suis retrouvé à devoir apprendre à générer des données aléatoires pour remplir la table. Bilan des courses : si j'utilise mal l'outil, les perfs sont catastrophiques. Si j'utilise l'outil tel qu'il a été prévu, temps de changement de page == 1 seconde.

Encore une fois, je n'y connaissais rien, quelqu'un qui s'y connaissait suffisamment pour me dire quoi regarder et quels critères je devais prendre en compte. A partir de là j'ai pu expérimenter en sachant quels résultats étaient prévisibles, et donc si je tombe sur complètement autre chose, il est probable que je m'y sois mal pris.

Et cet exemple, on peut s'en douter, concernait une recherche sur un sujet plus costaud que simplement choisir quelle méthode de concaténation utiliser. Et là, je peux imaginer que certaines personnes qui lisent ce billet ne comprennent pas qu'on fasse tester un junior sur un sujet pointu. En fait, c'est souvent une idée qui fonctionne plutôt bien. Pas pour ce qui est de prendre les décisions, mais pour ce qui est de réaliser les expériences. Les débutants n'ont pas des tonnes d'idées préconçues. Ils n'ont pas d'à priori du type "les ORM c'est de la maÿrde donc celui-ci le sera aussi" (ceci n'est pas forcément mon avis, juste une phrase que j'ai trop souvent entendue – j'ai un billet sur les ORM en préparation, si jamais cette question intéresse du monde). Ils ne sont pas mauvais pour lire une doc et l'appliquer. Certes, il leur manquera du recul pour décider. On ne leur demandera pas de choisir en général, mais plutôt de réaliser des expériences qu'on aura prédéfini et on leur demandera les résultats pour les analyser avec eux. J'insiste sur un point, si vous voulez que vous juniors progressent, partager vos réflexions avec eux est le minimum de la base du fondamental.

Et au passage, j'ai posé un mot qui fait souvent peur et qui est souvent mal compris par la majorité des gens : "recherche". On va être très clair sur un point, je ne parle pas ici de recherche fondamentale, de labos publics ou privés où des chercheurs théorisent des tonnes de trucs et essaient de créer le futur. Je parle ici de la recherche que toutes les boites sont susceptibles de faire, à savoir apprendre à utiliser ce qui existe déjà, et apprendre à l'adapter à ses propres besoins, comparer plusieurs outils pour essayer de déterminer lequel on doit introduire dans son SI, etc. C'est LA phase de travail que les trésoriers stéréotypé(e)s haïssent parce que "ça coûte sans jamais rapporter un kopek, et on sait quand ça commence mais jamais quand ça se termine". C'est LA phase de travail que certains chefs d'équipes tech, voire certains DSI ont appris à camoufler à leurs hiérarchies juste pour qu'on les laisse travailler efficacement au lieu de leur imposer de "ne jamais chercher mais uniquement trouver" ou autres inepties dues à un simple manque de compréhension de nos métiers (et en soit je ne jette la pierre à personne de ne pas comprendre ce qu'on fait, la majorité des informaticiens ne comprennent déjà rien à ce que font les autres informaticiens alors les non-informaticiens... par contre évitez de croire que vous savez mieux que les professionnels d'un sujet si une chose est nécessaire, utile ou futile s'il vous plait – et ça vaut aussi pour les DSI, si les trésoriers vous disent que le budget est limité, c'est qu'il a une limite...)

Du coup comment on fait de la recherche d'entreprise ? J'ai un billet en préparation là-dessus, je traine des pieds pour l'écrire, si ça en intéresse particulièrement dites-le moi, j'accélèrerai certainement (j'ai 3 ou 4 papiers en cours d'écriture à la fois, je peux les prioriser et me motiver un peu). La version résumée est en gros :

- On commence par faire quelques recherches avec son moteur de prédilection

- On cherche une explication point par point du problème

- On compare les arguments en faveur d'une solution ou d'une autre, et j'ai bien dit les arguments, c'est ça qui nous intéresse, les outils proposés sont secondaires à ce stade. Les arguments permettent de confirmer où sont les problèmes et pourquoi

- Enfin on commence à s'intéresser aux solutions, on lit les docs

- On essaie de monter un cas de base de chaque solution

- On compare sur plusieurs critères génériques (simplicité, précautions à prendre, sécurité native de la solution, évolutivité, niveau d'apprentissage requis pour utiliser l'outil correctement, niveau d'apprentissage voire d'expertise requis pour mettre l'outil entre les mains de ses équipes)

- On cherche à comprendre quels sont les critères qui nous concernent plus spécifiquement, et si des contraintes de sécurité mettent un droit de véto sur certaines.

- On ne néglige pas de piste, et on ne part JAMAIS bille en tête qu'il faut utiliser "cette solution" ou "cette autre", la seule bonne façon d'expérimenter et avec le moins possible d'à priori.

- On collecte des mesures, des résultats, qu'on compare pour estimer si une solution est effectivement plus efficace qu'une autre.

- On réfléchit à qui va mettre en place la solution chez soi et qui va l'utiliser au quotidien. A quel point faut-il former les gens, à quel point faut-il être expert du sujet dans sa théorie pour être capable d'utiliser l'outil ?

- Les décideurs arbitrent une solution, et si possible en gardant la possibilité sous le coude de basculer au cas où on se rendrait compte rapidement que ce choix n'est pas si terrible.

Un mauvais choix de techno se paiera en dette technique pendant des années ou des décennies. Dit comme ça, ça peut faire très peur. Maintenant je rassure tout de suite tout le monde, un bon choix de techno se paiera en dette technique pendant des années ou des décennies aussi. La seule question est de savoir combien ça limitera les prochaines évolutions.

Par exemple, on veut utiliser une techno pour créer le front. Peut-on la cumuler avec une autre si jamais on n'est pas satisfait ? En général, si on parle de front web, on peut avoir plusieurs outils de rendu différents. Ce n'est pas toujours pratique à mettre en place, mais il est (presque) toujours possible d'avoir des pages rendues avec un certain outil et d'autres pages rendues avec un autre outil. Ou au pire avoir deux sites/appli web avec du SSO et le même look'n'feel et basculer discrétos de l'une à l'autre sans forcément que l'utilisateur final ne s'en rende compte. L'important, c'est de pouvoir changer son fusil d'épaule en cas de soucis. Quel que soit le choix, il aura des conséquences désagréables à un moment ou à un autre. Mieux vaut partir du principe que le choix ne sera pas le meilleur, mais qu'on fera de notre mieux pour qu'il ne soit pas le plus mauvais. Faire un choix de techno après une période de recherche relève presque toujours du pari.

Autre point, plus on utilise un composant pendant longtemps plus ça va coûter cher de le remplacer par un autre. Du coup, quand on essaie, on se donne les moyens de réussir. On a fait le choix d'utiliser un sgbd, on se note les alternatives viables et les arguments en leur faveur, et se lance dans le grand bain. Et ça, ça veut dire prendre le temps de former les équipes. On utilise un nouveau modèle de connexion avec l'extérieur ? On fait une doc qui l'explique et on prend le temps d'enseigner au reste de l'équipe (voire de la boite selon les cas) comment s'en servir, qui est le référent en cas de soucis, comment faire circuler les infos qu'on découvrira tous ensembles, etc.

Et si vous avez l'impression que c'est contradictoire d'un côté de se donner à fond sur un choix et d'un autre être prêt à changer son fusil d'épaule, c'est soit que je l'ai mal expliqué, soit que vous avez raté une marche 😉 les deux sont largement compatibles, et même encouragés par certains choix d'architecture. Sans rentrer dans des tonnes de débats ou de guerres de chapelles entre l'architecture hexagonale, les micro services, le SOA, la programmation modulaire, les composants ou tous les très nombreux outils à notre disposition pour permettre de remplacer tout ou partie d'un programme ou d'un ensemble de programmes, il "suffit" (et promis c'est réalisable) d'assumer son choix tout en utilisant les outils de niveau d'abstraction ou de déploiement alternatif approprié pour être capable d'évoluer autrement, totalement ou partiellement, quand on atteindra les limites de son choix. Oui, j'ai dit "quand" et pas "si". On l'atteindra fatalement un jour. La seule question est de savoir si ce sera dans quelques semaines, mois, années ou décennies. Et souvenez-vous, même dans les environnements qui ont la réputation de ne pas évoluer depuis des lustres (coucou les gens qui font encore du COBOL depuis 40 ans), il y a toujours la partie ancienne ou spécifique, utilisée le plus souvent pour stocker et manipuler la donnée fondamentale, ou pour interagir avec un device particulier et la partie dite "moderne" ou du moins, pas sujette aux mêmes contraintes, utilisée le plus souvent pour la partie interface utilisateur ou interface avec les autres composants du système. Et à une échelle moins extrême on trouve ça très souvent dans plein d'entreprises sous forme du code associé à l'ERP, au CRM, au core system quoi qu'il soit, parfois dans une techno ancienne, exposé en service web ou équivalent, et des applis dans différentes technos plus souvent mises à jour, éventuellement avec leurs propres bases de données alimentées par le core system et par l'extérieur, servant parfois d'intermédiaires entre les deux. Et retenez bien ça si ça vous parait étrange, parfois, l'alternative, ce n'est pas de remplacer un composant, c'est d'en cloisonner l'usage et d'en rajouter des nouveaux autour, tout en continuant à l'utiliser et le développer.

Au passage, je digresse un peu mais pas tant que ça. Le sujet d'origine c'était de remettre en question de façon constructive ce dont on peut vérifier le comportement. En terme de technique cela se traduit d'une part par faire un peu de recherche, des essais, et éventuellement, si approprié, des nouveautés mises en place après tests. Je voudrais insister sur un point, cette dernière étape n'est absolument pas obligatoire et ne représente pas une perte financière pour l'entreprise quand il n'y a pas de déploiement. Se tenir informé de ce qui se fait avec quoi on est susceptible d'interagir fait partie de notre job. Se tenir informé de possibilités futures fait partie du job, un jour on pourrait en avoir besoin et autant savoir à quoi ça sert. Au même titre que la recherche au sens global du terme, on ne peut pas savoir à l'avance tout ce dont on pourrait avoir besoin dans les années à venir. Et des fois on essaie des trucs qui ne serviront jamais, des fois on essaie des trucs et ça nous permet d'éviter de nous en servir alors qu'on en avait envie au départ, voire même qu'on s'en servait déjà et que des essais en mode laboratoire ont mis en évidence un problème ou une alternative plus appropriée pour notre contexte (d'anciens collègues doivent se souvenir avoir commencé à travailler avec des websockets jusqu'à ce que mes recherches sur le sujet montrent leurs limites et en particulier leur risque niveau sécurité, ainsi qu'une alternative préférable dans le contexte de cette entreprise et de ses logiciels...)

Et si maintenant je veux parler d'autre chose que de pure technique ? Et bien, même raisonnement, même combat. Vous voulez savoir si oui ou non l'eau chaude gèle plus vite que l'eau froide ? Quelques coups de moteur de recherche devraient vous répondre et sinon vous pouvez faire le test. Ce n'est pas évident à mettre en place n'importe où, mais les hivers où ça gèle dur c'est faisable avec un peu patience 😉 (et non je ne vous donnerai pas la répondre, do your own research they say 😛)

Souvenez-vous si vous n'essayez pas, ça n'arrivera pas. Si vous essayez, les premières fois on tâtonne un peu, et assez vite on y arrive. Et spécialement les techos, ne vous contentez pas d'une simple assertion pour vos décisions. Nous avons la chance de faire des métiers où beaucoup de choses sont manipulables, expérimentez, prenez le pas d'essayer, ça peut vous changer la vie, vous ouvrir de nombreuses portes (notamment celle de l'expertise).