Pourquoi des ingénieurs talentueux écrivent du mauvais code dans les grandes entreprises
(seangoedecke.com)- En raison de durées de présence courtes et de fréquentes réorganisations dans les grandes entreprises technologiques, beaucoup d’ingénieurs travaillent sur des bases de code qu’ils ne connaissent pas bien
- Une part importante des modifications de code est en pratique réalisée par des ingénieurs “débutants” présents depuis moins de 6 mois
- Quelques ingénieurs “old hand” expérimentés compensent partiellement les problèmes de qualité, mais ils se heurtent à leurs limites à cause d’une surcharge de travail et de responsabilités informelles
- Les entreprises privilégient la mobilité des effectifs et la lisibilité interne (legibility) plutôt que l’expertise, ce qui correspond à un compromis assumé au détriment de la qualité
- En conséquence, indépendamment des compétences individuelles, la cause profonde du mauvais code est un problème structurel : travailler vite sur des systèmes peu familiers pour respecter des délais serrés
La structure qui produit du mauvais code dans les grandes entreprises
- Les grandes entreprises tech recrutent des ingénieurs talentueux avec des salaires élevés, mais leur durée de présence n’est souvent que de 1 à 2 ans
- Les stock options ou actions (share grant) n’atteignent leur acquisition complète qu’au bout de 4 ans, après quoi la rémunération peut être divisée par deux
- Il existe parfois des refresh annuels, mais ils ne sont pas garantis, ce qui pousse les ingénieurs à changer d’entreprise
- Même en tenant compte de la mobilité interne, rester plus de 3 ans sur une même base de code est rare
- Les réorganisations (re-org) ont lieu chaque année, voire plus souvent
- À l’inverse, les bases de code vivent souvent plus de 10 ans, si bien que la plupart des ingénieurs sont encore en train d’apprivoiser un nouveau système
- En conséquence, une part significative des modifications est effectuée par des nouveaux arrivants de moins de 6 mois
Le rôle et les limites des “old hands”
- Certains ingénieurs restent longtemps sur un système donné et acquièrent une expertise approfondie
- Ils peuvent repérer tôt les problèmes via la revue de code
- Mais cette structure est informelle et non institutionnalisée
- Les entreprises s’intéressent peu au maintien d’une expertise de long terme et déplacent souvent les profils expérimentés vers d’autres équipes
- Les profils expérimentés sont en permanence surchargés
- Ils n’ont pas le temps d’examiner directement toutes les modifications
- Si leurs propres résultats baissent, ils risquent même d’en subir les conséquences
La réalité de l’ingénieur productif moyen
- Dans une grande entreprise, l’ingénieur productif moyen présente généralement les caractéristiques suivantes
- Il est suffisamment compétent pour avoir passé le processus de recrutement, mais ne connaît pas encore bien une nouvelle base de code ou un nouveau langage
- Il travaille en parallèle sur plusieurs projets avec des échéances qui se chevauchent
- Le résultat est un environnement où le calendrier prime sur la qualité
- Exemple : un ingénieur débutant corrige à la va-vite un bug dans un code qu’il connaît mal, puis un profil expérimenté fait une revue rapide avant le déploiement
- Des années plus tard, en retombant sur ce code, on se demande : « pourquoi cela a-t-il été écrit ainsi ? »
Pourquoi les entreprises maintiennent cette structure
- Les grandes entreprises accordent plus d’importance à la lisibilité interne (legibility) qu’à la productivité
- Elles préfèrent une organisation où l’on sait qui fait quoi et où les personnes peuvent être réaffectées à tout moment
- C’est un choix délibéré qui sacrifie l’expertise et la qualité du code
- Elles acceptent la perte de savoir-faire en échange d’une flexibilité permettant de redéployer rapidement les effectifs en cas de besoin
- Cette stratégie est particulièrement avantageuse pour les entreprises lorsque des bifurcations rapides (pivot) vers de nouveaux domaines, comme l’IA, deviennent importantes
- Mais dans un tel environnement, il est inévitable que de nombreux ingénieurs travaillent dans l’urgence sur des systèmes qu’ils connaissent mal
Les limites individuelles de l’ingénieur et l’ingénierie “pure” / “impure”
- Un ingénieur isolé n’a pas le pouvoir de changer cette structure
- En 2025, le centre du pouvoir s’est déplacé des ingénieurs vers le management
- Le mieux qu’un individu puisse faire est de devenir un “old hand” dans un domaine précis afin de préserver un minimum de qualité
- Mais s’impliquer excessivement peut au contraire exposer à un risque d’évaluation pour sous-performance (PIP)
- Le texte propose une distinction entre ingénierie “pure” et “impure”
- Ingénierie pure : projets techniques indépendants, par exemple le développement d’un langage de programmation
- Ingénierie impure : environnement réel, centré sur les délais, dans des systèmes peu familiers
- La plupart des ingénieurs en grande entreprise relèvent de l’ingénierie impure, et dans ce cadre, le mauvais code est un sous-produit inévitable
- Si le système fonctionne suffisamment bien, le projet est considéré comme un succès
Conclusion : la “base de code peu familière” comme cause structurelle
- Les grandes entreprises ont le pouvoir de déplacer librement les ingénieurs, et c’est un choix d’entreprise assumant la perte d’expertise
- La responsabilité du mauvais code ne relève pas des individus, mais de la structure organisationnelle et du mode de gestion des effectifs
- Même en doublant les compétences de tous les ingénieurs, les erreurs dans des bases de code peu familières continueraient d’exister
- La cause fondamentale est la suivante : « la plupart des ingénieurs doivent effectuer l’essentiel de leur travail dans un code qu’ils ne maîtrisent pas vraiment »
- Pointer des exemples de mauvais code peut aider à améliorer les choses, mais ce n’est pas l’ingénieur qu’il faut blâmer, c’est le système
5 commentaires
D’après mon expérience, quand on a de bonnes bases en informatique, surtout en PLT, on finit par écrire un code relativement meilleur, quel que soit l’environnement.
Même sans connaissances extraordinaires, quelqu’un qui comprend simplement les principes les plus fondamentaux peut produire un code d’une certaine qualité s’il a suffisamment de temps et travaille sur un code qu’il connaît bien. Après n cycles de refactoring, même du code généré par une IA peut devenir assez convaincant.
À l’inverse, il y a aussi beaucoup de gens qui peuvent passer un temps infini sur un même code source, se dire seniors avec 20 ans d’expérience, et ne savoir faire que du spaghetti code, sans même comprendre pourquoi il ne faut pas faire comme ça.
À moins de disposer d’un environnement parfait avec un temps et un budget illimités, tout cela me paraît assez creux et sans grande portée. Peu importe l’époque ou le poste, ce n’est pas toujours la même histoire ?
Écrire un meilleur code dans un même système, c’est clairement une compétence d’ingénieur.
Ce serait bien que le système soit conçu avec suffisamment de marge et de souplesse pour pouvoir offrir une bonne qualité. Et, bien sûr, en moyenne, c’est probablement davantage le cas aujourd’hui qu’à une époque où l’ingénierie organisationnelle et les méthodologies de développement étaient moins avancées qu’aujourd’hui.
Cela dit, à mes yeux, cela ressemble à quelqu’un dont l’ego en tant qu’ingénieur est surdimensionné, mais dont le sens des responsabilités en tant que membre d’une organisation est insuffisant, et qui se cherche des excuses en disant que tout cela n’est pas de sa faute mais de celle de la direction.
Les architectes, les designers industriels et les animateurs n’ont-ils pas de délais, et ne sont-ils évalués que sur la créativité et la qualité, plutôt que sur la productivité, alors qu’il n’y aurait que les programmeurs qui auraient des délais ?
Il y a vraiment n’importe quoi là-dedans… parler de mauvais code ou de bon code, c’est un truc que racontent les juniors ; ce qui compte davantage, c’est de savoir s’il y a, ou non, des seniors capables de bien concevoir des logiciels adaptés à ce secteur..
Les textes publiés ici peuvent relever d’un environnement quelque peu différent de certains points de vue ou expériences du marché national du SI, où même l’OCP est souvent ignoré.
Quoi qu’il en soit, Linus Torvalds n’est pas un junior…
Avis Hacker News
J’ai lu les textes de cette personne plusieurs fois, et il m’en est toujours resté une sorte de malaise
Je crois comprendre maintenant pourquoi. L’analyse en elle-même est logique, mais elle semble reposer sur une forme de nihilisme
C’est sans doute quelqu’un qui a été idéaliste autrefois, mais qu’une mauvaise expérience a conduit à expliquer qu’« il est vain de croire en quoi que ce soit »
D’où cette question — pourquoi les grandes entreprises doivent-elles agir ainsi, pourquoi le mauvais code fait-il tant souffrir les ingénieurs, ce sentiment est-il vraiment déplacé, ou bien est-ce la faute de la structure économique dans laquelle nous vivons, ou encore le fait de se plier à une force immense est-il une forme de maturité ?
Parce que c’est moi qui dois en assumer les conséquences.
Le planning dérape parce que je dois réparer le code bancal écrit par quelqu’un d’autre, et à cause de ça mon évaluation de fin d’année en prend un coup
On me demande « pourquoi cela a pris si longtemps », mais c’est parce que j’ai dû fouiller dans un tas d’ordures pour trouver le problème
J’ai essayé pendant des années de faire comprendre ce problème au management, mais au final cela a ressemblé à un travail de Sisyphe
De la même façon qu’un architecte souffre en voyant un bâtiment bâclé, ou qu’un réalisateur est peiné devant un mauvais film, un bon ingénieur recherche le travail bien fait
La maturité ne consiste pas à se résigner à l’impuissance, mais à se battre autant que possible
Fait intéressant, on qualifie l’auteur de nihiliste, mais l’idée même que « le monde est hors de contrôle » est déjà une pensée nihiliste
Avant, moi aussi je pensais que tout code imparfait était mauvais, mais mon point de vue a changé après être passé par plusieurs entreprises
Désormais, je considère qu’un code qui remplit les objectifs business et dépasse un seuil minimal de qualité est acceptable
Au fond, presque tout code peut être amélioré
J’ai trouvé que cela décrivait exactement la dure réalité du Staff+ engineering
L’idée de « faire ce que l’entreprise veut, même si ce n’est pas juste » est cynique, mais je pense que c’est encore mieux que de se faire broyer par les rouages de l’entreprise
Il ne croit simplement pas en vos idéaux, ce qui ne fait pas automatiquement de lui un nihiliste
Le problème n’est pas l’ancienneté, mais la motivation
Cela rappelle la réplique du film Office Space : si travailler dur n’apporte aucune récompense, la motivation disparaît
Mais le management accorde plus d’importance aux résultats qu’au bon code
Comme il ne sait pas évaluer la valeur de la maintenance, ce travail n’est pas reconnu
Au final, c’est celui qui a livré du code bancal qui se fait promouvoir
Je tenais à mon équipe et à mon code, et je travaillais avec soin, mais au final j’étais évalué sur des métriques simplistes comme le nombre de PR
La difficulté du code ou la contribution à l’équipe étaient ignorées, et seuls comptaient les « chiffres visibles »
Finalement, le manager qui m’évaluait a lui aussi été licencié quelques mois plus tard
Ironiquement, si j’avais été indifférent, je n’aurais pas été blessé par ce genre de choses
Les grandes entreprises traitent les ingénieurs comme des ressources interchangeables
Ce n’est pas seulement une question d’efficacité, c’est aussi une stratégie visant à faire pencher l’équilibre du pouvoir du côté du management
L’objectif est d’éviter que des projets critiques dépendent d’un groupe précis d’ingénieurs
Il veut que chaque travailleur soit remplaçable
Au contraire, elle cherche souvent à retenir les bons ingénieurs
Autrement dit, cette culture n’est pas uniquement un problème de management
Je vois souvent du code dont la syntaxe et la structure sont conformes aux manuels, mais où l’approche de fond est mauvaise
Les code reviews se concentrent uniquement sur la syntaxe, sans discussion sur le problème business ni sur la complexité
À court terme cela passe, mais à long terme la dette technique explose
Résultat : des débats mineurs sur la qualité du code retardent les PR pendant des jours
Tout le monde s’obsède pour la propreté superficielle du code
Il est difficile d’évaluer la solidité logique ou la vision d’ensemble, et il arrive souvent que le reviewer manque de contexte
Si l’organisation dans son ensemble n’a pas la marge nécessaire pour absorber ce type de feedback, elle finit par dépendre d’un « système qui tourne tant bien que mal »
Les grandes décisions de conception devraient être examinées avant la code review
En d’autres termes, nous sommes en train d’automatiser les coûts à long terme
Les grandes entreprises ne s’intéressent pas au code en lui-même
Le code n’est qu’un moyen de faire tourner l’entreprise
Au final, ce qui compte, ce n’est pas le code mais le processus
La vraie question est de savoir s’il existe des procédures permettant de rétablir le système quand il tombe en panne
Tous les secteurs finissent par faire des compromis similaires à grande échelle
Ce n’est pas la perfection, mais une qualité « suffisamment bonne » qui génère du profit
Comme pour la différence entre une chaise IKEA et une chaise Herman Miller, tout dépend simplement des contraintes
La vraie compétence consiste à savoir où faire des compromis
La structure des grandes entreprises impose ce type de compromis aux ingénieurs
Un bon ingénieur senior n’écrit pas du mauvais code dès le départ
Le vrai problème, c’est la pression du court terme et le manque de bases solides
Le fait de sauter les reviews ou de ne pas assez réfléchir à l’architecture en est la cause principale
Comme le décrit ce commentaire, quand on travaille sur une base de code de plusieurs millions de lignes accumulant les hacks, on ne peut pas la rendre propre malgré tous ses efforts
On finit simplement par soulever tout le plat de spaghettis
Un senior est toujours face au dilemme entre « bien faire » et « finir vite »
On ne peut pas comprendre une base de code complexe du jour au lendemain, et si l’organisation ne valorise pas l’accumulation des connaissances, la qualité se dégrade
Il est utile de confier aux nouveaux arrivants des tâches de documentation ou de remise en ordre pour leur faire apprendre la structure du code
Même s’il existe beaucoup de vieux hacks dans le code, on ne peut pas y toucher si on ne peut pas se permettre de les casser
Même la meilleure conception s’effondre quand ses fondations reposent sur du sable
La conclusion de l’auteur, selon laquelle « la lisibilité passe avant la qualité », implique alors que tous les projets de grandes entreprises devraient obligatoirement utiliser des outils d’analyse statique et des formatters automatiques
Mais dans la réalité, ce n’est pas le cas
L’adoption de ces outils dépend de décisions de managers non techniques, et ils détestent les coûts à court terme
Au final, le calendrier de sortie écrase tout le reste
Lors d’une mission de conseil dans un grand groupe industriel, il y avait dans tout le code des patterns de modélisation objet étranges
En remontant à la source, on a découvert que l’équipe de développement avait complètement mal compris le concept prévu par le concepteur (blueprint–mold–product)
J’ai proposé de le corriger, mais la réponse a été : « il est déjà trop tard »
Résultat : pendant plus de 10 ans, ce modèle erroné a été conservé et a produit une énorme dette technique
Les statistiques sur la faible ancienneté moyenne dans les grandes entreprises sont trompeuses
Elles s’expliquent surtout par la forte croissance des effectifs, qui raccourcit la médiane
En réalité, il faut regarder les chiffres des personnes qui quittent l’entreprise pour avoir une image juste
Tout simplement parce qu’il y avait moins de développeurs par le passé