L’article souligne les risques de l’anticipation excessive dans le développement logiciel, où la complexité naît souvent de besoins hypothétiques plutôt que réels. L’auteur illustre ce propos avec un exemple concret : une fonctionnalité rendue paramétrable par prudence, mais jamais utilisée, entraînant deux ans de maintenance inutile. Cette approche, bien que courante, alourdit inutilement les systèmes en augmentant le temps de développement, les risques de bugs et la difficulté de maintenance.
L’auteur explique que les abstractions prématurées, comme des interfaces génériques ou des systèmes de configuration superflus, compliquent le code sans apporter de valeur réelle. Ces choix, motivés par une anticipation incertaine, rendent souvent le logiciel plus difficile à comprendre et à faire évoluer. De plus, la solution imaginée pour un besoin hypothétique peut s’avérer inadaptée, forçant des adaptations coûteuses plutôt qu’une refonte optimale.
Pour éviter ces écueils, l’auteur prône un principe simple : construire uniquement ce qui est nécessaire aujourd’hui, en se basant sur des besoins avérés plutôt que sur des scénarios futurs incertains. Cette approche réduit la complexité, facilite la maintenance et permet d’adapter le code plus efficacement lorsque les besoins réels se présentent.
L’article explique que la lenteur des équipes techniques est souvent attribuée à tort aux compétences des développeurs, alors qu’elle provient principalement de la complexité du codebase. L’auteur, Ally Piechowski, introduit le concept de codebase drag (frottement du codebase), où la dette technique et les choix d’architecture alourdissent les tâches quotidiennes, comme illustré par l’exemple d’une équipe ayant passé une semaine sur une fonctionnalité simple à cause d’un code mal structuré.
L’auteur identifie cinq signaux révélateurs d’un codebase problématique, dont les estimations gonflées et la peur des déploiements. Par exemple, des équipes reportent systématiquement les déploiements par crainte de générer des incidents, ce qui reflète un manque de fiabilité du code et des processus. Ces problèmes ne sont pas résolus par des réorganisations ou des embauches, mais nécessitent un investissement direct dans la refonte du code.
L’article propose un audit interactif pour évaluer l’impact du codebase sur la productivité, soulignant que les équipes sous-estiment souvent l’ampleur des coûts cachés liés à un code mal conçu. La solution passe par une prise de conscience de ces dysfonctionnements et une priorisation de la maintenance technique pour réduire le codebase drag.
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.