Ceci est un article sur la vaisselle. C'est aussi un article sur le DevOps, mais nous allons principalement parler de vaisselle.
Mais avant de commencer, nous allons parler d'un concept appelé la courbe en U.
Si vous avez lu The Principles of Product Developement Flow (Donald G. Reinertsen), vous savez déjà ce qu'est une courbe en U. Et vous avez probablement compris où je vais en venir avec cette histoire de lave-vaisselle. Si ce n’est pas le cas et que vous travaillez dans le domaine de la tech, mettez-le en tête de votre liste de lecture.
Qu'est-ce qu'une courbe en U ? C'est une forme qui apparaît lorsque vous combinez les coûts de ne pas faire quelque chose (et de les laisser s'entasser) avec le coût de faire réellement la tâche. Cette courbe est utilisée pour trouver la taille optimale des lots (Batch Size) pour la productivité d'une tâche.
Si vous trouvez ça compliqué, vous avez raison ! Une analogie avec le monde réel devrait rendre ce concept plus clair.
Pensons au coût que représente le fait de laver la vaisselle à la main (et je vous promets : tout cela sera bientôt lié aux logiciels !).
Pour laver ne serait-ce qu'un seul plat, nous devons :
Cet ensemble de tâches représente le coût de transaction (transaction cost) pour nettoyer la vaisselle à la main. Que vous laviez un seul plat ou tous les plats de votre cuisine, les mêmes tâches sont nécessaires. La principale différence est le nombre de plats que vous choisissez de nettoyer à la fois, ce que l'on appelle la taille du lot (batch size).
Comme il faut plusieurs minutes pour laver chaque plat, beaucoup de personnes ne suivent pas cette routine. Au lieu de cela, ils les laissent généralement s'empiler dans l'évier. Quand la pile aura atteint un nombre critique, ils laveront tout d'un coup.
Le graphique ci-dessus illustre le coût lié au nettoyage de la vaisselle (le coût de transaction donc, en rouge) et le coût lié à l'empilage de la vaisselle (le coût de possession, en gris). La courbe des coûts globaux (overall cost en violet) est créée en additionnant les coûts de transaction et les coûts de possession. Elle forme ainsi un "U". La taille optimale des lots pour laver la vaisselle à la main est donc l'endroit où le "U" se trouve à son point le plus bas.
Les bandes verticales grises du graphique ci-dessus montrent les deux extrêmes : à gauche, on lave un plat à la fois ; à droite, on ne les lave que rarement (disons, une fois par semaine).
Si la vaisselle est lavée après chaque repas, le coût de transaction est très élevé, car il y a beaucoup de préparation et de travail requis pour chaque lavage.
Si nous attendons jusqu'à la fin de la semaine pour laver, le coût de la transaction diminuera considérablement puisque nous ne passerons pas une semaine entière à faire la vaisselle. Cependant, beaucoup de plats s'accumuleront, ce qui entraînera un coût de possession élevé (peu de vaisselle propre disponible, la cuisine a l'air sale, il y a moins d'espace libre sur le plan de travail, etc.)
L'Homme est en fait assez bon pour optimiser inconsciemment le coût global. Nous construisons naturellement des routines, comme laver la vaisselle, qui équilibrent le coût transactionnel. Ainsi nous mettons en place une routine de vaisselle en fonction du temps que cela prend et des effets négatifs de laisser une pile sale reposer dans l'évier de la cuisine.
Le mieux pour une personne avec un torchon et du savon dans les mains c'est d'opérer au point le plus bas de la courbe en U. En d'autres termes, il ne peut pas réduire radicalement les coûts globaux sans changer fondamentalement le système.
J'ai promis de lier cette analogie aux logiciels et au DevOps. Voici comment chaque concept se traduit en technologie :
Dans le monde de la tech, laver la vaisselle à la main, c'est comme mettre en production des fonctionnalités manuellement, avec un minimum d'automatisation. Déclencher manuellement les builds ; déployer les changements d'infrastructure en se connectant directement sur les serveurs et en tapant les commandes ; compiler manuellement les entrées ChangeLog, etc : ce sont les équivalents logiciels de "laver la vaisselle manuellement".
Une grande pile de vaisselle sale représente une file d'attente de plus en plus longue. Dans tout système, qu'il soit informatisé ou humain, les files d'attente sont les ennemis des flux. Les files d'attente augmentent rapidement les retards de livraison et sont des indicateurs précoces de problèmes de performance futurs. Ils freinent également les feedback loop.
Malheureusement, des longues files d'attente provoquent aussi des comportements improductifs chez l'Homme. Par exemple, les ingénieurs QA chargés de tester une nouvelle version de leur produit se plaignent : "Je ne peux pas suivre tous les changements que nous avons à tester tellement cette mise en production est conséquente !"
Les individus se mettent à craindre de plus en plus les actions qui leur permettraient de réduire la longueur de la liste d'attente. Cela les pousse à procrastiner... la liste d'attente s'allonge encore plus. Si on en revient à la vaisselle, les gens essayent d'éviter de passer le temps requis pour laver la pile de vaisselle.
Les longues files d'attente (ou les piles de plats) ont aussi tendance à augmenter l'importance cérémonielle des transactions. À mesure que la peur transactions augmente, nous avons tendance à établir des routines et des traditions pour accommoder le risque, le temps et l'effort encourus. Nous devenons moins rigoureux et nous permettons à ces files d'attente de grossir. Nous commençons ainsi à répondre aux besoins de la transaction plutôt qu'à ceux de nos utilisateurs.
Par exemple, tout comme les gens qui ont l'habitude de laisser s'accumuler beaucoup de vaisselle peuvent désigner un " temps hebdomadaire pour laver la vaisselle ", une équipe avec des processus manuels compliqués peut facilement créer un calendrier de mise en production occasionnelle. Ainsi les mise en production se font rares, les process sont manuels et les règles compliquées, ce qui perpétue la situation actuelle et devient une habitude voire même une culture d'équipe.
Avec un processus entièrement manuel, les gens ont tendance à pousser plus vers la droite la courbe en U, exécutant les transactions moins fréquemment, et conduisant à des lots de plus en plus gros. Quand vous entendez des phrases comme, "Ne commencez pas la phase de test avant demain car il y a encore une correction de bug que nous aimerions faire avant...", alors vous êtes témoin de ce phénomène.
Le lave-vaisselle est une invention utile, mais il ne règle pas tous les problèmes de vaisselle sale. Un lave-vaisselle pousse simplement les individus à choisir une taille de lot proche du point optimal au bout de la courbe en U.
Qu'est-ce que change l'utilisation d'un lave-vaisselle ?
Cependant, la cérémonie transactionnelle demeure un problème, même avec un lave-vaisselle. Des routines se construisent autour du lave-vaisselle, on ne sait plus faire sans, et cela empêche toute nouvelle optimisation. Pour beaucoup de gens, "démarrer le lave-vaisselle après le dîner" devient une routine établie qu'ils feront pendant de nombreuses années sans même y penser.
Si on revient à la comparaison avec les logiciels, l'ajout d'un lave-vaisselle dans une cuisine revient à automatiser une partie d'un processus sujet aux erreurs, tout en conservant les mêmes étapes de base.
Cette automatisation augmente la fréquence de déploiement suffisamment pour que la taille du lot soit optimale. Mais les lignes et les courbes sur le graphique ne bougent pas. Autrement dit, il s'agit simplement d'automatiser les mises en production pour qu'elles soient moins effrayantes mais sans remédier au problème de base.
C'est là que DevOps intervient.
Il existe une utopie de lave-vaisselle que l'on peut atteindre dans laquelle :
Nous pouvons réaliser cette utopie grâce à une utilisation intelligente de la technologie ! Pour cela il faut se concentrer sur ce qui a le plus de valeur : un flux constant de vaisselle propre.
Pour ce faire, il faut construire un nouveau lave-vaisselle robotisé qui fonctionne très différemment des lave-vaisselle traditionnels. Il a toujours de l'eau chaude et du savon à portée de main, il saisit la vaisselle sale dès qu'elle apparaît dans l'évier, il la lave et la sèche rapidement, et enfin, il la range sur l'étagère.
Si d'un coup il y a beaucoup de vaisselle sale, (suivez-moi dans ce monde imaginaire...) une petite armée de notre nouveau lave-vaisselle robotisé apparaît par magie, et chacun attrape un plat et nettoie en même temps. Ainsi, la vaisselle sale ne s'accumule jamais, et la vaisselle propre est toujours rangées.
En investissant dans cette technologie, nous changeons la façon de nettoyer la vaisselle, et notre courbe des transactions diminue considérablement. Par conséquent, nous changeons radicalement la forme de la courbe en U de notre lave-vaisselle. Son point le plus bas (le plus optimal) s'abaisse, tout en réduisant la taille du lot nécessaire pour réaliser ces économies.
Quel est l'équivalent logiciel de cette merveilleuse utopie de lave-vaisselle ? Les pièces essentielles sont : DevOps, CI/CD, pipelines, développement basé sur le tronc, cartographie de la chaîne de valeur, infrastructure-as-code, et plus encore. Voici l'ensemble des choses nécessaires pour que les modifications soient apportées dans votre code et mis entre les mains de vos utilisateurs au plus vite :
Indépendamment des termes que vous pouvez utiliser pour décrire tout ce qui précède (regroupons-les tous sous le terme "DevOps" pour l'instant), c'est l'équivalent logiciel de notre incroyable lave-vaisselle robotisé. Utilisés correctement, ils conduisent à des tailles de lots minuscules, à des files d'attente négligeables et à un coût global considérablement réduit.
Déployer des petits changements fréquents est aussi un bon moyen de réduire le risque de ruptures dans la production. Combien de bugs peuvent se cacher dans 10 lignes de code ? Pourquoi pas 10 000 ? La probabilité que des problèmes surviennent augmente considérablement à mesure que la taille des lots augmente. Adopter un modèle de déploiements plus fréquents avec des tailles de lots plus petite est beaucoup plus sûr que d'essayer de déployer une grosse fonctionnalités après plusieurs mois de travail.
Enfin, les petits changements de taille de lots et les déploiements réguliers permet d'évaluer la performance des équipes plus facilement (comme vous le savez déjà si vous avez lu Accelerate).
Maintenant que vous avez une bonne compréhension de la courbe en U et des relations économiques (entre la taille des lots, le coût de transaction, le coût de possession et les risques), vous pouvez appliquer la courbe en U dans d'autres domaines que votre vie professionnelle.
Et peut-être que la prochaine fois que vous serez dans une réunion d'équipe à décider quand déployer manuellement une tonne de fonctionnalités qui ont été mises en attente pendant des semaines, vous imaginerez des piles de vaisselle sale dans l'évier et commencerez imaginer des façons surprenantes de les laver.
Un grand merci à Ty Paulhus pour ses graphiques personnalisés.