Ce billet de blog explore un problème subtil mais persistant dans les équipes d'ingénierie : la valorisation excessive de la complexité au détriment de la simplicité. L'auteur observe que les ingénieurs qui sur-ingénierisent leurs solutions sont souvent mieux récompensés et promus que ceux qui livrent des solutions simples et efficaces. Ce biais se manifeste dans les entretiens d'embauche, les évaluations de promotion et les revues de conception. La complexité est perçue comme plus intelligente et impressionnante, même si elle n'est pas nécessaire, tandis que la simplicité, bien que souvent plus efficace, est moins visible et moins valorisée. L'auteur appelle à une réévaluation de ces systèmes de récompense pour encourager la simplicité et éviter les pièges de la complexité inutile.
Cet article remet en question l'idée reçue que Kubernetes est uniquement utile pour les grandes entreprises comme Netflix ou Google. Il rappelle que les problématiques d'infrastructure (tolérance aux pannes, déploiements fréquents, flexibilité, etc.) existent dès qu'une équipe gère plusieurs applications en production, indépendamment de la taille de l'entreprise. L'auteur décrit les solutions utilisées avant Kubernetes, comme le load balancing avec HAProxy et Keepalived, et les défis liés au service discovery et aux rollouts, soulignant la complexité de ces tâches sans un outil comme Kubernetes.
Chez Les-Tilleuls.coop, on réhabilite la maintenance logicielle, souvent perçue comme une corvée, mais qui est en réalité une discipline exigeante et formatrice. Contrairement à la création ex nihilo, la maintenance confronte au réel, aux imprévus et à la complexité, tout en étant un travail invisible et préventif. Elle enseigne la résilience, l'empathie et l'importance de concevoir des systèmes durables. Dans un monde obsédé par l'innovation, la maintenance est un acte écologique et économique, permettant de faire durer les projets au-delà de leur phase initiale.
L'auteur décrit une méthodologie (décrite dans le livre "Team topologies") pour répartir les équipes de développement en fonction de la complexité des domaines (au sens DDD), des relations entre domaines, etc. de manière à réguler la charge cognitive.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Comme le dit l'auteur, la notation Big O est une mesure pour savoir combien de temps prendra l'ordinateur pour faire quelque chose.
La complexité qui ne peut-être débuguée est un péché d’orgueil, pas forcément celui du développeur.