- Dans la culture de l’ingénierie logicielle, ceux qui construisent des systèmes complexes sont davantage reconnus, tandis que ceux qui choisissent une solution simple restent peu valorisés
- Dans les évaluations de promotion, les entretiens et les revues de conception, la complexité est souvent prise à tort pour de l’« impact », ce qui renforce la tendance à ajouter des abstractions et de l’extensibilité inutiles
- Une implémentation simple reste souvent une « réussite invisible », alors qu’une structure complexe remplit facilement un dossier de promotion grâce à un récit flatteur et à une documentation abondante
- La véritable maîtrise ne consiste pas à utiliser davantage d’outils, mais à avoir le discernement et la confiance nécessaires pour savoir quand écarter la complexité
- Les ingénieurs comme les responsables doivent rendre la simplicité visible et créer des systèmes d’évaluation et de récompense qui la reconnaissent officiellement
Simplicité vs complexité : l’asymétrie du récit de promotion
- Exemple de deux ingénieurs dans la même équipe : Engineer A livre une fonctionnalité en quelques jours avec 50 lignes de code concises ; Engineer B met trois semaines à terminer en introduisant une nouvelle couche d’abstraction, un système pub/sub et un framework de configuration
- Le travail d’Engineer B peut être décrit dans un dossier de promotion comme « conception d’une architecture évolutive orientée événements, introduction d’une couche d’abstraction réutilisable, mise en place d’un framework de configuration »
- Celui d’Engineer A se résume à trois mots : « implémentation de la fonctionnalité X »
- En réalité, c’était le meilleur travail, mais comme il a été rendu simple en apparence, il devient une contribution invisible
- Personne n’est promu pour la “complexité évitée” — si la complexité paraît intelligente, c’est parce que le système d’évaluation est conçu pour la récompenser
Comment la complexité est renforcée dans les entretiens et les revues de conception
- Dans un entretien de system design, si vous proposez une solution simple (une base de données unique, une API intuitive, une couche de cache), l’intervieweur met la pression avec : « Et si vous aviez dix millions d’utilisateurs ? »
- Plus on ajoute de services, de files de messages et de sharding, plus on a l’impression de satisfaire l’intervieweur
- La leçon retenue par le candidat : « une réponse simple ne suffisait pas »
- L’intervieweur peut avoir des raisons légitimes d’insister (évaluer la réflexion sous pression, la compréhension des systèmes distribués), mais le message perçu par le candidat reste : « la complexité impressionne »
- Dans les revues de conception aussi, le schéma se répète : face à la question « Ne faudrait-il pas anticiper l’avenir (future-proof) ? », on finit par ajouter des couches et des abstractions inutiles
- Non pas parce que le problème l’exige, mais parce que c’est ce que la salle attend
- On voit souvent des abstractions créées pour éviter quelques lignes de code dupliquées, qui au final rendent la compréhension et la maintenance plus difficiles
- Le code avait l’air plus « professionnel », mais les utilisateurs n’ont pas reçu la fonctionnalité plus vite, et l’ingénieur suivant a passé une demi-journée à comprendre l’abstraction avant de pouvoir modifier quoi que ce soit
Complexité justifiée vs complexité inutile (Unearned Complexity)
- La complexité n’est pas un problème en soi — traiter des millions de transactions nécessite des systèmes distribués, et quand 10 équipes construisent le même produit, il faut des frontières de service
- Le problème, c’est la complexité inutile : il y a une différence entre « il faut du sharding parce qu’on a atteint les limites de la base de données » et « faisons du sharding maintenant parce qu’on pourrait atteindre ces limites dans trois ans »
- Le code et l’architecture des ingénieurs qui comprennent cela donnent une impression d’évidence : rien de magique, rien d’astucieux à exhiber, et aucun sentiment d’être idiot parce qu’on ne comprend pas
- La vraie voie vers le niveau senior ne consiste pas à apprendre toujours plus d’outils et de patterns, mais à savoir quand ne pas les utiliser — n’importe qui peut ajouter de la complexité, mais l’en retirer demande de l’expérience et de la confiance
Pistes d’action pour les ingénieurs
- Il faut rendre la simplicité visible — le travail ne parle pas de lui-même, parce que le système d’évaluation n’est pas conçu pour l’entendre
- Au lieu d’écrire « implémentation de la fonctionnalité X », écrivez plutôt : « après avoir évalué trois approches, dont une architecture orientée événements et une couche d’abstraction personnalisée, j’ai conclu qu’une implémentation simple répondait aux besoins actuels et prévisibles ; elle a été livrée en 2 jours et a tourné 6 mois sans incident »
- Décider de ne pas construire quelque chose est aussi une décision, et une décision importante — elle doit être documentée comme telle
- En revue de conception, face à « ne faut-il pas anticiper l’avenir ? », ne cédez pas immédiatement ; expliquez plutôt : « l’ajouter plus tard coûterait tant, l’ajouter maintenant coûterait tant, il vaut mieux attendre »
- Ce n’est pas de la contradiction, c’est la preuve que l’analyse a bien été faite
- Parlez directement à votre manager : « je veux que la façon de documenter mon travail reflète non seulement le code, mais aussi les décisions que j’ai prises »
- Du point de vue du manager aussi, cela lui donne un vocabulaire pour défendre ce travail
- Si, malgré tous ces efforts, l’équipe ne promeut que ceux qui construisent les systèmes les plus sophistiqués, c’est aussi une information utile — certaines organisations accordent réellement de la valeur à la simplicité, tandis que d’autres le disent tout en récompensant l’inverse
Pistes d’action pour les responsables d’ingénierie
- Définir les incitations est de la responsabilité des responsables — la plupart des critères de promotion sont conçus pour récompenser la complexité, et l’« impact » est souvent mesuré à l’échelle et à l’étendue de ce qui a été construit
- Il faut évaluer non seulement ce qui a été construit, mais aussi ce qui a été évité
- En revue de conception, au lieu de demander « avez-vous pris en compte la scalabilité ? », demandez plutôt : « quelle est la version la plus simple que l’on peut mettre en production, et quels signaux concrets indiqueraient qu’une solution plus complexe devient nécessaire ? »
- Cette seule question change la donne : la simplicité devient l’option par défaut, et la charge de la preuve revient à la complexité
- Lors des discussions de promotion, face à un dossier composé d’une liste de systèmes impressionnants, il faut aussi demander : « était-ce vraiment nécessaire ? Le système pub/sub était-il réellement utile, ou avait-il surtout belle allure sur le papier ? »
- Lorsqu’un membre de l’équipe livre quelque chose de propre et simple, il faut l’aider à construire son récit — « a évalué plusieurs approches et choisi la plus simple pour résoudre le problème » ne devient un argument convaincant pour une promotion que si le responsable le traite réellement comme tel
- Faites attention à ce que vous célébrez publiquement dans les canaux d’équipe — si vous ne félicitez que les grands projets complexes, les gens s’optimiseront pour cela
- Il faut reconnaître l’ingénieur qui a supprimé du code, celui qui a dit « ce n’est pas encore nécessaire » et qui avait raison
Aucun commentaire pour le moment.