Choisissez des technologies ennuyeuses (2015)

• Adopter avec retenue les nouvelles technologies et privilégier des technologies éprouvées (boring technology) favorise le succès à long terme de l’entreprise
• Chaque entreprise ne dispose que d’environ 3 jetons d’innovation (innovation tokens), et en dépense un à chaque fois qu’elle choisit NodeJS, MongoDB ou un outil émergent
• Les technologies éprouvées ont des capacités et des modes de défaillance (failure modes) bien connus, ce qui réduit le risque des inconnues inconnues (unknown unknowns) propres aux technologies récentes
• Les choix technologiques affectent toute l’équipe et toute l’organisation ; à cause de la charge opérationnelle et de la charge cognitive, il est souvent préférable d’utiliser un outil convenable pour de nombreux problèmes plutôt que le meilleur outil pour une tâche donnée
• Un choix technologique réfléchi donne aux ingénieurs la liberté de se concentrer sur des problèmes plus importants, et la technologie pour la technologie n’a aucun sens

---

Accepter l’ennui (Embrace Boredom)

• Chaque entreprise possède environ 3 jetons d’innovation (innovation tokens) et cette réserve reste fixe pendant un certain temps — elle peut augmenter un peu une fois la stabilité et la maturité acquises, mais on a tendance à surestimer son stock
• Écrire un site web en NodeJS, utiliser MongoDB ou adopter une technologie de service discovery lancée depuis moins d’un an consomme chacun un jeton d’innovation ; écrire sa propre base de données est une très mauvaise idée
  • Ces choix peuvent être légitimes pour une société de conseil JavaScript ou une entreprise de bases de données, mais la plupart des entreprises poursuivent de grandes missions comme redéfinir le commerce mondial ou réinventer les paiements sur le web — consacrer une attention limitée à des innovations dans un domaine comme ssh est un bon moyen d’échouer ou de retarder son succès
• « Ennuyeux (boring) » n’est pas synonyme de « mauvais (bad) », et il existe aussi des technologies à la fois ennuyeuses et mauvaises — parmi les technologies ennuyeuses mais suffisamment bonnes, on peut citer MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• L’avantage des technologies ennuyeuses tient non seulement à leurs capacités (capabilities), mais aussi au fait que leurs modes de défaillance (failure modes) sont bien compris
• Dans un choix technologique coexistent les known unknowns (par ex. ne pas savoir comment une base de données réagit quand le CPU atteint 100 %) et les unknown unknowns (par ex. ignorer que l’enregistrement de statistiques peut provoquer une pause GC) ; plus une technologie est récente, plus l’ampleur des unknown unknowns est grande

Optimiser globalement (Optimize Globally)

• Préférer les technologies ennuyeuses est un bon biais, mais ce n’est pas le seul critère ; un choix technologique a une portée (scope) qui s’étend à l’équipe, à l’organisation et au système dans son ensemble
• Ajouter une technologie a un coût — si l’on utilise déjà Ruby, ajouter Python fait vite dépasser le gain marginal par la complexité, mais dans des débats du type Python vs Scala ou MySQL vs Redis, on oublie souvent ces contraintes pour invoquer « le meilleur outil pour le travail (best tool for the job) »
• Le cœur du travail consiste à faire correspondre des problèmes métier à l’espace des solutions offertes par les logiciels ; sans coût associé au choix, on pourrait sélectionner pour chaque problème l’outil localement optimal, mais dans la réalité ce coût existe
  • Ce coût est surtout celui des opérations (operations) et, dans une moindre mesure, de la charge cognitive (cognitive overhead) — supervision, tests unitaires, connaissances nécessaires pour corriger, scripts d’initialisation, etc. s’accumulent rapidement
• Le problème de la logique du « meilleur outil pour le travail » est qu’elle envisage « meilleur » et « travail » de manière myope — le vrai travail consiste à faire survivre l’entreprise, et le « meilleur » outil est celui qui est le moins mauvais (least worst) sur le plus grand nombre possible de problèmes
• Le coût à long terme du maintien d’un système stable dépasse largement les désagréments rencontrés pendant sa construction, et les développeurs expérimentés et productifs le comprennent

Choisir parfois de nouvelles technologies (Choose New Technology, Sometimes)

• Poussée à l’extrême, cette logique conduirait à tout faire en Java pour créer un site web, ce qui n’est pas réaliste — il faut un moyen d’ajouter de nouveaux outils à la boîte à outils
• Comme une nouvelle technologie finit par avoir un impact à l’échelle de l’entreprise, son ajout est une décision qui exige une visibilité à l’échelle de toute l’entreprise (company-wide visibility) — il faut instaurer l’attente culturelle que « c’est un sujet dont nous discutons tous ensemble »
• L’exercice le plus utile consiste à se demander comment résoudre le problème immédiat sans ajouter de nouvelle technologie — cela permet de détecter les cas où le « problème » n’est en réalité que l’envie de quelqu’un d’utiliser cette technologie, auquel cas il faut arrêter immédiatement
  • On peut aller très loin avec un petit nombre de choix technologiques, et la vraie réponse n’est généralement pas « c’est impossible », mais plutôt « c’est faisable, mais trop difficile » — si vous avez l’impression qu’il est impossible d’atteindre votre objectif avec les ressources actuelles, c’est peut-être que vous ne réfléchissez pas de manière assez créative
• Il est utile de documenter clairement pourquoi résoudre ce problème avec la pile actuelle est excessivement coûteux et difficile
• Le choix d’une nouvelle technologie peut être purement additif (par ex. ajouter memcached faute de cache), ou bien chevaucher ou remplacer un existant — dans ce cas, il faut fixer des attentes claires concernant la migration des fonctionnalités existantes, la politique prenant généralement la forme d’une promesse de migration accompagnée d’un calendrier proposé
  • L’objectif est de maintenir les débris à un niveau gérable et d’éviter la prolifération de solutions localement optimales
• Cette procédure n’est pas lourde : quelques questions à remplir dans une tâche et une réunion pour en discuter — si une nouvelle technologie ou un nouveau service franchit ce filtre sans problème, son ajout est approprié

Il faut livrer, tout simplement (Just Ship)

• La programmation polyglotte (polyglot programming) est vendue avec la promesse que laisser aux développeurs une liberté totale dans le choix des outils permet de mieux résoudre les problèmes, mais c’est au mieux une définition naïve du problème, au pire un raisonnement biaisé — le toil des opérations quotidiennes finit par écraser les développeurs
• Un choix technologique réfléchi est précisément ce qui donne aux ingénieurs la liberté de réfléchir à des questions plus importantes, et la technologie pour la technologie est de l’huile de serpent

Le cas Etsy (note)

• Etsy a beaucoup souffert de ce problème au début — après avoir recruté de nombreux développeurs Python, l’entreprise a cherché quoi leur faire faire et a construit une couche intermédiaire sans intérêt, dont la suppression a pris des années ; en parallèle, la latence de recherche au 90e percentile était d’environ 2 minutes — Etsy n’a pas échoué, mais n’a rien livré pendant des années, ce qui a retardé son succès
• On appelle souvent l’intersection des technologies ennuyeuses et mauvaises « enterprise software », mais ce n’est pas forcément exact
• Le cas des activity feeds d’Etsy — ils ont été implémentés à une époque où l’essentiel était consolidé autour de PHP, MySQL, Memcached et Gearman ; l’implémentation était bien plus complexe qu’avec un outil comme Redis, mais elle restait tout à fait réalisable avec cette pile
  • Pendant les années suivantes, alors que l’attention s’est déplacée ailleurs, l’usage des activity feeds a été multiplié par 20, mais grâce à la plateforme partagée, ils ont continué à fonctionner sans changement particulier — un avantage de long terme apporté par la retenue dans les choix technologiques
  • Cela ne signifie pas qu’il faut être absolutiste — des activity feeds basés sur memcached paraissaient pragmatiques, mais pas au point d’implémenter de la recherche spécialisée avec recherche à facettes en pur PHP, c’est pourquoi Etsy a utilisé Solr