Pourquoi devrais-je lire ceci ?

Pour mieux comprendre le coût réel et mortel de la complexité. En remarquant notre perception biaisée de la simplicité et de la complexité. Et aussi en modélisant la complexité pour découvrir certaines de ses caractéristiques. Il s'agit principalement de la nature exponentielle.

Règles de simplicité

La simplicité, à mon avis, est le principe le plus important du développement logiciel. Voilà, je l'ai dit. C'est si simple :)

Pensez-vous la même chose? Laissez-moi vous dire pourquoi je le crois.

Les deux faces d'une même médaille

La simplicité est sous-estimée

Nous ne voyons souvent pas la beauté cachée de la simplicité. Comme si nous tenions cela pour acquis. Il est très facile de passer à côté de l'ingéniosité qu'il introduit. En effet, une solution simple est évidente à expliquer et à comprendre mais souvent pas à découvrir. Il est difficile d'être fier de quelque chose qui, une fois expliqué, semble banal. Même s'il aurait fallu un effort monumental pour le découvrir. Après tout, les gens jugent souvent les résultats, pas la manière de les obtenir. Mais pour mieux comprendre la valeur de la simplicité, nous devons la regarder dans l'autre sens. Bonjour, complexité.

Le véritable coût de la complexité

Je soutiens que la complexité est une maladie. Une maladie mortelle. Il a été ajouté à petites doses par chaque décision que nous prenons. Lentement mais sûrement, ceux-ci ont un impact cumulatif sur le corps qu'ils envahissent. La vitesse de changement ralentit comme si des poids invisibles étaient ajoutés aux jambes d'un coureur. À terme, il pourrait même atteindre une stagnation complète. Dans le pire des cas, une intervention douloureuse (comme une réécriture) est la seule voie à suivre.

La complexité est admirée

Pourquoi ce scénario est-il si courant ? Pour répondre à cette question, nous devons comprendre que nous privilégions la complexité. C'est parce qu'on nous apprend à apprécier la complexité. Prenez la Grande Pyramide de Gizeh comme exemple extrême. Il est considéré comme le dernier membre permanent des sept merveilles du monde antique. Un bâtiment remarquable et impressionnant. Mais pour être franc, ce n'est qu'un tombeau. Le pharaon avait simplement besoin d'un endroit pour être enterré. Disons que c'était son intention dès le bâtiment (ignorant la motivation religieuse ou politique). Ensuite, une simple tombe aurait suffi. Quelque chose de semblable à ce que les chefs d'État reçoivent de nos jours. Pourtant on admire le bâtiment et sa complexité. Nous ne voyons pas cela comme un gaspillage de ressources qui auraient pu être investies ailleurs.

Et voici la grande ironie :

Nous admirons la complexité et évitons la simplicité, alors que nous devrions admirer la simplicité et éviter la complexité.

Complexité de la modélisation

Pouvez-vous estimer l'impact de la complexité ? Qu'est-ce que cela fait à votre système ou à votre organisation ? Peut-être a-t-il l'impression que c'est trop abstrait même pour aborder ce sujet. Voyons si nous pouvons analyser ensemble le coût caché de la complexité, et comment le combattre.

Nous devons nous construire un modèle mental qui donnera forme à cet ennemi insaisissable. Cela servira de pierre angulaire à notre approche de la complexité.

Chaînes de complexité

Toute chaîne est construite en connectant des maillons. Prenons par exemple un système de société de logiciels aléatoire et essayons de le décrire avec des chaînes. Les liens seraient des composants du système (par exemple, des microservices). Une chaîne serait composée de composants système qui sont couplés dans n'importe quelle relation significative (par exemple, des microservices qui communiquent entre eux). Le système peut alors être représenté comme un ensemble de chaînes. Voilà, assez avec les définitions.

Voyons un exemple concret. Disons que nous avons deux microservices qui communiquent entre eux. Ce sont deux maillons de notre chaîne. De plus, ils fonctionnent sur un fournisseur de cloud. Le fournisseur de cloud est un autre lien. Et enfin, les services sont déployés à l'aide d'une seule infra CI/CD. Encore un lien. Nous avons maintenant décrit une chaîne de quatre maillons. Jusqu'ici tout va bien.

La complexité vous frappera durement lorsque les liens commenceront à avoir plus d'un seul état. Par exemple, supposons que l'un des microservices est en cours de migration vers une nouvelle version majeure (par exemple, ayant des changements avec rupture dans l'API). Pendant le processus de migration, ce lien aura simultanément deux états. Comme si notre chaîne bifurquait en deux « chaînes fantômes ». De plus, si nous prenons en charge une architecture multi-cloud et avons 2 fournisseurs de cloud différents, un autre lien a plus d'un état. Mais maintenant, notre chaîne d'origine a été transformée en 4 chaînes fantômes. Dans le même temps, l'équipe infra a commencé les tests A/B de l'infrastructure CI/CD. Le 4 double à 8. Cela croît de façon exponentielle.

Un cas limite entraînant une défaillance du système ne peut désormais être déclenché que dans l'une des chaînes fantômes. Par exemple, un bogue déclenché par un appel d'API au microservice nouvellement migré. Mais seulement s'il a été déployé à l'aide de la nouvelle infra sur le premier cloud. Le décor est planté. Et devinez quoi, cela se produit vers 2 heures du matin en réveillant l'ingénieur de garde. Conduisant à un autre post- mortem .

Plus vous avez de chaînes et plus elles s'allongent, plus le risque d'explosion exponentielle de chaînes fantômes augmente.

Notons quelques comportements intéressants qui ressortent de cette modélisation :

1. Impact sur la complexité - Ajouter la même quantité de complexité à un système complexe produit un impact plus important que sur un système simple. Cela est dû au facteur exponentiel de complexité.
2. Le paradoxe de la complexité - Un effort pour réduire la complexité, à long terme, ajoutera probablement de la complexité à court terme. En effet, les modifications impliquant des migrations ajoutent plus d'états aux liens des chaînes existantes (visibles dans l'exemple ci-dessus). Cela peut donner l'impression aux gens que nos efforts pour réduire la complexité échouent alors qu'en réalité ce n'est pas le cas.

Dans cet article, j'ai abordé un type de complexité. Cependant, la complexité peut prendre de nombreuses formes différentes. En énumérant quelques-uns :

1. Complexité du système - Comme nous l'avons décrit ci-dessus. La complexité des composants du système et leurs interactions.
2. Complexité des produits - Des produits aux services. Décomposez-le en fonctionnalités, UX, flux et leurs interactions.
3. Complexité organisationnelle - De la structure organisationnelle à ses processus et sa gouvernance.
4. Complexité du code - Pas seulement les définitions classiques du temps et de la mémoire de l'informatique. Mais aussi d'autres aspects tels que le code propre.

Et après?

Dans mon prochain article, nous discutons de certaines caractéristiques supplémentaires de la complexité :

Sauter dans le terrier du lapin de la complexité

Conclusion

Résumé

La complexité est souvent admirée par les gens. Pourtant, nous manquons souvent qu'il a aussi un côté mortel. Nous ne voyons généralement pas son coût jusqu'à ce qu'il soit trop tard, principalement parce que c'est un concept abstrait et insaisissable. La complexité de la modélisation et son caractère exponentiel permettent d'être conscient des dangers à venir. Soulignant l'importance cruciale de la simplicité.

Réflexions finales

Une remarque complémentaire sur le modèle mental des chaînes de complexité : Un meilleur modèle sera probablement un graphe (celui de l'informatique classique). Où chaque composant du système est un nœud/vertex. Un bord entre les nœuds marque que ces composants du système sont connectés dans une certaine relation. Ensuite, nos chaînes de l'exemple précédent seront des cliques dans un graphique. Mais c'est tout simplement trop complexe. Mon idée principale dans cet article est de prêcher la simplicité, pas de construire un modèle précis de complexité. C'est vrai pour les systèmes comme pour les articles de blog. Espérons qu'un modèle inexact mais simple contribuera à renforcer le message à emporter. La complexité a un caractère exponentiel. Soyez conscient du danger que cela représente.

Remerciements

Un grand merci à Pol Miro Omella , Yanai Ron , Nimrod Shai et Roy Green pour leurs critiques et commentaires perspicaces.