La plupart des problèmes techniques sont en réalité des problèmes humains
(blog.joeschrag.com)- Dans les entreprises qui traînent une importante dette technique, l’inefficacité provient souvent de la duplication de code et de frameworks obsolètes
- Au cours d’un projet, la perte de confiance du management et la résistance au changement dans l’organisation deviennent des obstacles majeurs
- Les causes profondes de la dette technique sont des facteurs humains comme des exigences floues, des délais irréalistes, une préférence pour des technologies obsolètes, les réactions à court terme de la direction et l’ego individuel
- Pour qu’un projet réussisse, il faut non seulement des résultats techniques, mais aussi une bonne gestion de la perception et de la communication
- En plus de leurs compétences techniques, les ingénieurs doivent aussi savoir coopérer dans l’organisation et gérer les relations humaines
Dette technique et problème du code dupliqué
- Dans une entreprise où j’ai travaillé auparavant, il existait une grave dette technique avec plusieurs millions de lignes de code, l’absence de tests unitaires et l’usage de frameworks vieux de plus de 10 ans
- Pour faire tourner sous Linux un module réservé à Windows, des centaines de milliers de lignes de code ont été dupliquées par copier-coller
- Cela a créé deux bases de code distinctes, ce qui obligeait à gérer séparément l’ajout de fonctionnalités et la correction des bugs
- Ce type de situation mène à une architecture impossible à maintenir, et l’écart entre les deux codes s’aggrave avec le temps
La dette technique comme problème humain
- Il est difficile de convaincre la direction de lancer un projet de réduction de dette technique, car au final il modifie peu les fonctionnalités et produit donc peu de résultats visibles
- Le projet prend du retard, ce qui entraîne une perte de confiance du management
- Le cœur du problème n’est pas la technologie, mais l’attitude des personnes et la culture d’entreprise
- Beaucoup de développeurs résistent au changement et se contentent des anciennes méthodes
- La structure du code reflète la personnalité de son auteur et sa capacité à accepter le changement
- La dette technique naît d’exigences peu claires, de promesses irréalistes, de choix technologiques obsolètes, de décisions d’interruption prises par la direction et de l’ego personnel
- Plus une équipe a tendance à éviter le changement, plus cette résistance se reflète dans le code lui-même
- Plusieurs développeurs travaillaient depuis des années exactement de la même manière, et certains allaient jusqu’à dire : « Je n’ai pas envie d’apprendre quelque chose de nouveau »
- Dans un tel environnement, la dette s’accumule plus vite qu’on ne peut la résorber ; avant même de la réduire, il faut donc empêcher qu’elle continue de croître
- Comme dans le triage aux urgences, il faut d’abord “arrêter l’hémorragie”
L’écart entre le monde idéal et la réalité
- Il existe très rarement un environnement idéal où l’on peut résoudre des problèmes d’ingénierie en les séparant de leur contexte politique ou organisationnel
- La plupart des projets impliquent des parties prenantes non techniques
- Une attitude du type « Faites-nous confiance, on s’en occupe » ne fonctionne pas
- La gestion de la perception des résultats est aussi importante que les résultats eux-mêmes
- Les non-techniciens ne comprennent pas intuitivement la nécessité de traiter la dette technique ; il faut donc l’expliquer en valeur quantitative et métier
- Quand le leadership n’a pas de background en ingénierie, il faut montrer des chiffres visibles et des effets concrets
- Au final, le fait qu’une équipe paraisse productive est aussi important que sa productivité réelle
Les compétences nécessaires à un ingénieur senior
- À partir du niveau senior, la capacité à collaborer entre départements et à gérer les relations humaines devient indispensable
- Les formations en informatique n’enseignent pas vraiment la gestion des personnes, comme le caractère, l’ego ou les relations
- Même un ingénieur doté d’excellentes compétences techniques peut échouer face à des problèmes qui exigent des changements à grande échelle et à l’échelle de l’organisation
- Sa productivité individuelle peut être élevée, mais son influence organisationnelle reste limitée
- Le rôle de
Heads up coderest important- Une personne capable de conserver une forte profondeur technique tout en identifiant tôt les risques projet et en coordonnant l’équipe
- Au lieu de travailler seul très vite comme un cœur unique, elle oriente efficacement l’ensemble de l’équipe
- Contrairement à un ingénieur purement technique, elle sait avancer en lisant à la fois le contexte organisationnel et les risques
En résumé
- À la racine des problèmes techniques, il y a toujours des personnes
- La plupart des problèmes techniques se ramènent en fin de compte à des problèmes humains, culturels et de communication
- La dette technique n’est pas un problème de code, mais le résultat de schémas de comportement et d’une culture organisationnelle
- Pour la résoudre, il faut d’abord une acceptation du changement à l’échelle de l’organisation et une compréhension de la part du leadership
- Et il existe, plus loin dans la carrière, des problèmes plus vastes que l’excellence technique seule ne permet pas de résoudre
- Un véritable ingénieur senior est un leader équilibré qui sait conjuguer technique et compréhension de l’humain
2 commentaires
Avis Hacker News
J’ai constaté que la plupart des problèmes sont des problèmes de communication
Les ingénieurs sont coupés de la vision produit et des clients, et les équipes produit traitent les ingénieurs comme une simple équipe de sous-traitance interne
Les équipes commerciales et support client ne comprennent pas l’impact de leurs promesses sur la feuille de route produit
Au final, les objectifs et les indicateurs de succès divergent, et chacun rame dans une direction différente
La solution n’est pas d’avoir de « meilleures personnes », mais de faire en sorte que tout le monde soit investi dans le même objectif et comprenne comment son rôle s’articule avec l’ensemble
Il en va de même pour l’ancienne dette technique : l’ignorer ne la fait pas disparaître. Il faut chiffrer le coût et le risque qu’elle représente pour l’entreprise, l’équilibrer avec les autres objectifs, puis établir un plan pour la résorber
Les utilisateurs étant juste à côté, il s’agit de sessions où on les rencontre directement, on se lie à eux et on apprend leur quotidien ainsi que leur contexte
Elles sont planifiées automatiquement toutes les trois semaines et se déroulent sans action items formels. À chaque fois, les gens sont surpris, de petits bugs sont corrigés et des liens se créent
J’exploite cela avec un ordonnanceur automatique connecté à la Slack API, et la partie la plus difficile reste la coordination des agendas et l’incitation à participer
La direction n’écoute pas les subalternes, et les subalternes sont en compétition pour attirer l’attention
Récemment, dans notre service, un consultant a proposé de basculer vers une nouvelle plateforme ; personne n’était d’accord, mais il a été impossible d’arrêter le processus. Au final, personne n’écoute personne
À la question « pourquoi fait-on ça ? », on ne reçoit que des réponses du genre « fais-moi confiance »
Je ne pense pas que ce comportement des PM changera. C’est pourquoi des ingénieurs prennent eux-mêmes un rôle produit pour combler le fossé de communication
J’ai réalisé que beaucoup de gens, en réalité, ne sont pas fiers de leur travail
Pour certains, ce n’est qu’un salaire
Les collègues plus âgés, en particulier, ont déjà vu des systèmes s’effondrer et veulent éviter que cela se reproduise
Chaque fois que j’arrive dans un nouveau poste, j’essaie de poser des lignes directrices claires dans un plan à 90 jours, mais au fond tout repose sur l’équipe
Certaines équipes ont soif de changement, d’autres le bloquent
C’est encore plus difficile quand le leader est incompétent ou ne choisit que l’option la plus rapide et la moins chère
Cela m’a aussi rappelé des cas comme le scandale de la Post Office au Royaume-Uni, où le problème était connu en interne mais bloqué
Autrefois, plus de la moitié étaient indépendants ; aujourd’hui, il en reste à peine 10 %
Ce que nous produisons n’est plus « à nous », mais « à notre employeur »
Travailler davantage n’apporte pas de récompense ; au contraire, cela conduit souvent à hériter de plus de travail
Au final, les personnes sont traitées comme des ressources, puis jetées quand elles ne sont plus nécessaires
En cas de crise, ce sont les salariés qui sont licenciés en premier, pendant que le CEO touche des millions de dollars
Dans une telle structure, il est impossible d’attendre des employés qu’ils se dévouent à l’entreprise
Ceux qui travaillent moins sont mieux payés, et vous pouvez être licencié parce qu’un remplaçant coûte la moitié de votre salaire
Les entretiens deviennent de plus en plus exigeants, le mérite est volé, et l’inflation grignote les salaires
Au final, la question « pourquoi la fierté a-t-elle disparu ? » ressemble à un mystère, alors que la réponse est en réalité évidente
Mais les entreprises savent que la plupart des gens ne peuvent pas faire ce qu’ils veulent vraiment ; elles se concentrent donc sur les processus et workflows
Pour l’individu, le mieux est de faire ce qu’il aime tout en étant bien payé
Lorsqu’un développeur dit « je ne veux pas apprendre quelque chose de nouveau », ce n’est pas forcément une mauvaise chose
Il y a une différence entre la fatigue causée par des frameworks qui changent chaque jour, comme dans l’écosystème JavaScript, et la stabilité technique de Go ou des environnements basés sur des LTS
La stabilité aide aussi à l’agilité produit
Il faut parfois négocier avec des ingénieurs seniors qui gèrent une vieille codebase C++, mais qualifier cela simplement de dette technique est biaisé
Seuls le lead IC responsable de la codebase et le manager qui le supervise peuvent juger s’il s’agit ou non de dette technique
Évoquer des problèmes humains en entretien est un excellent moyen d’être recalé
Beaucoup d’intervieweurs considèrent que seules les réponses techniques sont bonnes et ignorent les intuitions humaines
Pour ma part, j’accorde au contraire beaucoup de valeur à cette perspective, mais je dois me battre avec mes collègues pour les convaincre
Quand j’ai dit que, selon le débit des messages, du batch processing pouvait suffire, il a conclu que « je ne connaissais pas les queues »
J’ai pourtant expliqué que je travaillais depuis plus de dix ans sur des produits de données à l’échelle du pétaoctet, mais j’ai été rejeté parce que cela ne collait pas à sa vision du system design
Aujourd’hui, cette équipe est en train de mettre tous les microservices derrière une seule API
Si l’équipe ne comprend pas cet équilibre, alors je n’ai pas besoin de la rejoindre
En tant que data engineer dans la Big Tech, les deux problèmes les plus difficiles sont les suivants
D’abord, à cause de la loi de Conway, chaque service a sa propre toolchain et sa propre philosophie de la donnée
Ensuite, chaque silo affirme que sa manière est la bonne tout en voulant les données des autres
La standardisation est impossible parce que les responsables de chaque division croient que leur méthode est la seule valable
En pratique, la plupart des approches sont à la fois justes et erronées
En apparence, cela ressemble à un problème technique, mais au fond c’est un problème humain
Aucun changement des systèmes amont n’est signalé ; on ne l’apprend que lorsque les alertes se déclenchent en aval
Il y a tellement de demandes improvisées que les sprints en deviennent vides de sens, et une masse énorme de connaissances n’est pas documentée
Ce genre d’expérience m’a donné envie d’étudier une informatique plus bas niveau
Pour conduire le changement, il faut construire un réseau, rassembler les gens et diffuser le changement en toute transparence
Mais pour qu’un vrai changement ait lieu, il faut le soutien de dirigeants de niveau supérieur, comme des directeurs ou des VP
AWS a publié un guide sur ce type de transformation organisationnelle, et AWS Prescriptive Guidance constitue un excellent plan directeur
On commence par dire « rassemblons tout le monde dans une solution unique », mais très vite cela se fragmente en projets propres à chaque service
Pour éviter cela, il faut un leader doté d’une forte autorité
C’est particulièrement difficile dans le secteur public, où les services se détestent souvent ; dans le privé, il existe au moins l’objectif commun de préserver les emplois
Comme le disait Jerry Weinberg dans Secrets of Consulting,
« même quand cela ressemble à un problème technique, c’est toujours un problème humain »
À la racine des problèmes techniques, on retrouve toujours des choix humains, de la communication, du management et des compétences
J’ai travaillé comme analyste sur un projet de remplacement de système
L’ancien système distribuait le travail selon un simple round robin, mais le nouveau le répartissait équitablement en tenant compte de la charge de chacun
Or certains employés ont manipulé le système pour paraître plus occupés, si bien que les employés consciencieux se sont retrouvés avec plus de travail
Nous avons clairement expliqué que le fond du problème n’était pas technique mais lié à une absence de supervision, mais on nous a tout de même imposé une solution technique
Par nature humaine, le travail tend à s’étendre jusqu’à remplir le temps disponible, et ce type de contre-incitation doit être maîtrisé techniquement
Si l’on conçoit un système en supposant des humains idéaux, on court à l’échec
Jerry Weinberg insistait déjà depuis The Psychology of Computer Programming (1971) sur ce principe :
« même si cela semble être un problème technique, c’est toujours un problème humain »
Ses livres gardent toute leur valeur aujourd’hui encore
Je n’aime pas cette façon de reprocher aux gens « de ne pas être fiers de leur métier »
La plupart des employés ne sont pas propriétaires de leur travail ; c’est l’entreprise qui l’est
Si l’entreprise impose une direction donnée et sanctionne toute opposition, pourquoi faudrait-il se battre ?
Nous ne sommes que des rouages de la machine, et si c’est ainsi qu’on nous traite, nous nous comportons en conséquence
L’attitude égocentrique de l’auteur m’est désagréable
Je suis aujourd’hui assez senior, et je travaille directement avec les sponsors financiers et les responsables des exigences
Ils me demandent « fais-nous ça, combien ça coûte ? », mais je dois fournir une estimation approximative en 18 minutes sur une réunion de 30 minutes
Ils ne comprennent pas la technique, mais maîtrisent parfaitement le langage de l’argent et de la politique
Certains problèmes ont été résolus par un simple message texte, alors que le budget était de 6 millions de dollars
D’autres projets ont été récupérés par une autre équipe, qui a brûlé 35 millions de dollars avant d’échouer
Les sponsors qui tiennent les budgets font presque toujours passer la politique avant tout, et leur objectif est « le poste suivant »
Quand on regarde leur carrière, on se demande souvent « comment ont-ils bien pu arriver jusque-là ? »
Pour celles et ceux qui souhaitent en savoir plus à ce sujet, je vous recommande de lire Peopleware !