Développement orienté truc à la mode

Cette article est une traduction de “Hype Driven Development” écrit par Marek Kirejczyk. Je partage tellement cet avis que, avec son accord, j’ai décidé de le traduire en français.

Trop souvent, des équipes de développeurs ont tendance a faire le choix d’une technologie ou d’une architecture en se basant sur de fausses opinions, l’avis d’autres sur les réseaux sociaux ou ce qui est considéré comme le dernier truc à la mode incontournable, plus que sur des vraies recherches et considérations des impacts attendus sur leurs projets.

J’appelle cette tendance “Hype Driven Development” (HDD). Je la considère dangereuse et préfère toujours l’approche plus professionnelle dite“Solid Software Engineering” (Choix raisonné de la stabilité logiciel).

Nouvelle techno — nouvel espoir

Ça vous dit quelque chose ? Une équipe choisit la dernière technologie à la mode au lancement d’un projet suite un article sur un blog, de retour d’une conférence web ou parce que c’est en Trending topic sur Twitter. Et après quelques semaines à mettre en place et à utiliser cette nouvelle techno annoncée providentielle, les ennuis commencent.

Plutôt que de gagner en temps ou en simplicité, les développements ralentissent, les ajouts riment avec complexité, les mises en preprod/prod sont de plus en plus espacées, les équipes de démotivent en passant plus de temps à configurer des modules et débugger les effets de bords qu’à développer de nouvelles fonctionnalités. A chaque étape, “il nous faut encore quelques jours”

Le choix du truc à la mode

Le choix de l’orienté Truc à la mode peut toucher un projet de plusieurs manières différentes :

  • Orienté dernier blogpost cool — quand un développeur choisit une techno / librairire / framework / design selon le dernier article d’un blogueur connu ou selon ce qui fait le buzz
  • Orienté dernière conférence à la mode — Faites très attention aux gens rentrant d’une conférence. Ils sont inspirés. Et c’est un couteau à double tranchant. Utiliser une techno / librairie / méthodo sans plus de recherches et connaissance peut se révéler la meilleure façon de finir droit dans le mur
  • Orienté quelqu’un en parle tout le temps — se produit quand un seul membre de l’équipe parle sans arrêt d’une techo / librairie / méthode qui ne maitrise pourtant pas mais en parle tellement sans arrêt qu’elle fini par être sélectionné par l’équipe
  • Orienté plugin/gem/dépendance — particulièrement répandu dans la communauté Ruby On Rails où on peut trouver des gemfile tellement longues que la seule chose plus longue est le temps que prend l’application à se lancer. Cela venant de la croyance que tous les problèmes peuvent et doivent être régler par un Gem/plugin. Le besoin ou problème pourrait être réglé par quelques lignes de codes maison, mais on préfére rajouter du plugin/dépendance par dessus l’existant.
  • également a noter un comportement commun au développeur à la mode : l’orienté StackOverflow, où il intègre dans son appli des lignes de codes récupérées sur Internet qu’il ne comprend pas forcement.

Suivre la Hype, et se tirer une balle dans le pied

Le problème de suivre la mode est que cela amène la plupart du temps à un mauvais résultat. Et ce mauvais choix d’architecture ou de technologies peuvent impacter l’équipe et le projet des mois voir des années plus tard. Dans le pire des cas, il oblige à une autre situation très compliquée en développement logiciel : la grosse refonte globale. Qui finie toujours dans les larmes.

Le pire du pire me semble être les réseaux sociaux — où les nouvelles idées se répandent bien plus vite qu’elles ne sont vraiment testées. Trop vite pour que l’on puisse comprendre et identifier le pour du contre.

Anatomie de la hype

Comme expliqué sur Wikipédia, les cycles de la Hype s’inscrivent généralement dans la structure suivante :

Etape 1: solutionner un vrai problème

Le projet démarre dans une société. Une équipe dans cette société défini qu’il n’y a pas de socle technique existant répondant à leur problématique. Cette équipe crée un nouveau framework, librairie ou méthodologie et le problème soulevé est réglé.

Etape 2: Effet d’annonce, buzz et mots clés

L’équipe ne resiste pas au plaisir de parler et montrer au reste du monde ce qu’il ont créé dans des articles ou lors de conférences. La problématique était réelle et importante, et donc ils ne sont pas peu fiers de ces résultats impressionnants. Ce qui, c’est normal, en excite beaucoup.

Le problème c’est que cette excitation ne leur permet pas toujours de bien appréhender quels étaient réellement tous les problèmes rencontrés par cette équipe et tous les détails de cette solution. Après tout, c’est une problématique pas évidente et la solution ne l’était pas non plus, ce qui prend plus qu’une série de tweets, des conférences rapides ou du bavardage pour tout expliquer. Le message est altéré et certains détails sont omis.

Etape 3: l’adoption

Tous ces victimes de la mode lisent les blogs, réseaux et vont aux conférences. Rapidement, malgré l’altération du message et des détails omis, certaines équipes se précipitent dessus même si au final, elle n’apporte ou ne règle rien de leurs problèmes. Et pourtant, tout le monde croit dur comme fer que cette nouvelle technoloiguie fera le café et réglera leurs problèmes.

Etape 4: la désillusion

Au fur et a mesure que le temps passe, la technologie n’améliore pas les développements, et oblige a faire du boulot en plus. Il y a de plus en plus de code a reécrire plusieurs fois et un effort de formation pour l’équipe. Elle ralentie, les chefs de projets s’ennervent. Tout le monde se sent trahi.

Etape 5: le bilan

Au final, l’équipe fait le bilan et réalise quels sont les inconveignants et points de frictions de cette nouvelle technologie, et dans quel cas elle serait le mieux adapté … jusqu’au prochain cycle de la hype.

Exemples de la hype

Examinons certains examples de la hype selon ces 5 étapes

Example 1: React.js

Etape 1: Facebook a un problème: maintenir une application web monopage, avec tellement de changements d’états des éléments d’interface possibles selon des évenements divers qu’il en devient très compliqué voir impossible de les garder cohérents entre eux.

Etape 2: Facebook annonce un nouveau paradigme basé sur des mots-clés qui font le buzz à ce moment là: functionnel, DOM virtuel, composants.

Etape 3: Allelua ! Facebook a créé le framework applicatif du futur ! Tout projet de nouvelle application doit absolument l’utiliser.

Etape 4: Ah mais en fait ça représente quand même pas mal d‘investissement, pour peu voir aucun retour !

Etape 5: React c’est super pour de l’application monopage d’interfaces complexes temps réel, mais pas nécessairement pour des applis plus simple.

Example 2: DHH tue le TDD (Test Driven Development)

Etape 1: DHH, créateur de Ruby On Rails, réalise à quel point il est compliqué faire du TDD (développement piloté par du test en amont) vu que ce language n’a pas les fondations permettant de faire du vrai dev orienté objet. Il fait alors un choix pragmatique — ne plus faire de tests en amont.

Etape 2: La hype grossi autour de son blog post et conference — La hype est lancé et a son gimmick: “TDD est mort”

Etape 3: Arretons de faire des tests! Notre Guru l’a dit. On ne les faisait déjà pas en vrai, mais au moins on a plus à faire semblant.

Etape 4: Attends en fait là on a moins de choses qui fonctionnent qu’avant. On a laissé passé des bugs de partout.

Etape 5: TDD n’est ni mort ni vivant. Les tests unitaires sont une question de compromis, intégrant les risques de modifier une API, la compétence des équipes et de l’existant.

Example 3: les micro services

Etape 1: C’est compliqué de faire évoluer une grosse architecture monolytique. A un certain niveau de complexité, il est préférable de l’éclater en plusieurs services. Les performances n’en seront que meilleures et les évolutions plus facile à réaliser par plusieurs équipes.

Etape 2: La hype se crée une tendance: évolutivité, couplage léger, monolithe.

Etape 3: Recréons tout en micro-services ! Le code de l’application est un vrai “spaghetti” (ou aussi “pôt de pue”) a cause de notre architecture monolithique. On faut tout passer en micro-services.

Etape 4: Eeeet galère ! C’est beaucoup plus long de développer l’application comme ça, plus compliqué à déployer en prod et en plus on passe un temps de malade à trouver d’où vient le bug à travers tous ces échanges entre services.

Etape 5: Les micro-services nécessite beaucoup temps de coordination des équipes de devs et des opérateurs à la DSI, et représente un charge de travail supplémentaire. Tant que l’application ne rencontre pas de problème d’évolutivité, c’est de l’argent jeté par les fenêtres.

Example 4: noSql

Etape 1: les bases de données SQL ne sont pas adaptées pour de la haute charge ou de la donnée non structurée. Des équipes dans le monde entier travaillent sur des nouvelles bases de données qui n’utilisent pas SQL.

Etape 2: La hype se crée : évolutivité, big data, haute performance, …

Etape 3: Nous aussi on a une base de données lente et pas assez grosse. Changeons tout pour du noSql !

Etape 4: Besoin de faire une jonction de 2 tables ? Oublie tout de suite. La moindre opération sur les données devient de plus en plus compliqué. Les développements ralentissent sans que les vrais problemes soient résolus pour autant.

Etape 5: les bases noSql sont des outils dediés à résoudre des problémes très spécifiques (du très très très gros volume de données, données non structurée ou a très haute charge). SQL reste le meilleur outil pour gérer des données, même en très gros volume ou en haute charge s’il est utilisé correctement avec une vraie compétence. Les cas nécessitant du noSql restent assez rare en 2016.

Exemple 5: Elixir et Phoenix (ou votre language/librairie préféré)

Etape 1: des frameworks web comme Ruby On Rails tiennent assez mal la montée en charge, les architectures distribuées ou les web sockets.

Etape 2: La hype se met en place: évolutivité, haute performance, architecture distribuée, tolérance aux pannes.

Etape 3: Ah ça craint, notre application est très lente et le chat pas du tout évolutif

Etape 4: Wow, se mettre à la programmation fonctionnelle et les approches distribuées c’est pas si simple. On prend vraiment pas mal de retard…

Etape 5: Elixir et Phoenix c’est très bien, mais demande un gros effort d’apprentissage, qui n’aura d’interet sur le long terme que si il y a des besoins de haute performance.

Et la liste ne s’arrête pas là…

Dans ce monde bien rempli qu’est celui des développeurs les endroits où la hype est répandue sont légions. Un nouveau framework Javascript né pratiquement tous les jours : Node.js, event programming, reactive programming, Meteor.js, le MVC côté client, React.js, celui auquel vous pensez, …

Les bonnes pratiques

Mais alors, si on ne peut pas se fier à l’avis d’Internet ou à l’opinion des autres, comment faire les bons choix ? Voilà quelques principes à suivre.

Tester et faire des recherches avant de faire son choix

  • Prototyper — Apprenez d‘une technologie non pas des blogs mais de votre experience. Prenez 1 ou 2 jours pour créer un prototype d’une nouvelle fonctionnalité dans cette nouvelle techno avant de faire votre choix. Laissez l’équipe juger des pour et contre. Le mieux est encore de le faire avec plusieurs technologies et les mettre face à face.
  • Les Hackathons sont une bonne façon de faire réaliser à une équipe les points forts ou faiblesses de plusieurs technologies. Quelques jours suffisent pour que toute l’équipe teste une selection de nouveaux langages montants qu’il serait tentant d’utiliser. Le but est que l’équipe puisse se faire un avis personnel sur son expérience pour faire les meilleurs choix.

Quand ?

  • Le meilleur moment reste évidemment quand le retour sur investissement est au plus haut. La plupart des technologies sont créés avant tout pour régler un problème en particulier. Avez-vous ce problème ? Est-ce vraiment problématique ? Le régler va t’il vous faire gagner du temps ? La migration vers cette nouvelle technologie va t’elle “rembourser” la courbe d’entrée et de la refonte ? Cela va t’il, au moins pendant un temps, ralentir les developpements par un facteur de 2 ? 4 ? Est-ce vraiment le bon moment ?
  • Selon l’équipe en place — certaines équipes sont simplement plus rapide que d’autres à produire. Elles s’ennuient aussi plus vite à faire ce qu’elles savent déjà faire, et vont donc plus facilement introduire de nouvelles technologies. Ce n’est pas une raison pour autant de ne pas prototyper ou faire des hackatons. En revanche, si l’équipe a déjà du mal à produire dans les temps, jouez la prudence.

Embauchez les bonnes personnes

  • Une forte expertise technique est la clé — des personnes compétentes dans différents modèles, comprenant l’informatique théorique et ayant une bonne culture générale informatique sont moins sensible à la hype.
  • L’expérience — la hype se développe plus facilement chez les novices. Plus les années passent et plus une personne s’est retrouvé face à un mur ou les pieds dans la … boue. Ce qui va la rendre plus pragmatique quant à l’adoption ou non d’une nouvelle technologie.
Bravo à Nicolas Froidure pour m’avoir poussé ce jeu de tout pourri :)