Comment de bons ingénieurs écrivent du mauvais code dans les grandes entreprises

Par Sean Goedecke

Comment de bons ingénieurs écrivent du mauvais code dans les grandes entreprises, par Sean Goedecke

Tous les deux ou trois ans, quelqu'un remarque que les grandes entreprises technologiques produisent parfois du code étonnamment bâclé. Si vous n'avez jamais travaillé dans une grande entreprise, il peut être difficile de comprendre comment cela se produit. Les grandes entreprises technologiques paient suffisamment bien pour attirer de nombreux ingénieurs compétents. Elles évoluent suffisamment lentement pour donner l'impression qu'elles peuvent prendre leur temps et faire un travail solide. Comment se fait-il que le code soit mauvais ?

La plupart des modifications du code sont effectuées par des débutants

Je pense que la raison principale est que les grandes entreprises regorgent d'ingénieurs qui travaillent en dehors de leur domaine d'expertise. En moyenne, les employés des grandes entreprises technologiques ne restent qu'un an ou deux. En fait, les rémunérations des grandes entreprises technologiques sont généralement conçues pour limiter à quatre ans la durée d'emploi des ingénieurs : après quatre ans, l'attribution initiale d'actions est entièrement acquise, ce qui entraîne une baisse de salaire pouvant atteindre 50 % pour les ingénieurs. Les entreprises prolongent certes temporairement les renouvellements annuels, mais cela incite évidemment les ingénieurs à chercher un autre emploi où ils n'auront pas à se demander s'ils vont toucher la seconde moitié de leur rémunération chaque année.

Si l'on tient compte de la mobilité interne, la situation est encore pire. La plus longue période que j'ai passée dans une même équipe ou sur une même base de code a été de trois ans, au début de ma carrière. Je m'attends à être réorganisé au moins une fois par an, et souvent beaucoup plus fréquemment.

Cependant, la durée moyenne d'une base de code dans une grande entreprise technologique est beaucoup plus longue que cela. Bon nombre des services sur lesquels je travaille ont plus de dix ans et ont connu de nombreux propriétaires différents au fil des ans. Cela signifie que de nombreux ingénieurs des grandes entreprises technologiques sont constamment en train de « comprendre ». Un pourcentage assez élevé des modifications de code est effectué par des « débutants » : des personnes qui ont rejoint l'entreprise, la base de code ou même le langage de programmation au cours des six derniers mois.

Les anciens

Dans une certaine mesure, ce problème est atténué par les « anciens » : des ingénieurs qui ont suffisamment longtemps évolué dans l'orbite d'un système particulier pour développer une véritable expertise. Ces ingénieurs peuvent effectuer des révisions approfondies du code et détecter de manière fiable les problèmes évidents. Mais s'appuyer sur les « anciens » pose deux problèmes.

Tout d'abord, ce processus est entièrement informel. Les grandes entreprises technologiques font étonnamment peu d'efforts pour développer une expertise à long terme dans des systèmes individuels, et une fois qu'elles l'ont acquise, elles semblent se soucier très peu de la conserver. Souvent, les ingénieurs en question sont mutés vers d'autres services et doivent soit continuer à assumer leurs fonctions de « vétérans » sur une base volontaire, soit les abandonner et devenir des débutants relatifs sur un tout nouveau système.

Deuxièmement, les ingénieurs expérimentés sont toujours surchargés. Être l'un des rares ingénieurs à posséder une expertise approfondie d'un service particulier est un travail très prenant. Vous n'avez pas assez de temps pour examiner personnellement chaque modification logicielle ou pour participer activement à chaque processus décisionnel. N'oubliez pas que vous avez également votre propre travail à faire : si vous passez tout votre temps à examiner les modifications et à participer aux discussions, vous risquez d'être sanctionné par l'entreprise pour ne pas avoir un rendement individuel suffisant.

L'ingénieur productif médian

En résumé, à quoi ressemble l'ingénieur productif médian dans une grande entreprise technologique ? Il est généralement :

- suffisamment compétent pour passer le cap du recrutement et être capable de faire le travail, mais soit

- il travaille sur un code ou un langage qui lui est largement inconnu, soit

- il essaie de rester à jour face à un flot de modifications de code tout en jonglant avec son propre travail.

Il travaille presque certainement avec une échéance, ou une série d'échéances qui se chevauchent pour différents projets. En d'autres termes, il essaie de faire de son mieux dans un environnement qui n'est pas conçu pour produire un code de qualité.

C'est ainsi que naissent les codes « manifestement » mauvais. Par exemple, un ingénieur junior reçoit un ticket pour un bug gênant dans une base de code qu'il connaît à peine. Il passe quelques jours à le comprendre et trouve une solution de fortune. L'un des « anciens » plus expérimentés (s'il a de la chance) y jette un coup d'œil pendant une demi-heure, le rejette et suggère une solution légèrement meilleure qui fonctionnerait au moins. Le jeune ingénieur la met en œuvre du mieux qu'il peut, teste son fonctionnement, elle est brièvement révisée et livrée, et toutes les personnes impliquées passent immédiatement à des tâches plus prioritaires. Cinq ans plus tard, quelqu'un remarque cela et se dit « waouh, c'est bricolé - comment un code aussi mauvais a-t-il pu être écrit dans une si grande entreprise de logiciels » ?

Les grandes entreprises technologiques s'en accommodent très bien

J'ai beaucoup écrit sur les dynamiques internes des entreprises technologiques qui contribuent à cette situation. Plus directement, dans Seeing like a software company, j'affirme que les grandes entreprises technologiques privilégient systématiquement la lisibilité interne (la capacité de voir d'un seul coup d'œil qui travaille sur quoi et de modifier cela à volonté) plutôt que la productivité. Les grandes entreprises savent que traiter les ingénieurs comme des éléments interchangeables et les déplacer détruit leur capacité à développer une expertise à long terme dans une base de code unique. C'est un compromis délibéré. Elles renoncent à une certaine expertise et à une certaine qualité logicielle afin de pouvoir déployer rapidement des ingénieurs qualifiés sur le problème du mois.

Je ne sais pas si c'est une bonne ou une mauvaise idée. Cela semble certainement fonctionner pour les grandes entreprises technologiques, en particulier maintenant que « la rapidité avec laquelle vous pouvez vous orienter vers quelque chose lié à l'IA » est si importante. Mais si vous faites cela, vous allez bien sûr produire du code vraiment mauvais. C'est ce qui se passe lorsque vous demandez aux ingénieurs de se précipiter sur des systèmes qu'ils ne connaissent pas.

Les ingénieurs individuels sont totalement impuissants à modifier cette dynamique. Cela est particulièrement vrai en 2025, où l'équilibre des pouvoirs s'est déplacé des ingénieurs vers les dirigeants des entreprises technologiques. Le mieux que vous puissiez faire en tant qu'ingénieur individuel est d'essayer de devenir un « ancien » : développer une expertise dans au moins un domaine et l'utiliser pour bloquer les pires changements et orienter les gens vers des décisions techniques au moins minimement sensées. Mais même cela revient souvent à nager à contre-courant de l'organisation, et si cela est fait de manière inexpérimentée, cela peut vous valoir un PIP (plan d'amélioration des performances) ou pire encore.

Ingénierie pure et impure

Je pense que cela tient en grande partie à la distinction entre l'ingénierie logicielle pure et impure. Pour les ingénieurs purs, c'est-à-dire ceux qui travaillent sur des projets techniques autonomes, comme un langage de programmation, la seule explication à un mauvais code est l'incompétence. Mais les ingénieurs impurs fonctionnent davantage comme des plombiers ou des électriciens. Ils travaillent dans des délais impartis sur des projets qui sont relativement nouveaux pour eux, et même si leurs bases techniques sont impeccables, il y a toujours quelque chose dans la configuration particulière de cette situation qui est délicat ou surprenant. Pour les ingénieurs impurs, un mauvais code est inévitable. Tant que le système global fonctionne suffisamment bien, le projet est un succès.

Dans les grandes entreprises technologiques, les ingénieurs ne peuvent pas décider s'ils travaillent sur des tâches d'ingénierie pures ou impures. Ce n'est pas leur base de code ! Si l'entreprise souhaite vous faire passer du travail sur l'infrastructure de la base de données à la création d'un nouveau système de paiement, elle en a tout à fait le droit. Le fait que vous puissiez commettre des erreurs dans un système qui ne vous est pas familier, ou que vos anciens collègues de l'équipe chargée de l'infrastructure de la base de données puissent souffrir de l'absence de votre expertise, est un compromis délibéré fait par l'entreprise, et non par l'ingénieur.

Il n'y a rien de mal à signaler des exemples de mauvais code dans les grandes entreprises. Cela peut être un moyen efficace de faire corriger ces exemples spécifiques, car les dirigeants sautent généralement sur l'occasion de transformer un mauvais PR en bon PR. Mais je pense que c'est une erreur d'attribuer la responsabilité principale aux ingénieurs de ces entreprises. Même si vous pouviez agiter une baguette magique et rendre chaque ingénieur deux fois plus performant, vous auriez toujours du mauvais code, car presque personne ne peut se lancer dans une base de code entièrement nouvelle et y apporter rapidement des modifications sans faire la moindre erreur. La cause profonde est que la plupart des ingénieurs des grandes entreprises sont contraints d'effectuer la majeure partie de leur travail dans des bases de code qui ne leur sont pas familières.

Source : "How good engineers write bad code at big companies"

Et vous ?

Pensez-vous que ces affirmations sont crédibles ou pertinentes ?
Quel est votre avis sur le sujet ?

Voir aussi :

Lors de la conception de systèmes logiciels, faites la chose la plus simple qui puisse fonctionner, par Sean Goedecke

10 commandements pour l'excellence du génie logiciel, par Mensur Durakovic

Développement de logiciels à long terme, par Bert Hubert