Le problème des Héros dans les équipes techniques

OK : votre application web tombe en panne au milieu de la nuit.
Il est 2 heures du matin, naturellement votre site web a une audience mondiale et donc vous avez des utilisateurs dans tous les fuseaux horaires.
Forcément, ils sont en colère. Forcément, ils ne peuvent plus faire d'achats, ni annuler leurs abonnements.
Forcément, chaque minute où c'est en panne : vous perdez de l’argent.

Et d'un coup : l’un de vos développeurs se connecte au serveur, travaille un peu dessus, on ne sait pas trop ce qu'il est en train de faire. Les minutes sont longues. Mais YES ! le problème est finalement résolu ! L'application est à nouveau "up" et l'argent coule à nouveau.
Et malgré le fait que ce genre de situation se produise de temps en temps, vous êtes rassuré de savoir que vous avez toujours cette personne pour sauver le coup.

Ce développeur, c'est votre Héros.

Personne ne devrait se sentir à l'aise dans cette situation, elle est plutôt triste.

Pour une entreprise, c'est une situation risquée et cela a un impact négatif sur tous ceux qui y travaillent, y compris sur votre développeur Héros, malgré, c'est vrai, un immense sentiment d'importance.

C'est du bricolage
Explications.

Entretenir un Héros = entretenir un SPoF.

Si une application importante a des problèmes de stabilité : vous devez les résoudre ASAP. Et on le sait : lorsque l'on gère un crash, on ne traite jamais des problèmes de fond, on cherche simplement à patcher l’existant avec du court-terme ou des correctifs temporaires. Mais le vrai problème, lui, reste.

La gestion de crise n'est pas la même chose que la prévention de crise.

Paradoxalement, être rassuré d'avoir un Héros à votre disposition rend ces problèmes moins urgents. Et la tentation est grande de retarder leur résolution au profit d’autres activités génératrices de revenus. Or une entreprise qui est OK avec le fait d'avoir un Héros, est OK avec le fait d'avoir un Single Point Of Failure (SPOF). Ce n'est pas normal.

Votre Héros n'est pas non-plus Superman, les clients finissent par le voir.

Une application instable dégrade la réputation de l'entreprise, de sa marque. Cela impacte la rétention des clients et cela finira par rendre plus difficile l'acquisition de nouveaux clients.

Il y a aussi la probabilité non-nulle que votre Héros soit indisponible. En vacances, malade (ou auprès d'un membre de sa famille malade), ayant démissioné ... ou autre.
Votre application sera alors en panne pour une période beaucoup plus longue : les minutes deviennent des heures, les heures deviennent des jours ...
Peut-être que quelqu'un d'autre dans l'équipe peut assumer le rôle du Héros, mais quelles en sont les garanties ?

Votre équipe se ramollit

On peut facilement comprendre que pour les autres, être dans cette situation entraîne un sentiment d'impuissance. Cela va nuire à la confiance en soi des autres membres de l'équipe, ce qui va affecter en cascade le rendement au travail.
On pourrait demander aux Héros d'expliquer comment résoudre les problèmes mais cela n'a pas de sens : pourquoi l'entreprise donnerait-elle la priorité à cette passation de savoir alors qu'elle ne s’intéresse pas à résoudre la source des problèmes ?
Pire encore, les gens comprennent qu'ils peuvent compter sur les Héros et décident qu'ils n’ont qu'à faire uniquement leur travail. Pour les crises, il existe ces Héros pour les gérer.
Les Héros vont déculpabiliser les autres de ne pas s'intéresser au fond des problèmes.

Penser défensivement.
Car oui, elles vont arriver, c'est 100% garanti : il faut juste être prêt pour !
Le meilleur moyen de prévenir les crises (ou les rendre plus simple à gérer) est de penser votre logiciel de façon défensive. Cela signifie aller chercher à faciliter la prévention ou la compréhension des crises.

Comment un développeur peut-il faciliter la gestion d’un crash s’il n’a jamais lui-même été auparavant victime d’une crise ?
C'est très simple : il ne peut pas !

Chat échaudé craint l'eau froide.

Les développeurs chevronnés prennent chaque jour des dizaines de micro-initiatives dans leur code, beaucoup de ces décisions peuvent faire économiser de précieuses minutes, voire des heures lors d’un problème.

Cas typique. De nombreux développeurs juniors ont tendance à écrire des messages d'erreur trop génériques. On va trouver dans leur code des messages du type « Error » ou « Une erreur s'est produite ». Mouais ok.
Mais où l'erreur est-elle survenue ? Qui est l'utilisateur à l’origine de l’erreur ? Quel est le contexte ?
Car avoir un petit message qui dit « Une erreur s'est produite pour l'utilisateur 123 à l'adresse URL /home » fait une énorme différence.
Ce sont des changements mineurs dans le code mais ils peuvent avoir beaucoup d’importance. Écrire du code qui aide dans le débogage en cas de crise est une compétence essentielle pour un développeur. Mais quelqu'un qui n'a jamais eu à résoudre des problèmes graves dans l'urgence ne comprendra pas vraiment la plus-value.

Et lorsque les développeurs s’appuient sur un Héros : ils se privent de la possibilité de développer ces compétences.
Cela aura un impact sur l'entreprise à court terme... et sur la carrière des développeurs à long terme. Car clairement, avoir un collègue qui joue le Héros a également un impact négatif sur sa propre carrière.

Enfin, la culture des Héros est aussi problématique pour les Héros eux-même.
Avoir les compétences pour sortir d’une crise rend le Héros précieux en quelque sorte. Crise après crise, il développera uniquement les compétences pour résoudre des crises. Pas à les prévenir.
La conséquence est que les Héros ne sont pas nécessairement de bons développeurs. Certains sont même plutôt moyens mais cela est compensé par leur engagement extra-ordinaire.

Concernant la prévention des crises,
- Si l’entreprise n'en fait pas la priorité, le Héros n’aura jamais le temps de s’en occuper
- Si l’entreprise valorise la bravoure du Héros, le Héros n’aura jamais intérêt à s’en occuper

La carrière même du Héros est affectée parce que sa valeur reste liée à une seule entreprise, cela entache sa capacité d'aller en avant.
Résoudre des crises sans prévention a un impact microscopique sur la croissance du développeur. Vous finissez par résoudre le même type de crise encore et encore. Aucun apprentissage et aucune valeur ajoutée dans son skillset.

Naturellement, la vie personnelle du Héros peut aussi être impactée. Envie de prendre des vacances ? Oui, mais ayez toujours le téléphone à portée de main et soyez prêt à sortir votre ordinateur portable à tout moment. Vous voulez construire quelque chose de nouveau et d'intéressant ? Bien sûr, mais faites-le entre les crises. Vous voulez planifier un dîner avec des amis ou aller à un rendez-vous ? Pas de souci, mais préparez-vous à l’annuler, au cas où une crise se produirait.
A choisir entre Héros et simple développeur ? Il est bien pire d'être un Héros : les éloges et les encouragements peuvent être plaisants au début, mais cela ne dure pas. Finalement, il n'y a plus que l'épuisement, la résignation et la colère.
Sans même parler burn-out ou bore-out.

Alors, comment nous débarrasser de la culture des Héros ?

C'est en réalité assez simple, mais la mise en œuvre peut être difficile.

Traitez le fait d'avoir un Héros aussi sérieusement qu’une crise. En cas de crise, résolvez-la, évidemment. Mais faites immédiatement un pas pour empêcher que quelque chose de semblable ne se reproduise. Ce n’est pas une garantie de prévention, mais pas à pas, vous convergez vers une version stable de votre application.

Accordez également la priorité à la formation de vos équipes.
Impliquez plusieurs personnes dans chaque crise.
Peut-être qu’il s’agit juste de discuter du problème avec le Héros pour avoir un feedback. Impliquez tout le monde dans ce processus d'apprentissage continu. Cela peut sembler une perte de temps puisque le Héros peut agir plus rapidement, mais le fait d’avoir plusieurs personnes capables de résoudre des crises futures en vaut vraiment la peine.
On élimine les SPoF par la redondance.

Pour l'anecdote, Netflix est connu pour avoir retourné le problème. Ils sont passés d'un modèle classique où les équipes construisent un logiciel en espérant qu'il n'y aura pas de pannes à un modèle où ils seront certains qu'il y a aura une panne - mais provoquée. Par un Chaos Monkey ! Voir aussi les Principles of Chaos Engineering.

Il n’est jamais facile d’essayer de se projeter à long terme en cas d’urgence. Mais pour toutes les raisons énoncées ci-dessus, il faut empêcher ce cercle vicieux de n'avoir qu'une seule personne pour résoudre les crises.

Et même Balavoine le dit ...

---