- 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
Aucun commentaire pour le moment.