The Silver Bullet Syndrome

Hadi Hariri – The Silver Bullet Syndrome from NCRAFTS Conferences on Vimeo.

Généralement, quand Hadi Hariri a un truc à dire, tu te tais et tu écoutes. D’une part, parce que quand un gars a une liste de talks à son actif suffisamment longue pour nécessiter un menu, sur des technos aussi variées et depuis aussi longtemps, c’est sans doute qu’il ne raconte pas n’importe quoi. Et d’autre part, parce qu’il est à la tête de l’équipe chez JetBrains (tu sais, Resharper, IntelliJ, TeamCity, ce genre de bricoles) chargée de faciliter la vie des développeurs, et que ces gars savent, somme toute, à peu près de quoi ils parlent. Donc voilà pour le décor si tu viens de faire connaissance avec Hadi.
En revanche, et c’est là que ça se gâte, Hadi est remonté. Il est, entre autre, venu se moquer de toi. Mais pas que de toi. De nous aussi. Lui compris. Durant ce talk lors de NCrafts le mois dernier, il est venu parler du syndrôme de la balle en argent. Alors, ce n’est pas nouveau, mais Hariri a sans doute raison de remettre les pendules à l’heure et de faire une piqûre de rappel ou deux. Il nous prévient poliment en intro : “Si vous voulez apprendre quelque chose, allez plutôt dans la pièce à côté, il y a sûrement un talk très intéressant”. Si tant est que prendre du recul sur notre métier pendant une heure est incompatible avec le fait d’apprendre quoi que ce soit. Personnellement, j’ai pris une bonne torgnole. Du genre qui fait du bien, et où, en plus, tu remercies sincèrement celui qui vient de t’en coller une.

Donc, pendant une grosse demi-heure, Hariri va donc répéter son incantation : THERE IS NO SILVER BULLET. Et quand je dis que tout le monde est concerné, ce n’est pas du flan. Hariri a bien écrit un bouquin sur WCF. Ouais, le truc qui allait résoudre tous nos problèmes de communication inter-applications. Bon, à ceci près qu’on passait bien plus de temps à configurer le bousin dans des fichiers XML imbitables pour le faire fonctionner qu’à écrire les services à proprement parler. On est donc tous concernés. On fait notre boulot de veille, on regarde tous les trucs qui sortent comme un gamin qui déballe ses cadeaux de Noël. On n’a qu’une envie, c’est de jouer avec. “Chouette, une nouvelle brique dans Azure ! Hmm, NoSQL, plus de contraintes ! Oh, un nouveau framework JS ! Ah puis ça a l’air chouette, le fonctionnel ! Tiens, c’est quoi, Docker ? Et je viens d’entendre plusieurs personnes parler de Microservices, ça doit forcément être le prochain truc !”. Donc ouais, tout y passe. Les cycles de développement s’étant considérablement raccourcis ces dernières années, la fréquence de sortie de nouveaux produits a naturellement augmenté. Corollaire de ça, la vitesse à laquelle une techno est abandonnée s’est aussi considérablement accrue, donnant parfois l’impression d’avoir été des cobayes et de s’être formés pour rien à un outil mort-né. Et tout y passe : les AGL, les frameworks, les langages, les concepts. Le bilan est rude. Quand on le prend comme ça en pleine tête, ça a le gros mérite de pousser à la réflexion.

Parce que ça peut avoir des conséquences plutôt graves. Notre boulot à nous consultants est – entre autres – de consulter. De conseiller, du moins. Or, qui n’a jamais incité un client à opter pour telle ou telle techno parce qu’on avait envie de se former dessus ? Regarde-moi bien dans les yeux. Ouais, je me disais bien. Mais ça marche aussi chez les clients. On en voit qui font des choix basés non pas sur la satisfaction de leur besoin fonctionnel, mais parce que ça leur plait d’être à la pointe et accessoirement que ça leur permet de travailler avec les développeurs les plus passionnés et curieux. Une vraie spirale. Vertueuse ou néfaste, ça dépend clairement des cas.

Faut-il pour autant jeter à la poubelle tout le travail de veille ? Evidemment que non. On bosse dans un milieu où on marche constamment sur des oeufs.  Si même une boîte comme Google n’est pas capable d’assurer la rétrocompatibilité entre deux versions de son framework JS, c’est que le sol n’est pas très stable. La question de pourquoi on va choisir telle ou telle techno pour tel ou tel projet devient alors fondamentale. Et si on ne se la pose pas en permanence, c’est une erreur. Heureusement, il reste des wagons auxquels se raccrocher. L’architecture d’un PC n’a pas fondamentalement évolué depuis quelques dizaines d’années, se contentant de calculer les choses plus rapidement. Certains des meilleurs bouquins sur les pratiques d’ingénierie logicielle datent également de plus de 15 ans. Le retour en grâce des langages fonctionnels prouvent, eux aussi, que certaines choses sont faites pour durer. Javascript fête dignement ses 20 ans cette année. Et je ne parle pas du C.

Un développeur n’est pas un intégrateur. Sa plus-value n’est pas de savoir où mettre les points de colle pour faire cohabiter deux outils pré-existants. Sa vraie plus-value est de résoudre un problème. En tenant compte de toutes les informations qu’il peut recueillir en entrée (ce qui peut ne pas être une mince affaire), à lui d’imaginer la solution la plus efficace pour satisfaire ses contraintes. C’est là qu’il est utile.

Bref, j’espère vous avoir donné envie de regarder cette vidéo, c’était tout ce que je voulais faire initialement. Donc regardez cette vidéo. Vraiment. REGARDEZ CETTE VIDEO. Hadi n’est pas content. Mais Hadi est drôle. Et quand Hadi fâché, lui toujours faire ainsi.