L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ?

Les dangers d’un pompier pyromane

Est-ce qu’on peut reprocher à un développeur d’être bon dans le débuggage ? Evidemment que non. Encore faut-il que notre zigoto soit effectivement un excellent débuggueur, mais c’est une autre question.

On en arrive à l’aspect « pyromane ».

Une fois que le développeur est grisé par l’attention et les remerciements qu’il reçoit lorsqu’il résout un problème, il va commencer − très inconsciemment − à rechercher ces moments-là parce que ce sont les plus gratifiants. Donc plutôt que de travailler sur ses tâches habituelles, qui prennent parfois des jours ou des semaines à avancer, il va toujours trouver du temps (un peu comme par magie) pour résoudre le petit bug ou faire la petite amélioration qui va simplifier la vie de telle ou telle personne.
Après tout, si ça permet d’augmenter la productivité des gens de l’entreprise, ça ne peut être qu’une bonne chose, non ?

Le premier effet pernicieux, qui prend du temps avant de se voir, c’est qu’à force de privilégier les « quick win », le développeur va négliger ses autres tâches. En tout cas, il ne va pas s’y consacrer comme il le faudrait. Et le projet qui devait prendre 4 jours à développer va finalement en prendre 6, ce qui va le faire déborder du sprint. Vous ne maîtrisez plus le planning, mais il faut être très attentif pour comprendre d’où provient ce phénomène. Non seulement les projets qui sont planifiés mettent plus de temps à être réalisés que prévu, mais en plus des projets non stratégiques sont développés en passant sous les radars. S’interfacent-ils correctement avec le reste du code ? Auraient-il vraiment été fait de la même manière (que ce soit fonctionnement ou techniquement) s’ils avaient été planifiés ?

On en arrive au deuxième effet négatif. Tous ces petits développements vont entraîner des décalages sur les “vrais” projets et pour absorber cela, le développeur va faire au plus vite en prenant quelques raccourcis. La qualité globale de ses projets va diminuer, parce qu’il aura fait un peu moins attention à ce qu’il développait, parce qu’il sera allé un peu plus vite que d’habitude pour coder, parce qu’il aura tester un peu moins sérieusement, parce qu’il aura fait des tests unitaires avec un taux de couverture un peu moins bon, parce qu’il aura écrit une documentation un peu moins complète que ce qui était attendu, et ainsi de suite.

Mais, là encore, est-ce vraiment un problème ? Après tout, le risque de mettre en ligne des projets de mauvaise qualité n’est pas très grave : notre pompier sait qu’il peut compter sur ses capacités techniques et sa réactivité, et il pourra corriger un bug dès qu’il lui sera remonté. Si on fait la promotion de la méthodologie agile, c’est bien pour être agile, non ?

Le troisième effet pervers, c’est qu’à force de programmer à la va-vite, en patchant à toute vitesse pour tenter de faire marcher les choses, on obtient du code friable. Vous savez, le code qui génère des nouveaux bugs de régression dès qu’on y touche, même en ayant l’impression de bien faire les choses.
Tout en sachant que ce code, déjà très difficile à maintenir par le développeur qui en est à l’origine, sera quasi-impossible à faire évoluer par d’autres personnes de l’équipe.

On entre alors dans une spirale infernale qui peut être dévastatrice à moyen terme. Car ce code friable génère de plus en plus de bugs au fur et à mesure qu’on le fait évoluer pour y ajouter des fonctionnalités. Comme un château de sable auquel on tente d’ajouter des étages, il s’effrite de partout et fini par s’effondrer sur lui-même. Et au fur et à mesure que le pyromane œuvre à améliorer les choses, il ajoute du sable un peu partout et c’est au final l’ensemble de la plate-forme qui devient friable.
À ce moment-là, l’équipe technique est constituée d’incapables aux yeux du reste de l’entreprise. Le nombre de bugs va en augmentant, ce qui pousse notre pompier à éteindre de plus en plus d’incendies, ce qui lui fait recevoir de plus en plus de félicitations pour son efficacité à résoudre ces satanés bugs, ce qui fait qu’il passe de plus en plus de temps à jouer le pompier, ce qui l’amène sans le vouloir à placer des petites bombes dans le code qui viendront allumer de plus en plus d’incendies au fil du temps.

Comment reconnaître un pompier pyromane ?

C’est parfois très difficile, et d’autres fois beaucoup plus évident. Mais la plupart du temps, un développeur n’est pas toujours pyromane ; ça dépend des moments et des circonstances.

Il faut donc être attentifs à quelques indicateurs :

• Est-ce que l’un de mes développeurs sous-évalue systématiquement la taille de ses développements ? Est-ce qu’il passe plus de temps sur ses tâches qu’il ne le faudrait raisonnablement ? Cela voudrait dire que ses estimations sont juste, mais qu’il se laisse emporter par des tâches invisibles qui lui font prendre du retard sur ses projets.
• Est-ce que l’un de mes développeurs a tendance à toujours vouloir s’occuper des bugs qui sont remontés à l’équipe ? Cela pourrait indiquer un forte propension à jouer le pompier, ou au moins une préférence marquée pour les tâches rapides au détriment des projets qui s’inscrivent dans la durée.
• Est-ce qu’une demi-heure après chaque déploiement en production, l’un de mes développeurs arrive avec un patch à mettre en ligne rapidement pour corriger un “petit bug qu’on n’a pas vu en pré-prod” ? C’est un signe que les tests on été faits par-dessus la jambe, voire même n’ont pas été faits du tout.
• Est-ce que l’un de mes développeurs semble ne vouloir développer que des projets “from scratch”, ou bien veut toujours lancer des refactoring sur le code existant ? Peut-être qu’il est foncièrement incapable de relire du code écrit par quelqu’un d’autre que lui ; ou il a un problème d’égo qui lui fait penser que le code des autres est toujours merdique comparé au sien. Il faut alors faire attention, parce qu’il fera toujours des choix techniques (bons ou mauvais ; ils seront toujours bons pour lui) en fonction de cela, mais aussi parce qu’il risque de mal s’y prendre lorsqu’il devra modifier du code existant sans le réécrire entièrement.

La difficulté, c’est que tout développeur peut tomber dans l’un de ces travers à un moment ou un autre ; c’est normal. C’est la répétition qui doit vous alerter, ou la certitude que le développeur a un état d’esprit clairement marqué par l’un de ces travers.

Comment gérer un pompier pyromane ?

La première chose à faire, c’est d’en parler avec lui. Lui faire remarquer que si on définit un ordre de priorité entre les tâches, c’est parce qu’il y a une raison. Que les félicitations qu’il reçoit lorsqu’il fait cavalier seul sont peut-être gratifiantes pour son égo, mais qu’il ne doit pas oublier que c’est son manager − pas ses collègues − qui fait son évaluation annuelle (et donc qui décide de son augmentation ; mais pas besoin de le dire explicitement, il aura compris). Qu’il a fait perdre pas mal de temps à l’équipe et que ce n’est pas acceptable.

Si ça ne marche pas, il faut parfois aller jusqu’à lui faire l’énumération des boulettes qu’il a faites ou qu’il a générées. Ce n’est agréable pour personne : aucun manager n’a envie de fliquer quelqu’un, sans même parler du temps et de l’énergie dépensées ; et aucun développeur n’a envie de se prendre dans la figure une longue litanie de choses négatives. Ça peut éventuellement faire un électrochoc, mais c’est à utiliser en dernière solution.

Le pair programming est un moyen assez simple de casser la dynamique du pompier pyromane. En formant un duo avec un autre développeur, il lui devient impossible de faire des choix unilatéraux. Le binôme est un garde-fou qui peut aussi bien modérer ses initiatives que remonter au reste de l’équipe les choses qui ne lui semblent pas normales.

Enfin, il est possible d’ajouter du process. Faire en sorte qu’aucune évolution de code ne soit mise en production sans avoir été validée par deux personnes. Obliger un code coverage des tests unitaires supérieur à 95%. Avoir des cahiers de tests que les développeurs doivent dérouler avant toute demande de déploiement, et qu’ils doivent signer (à l’ancienne, avec un stylo).
Mais cela est très lourd et chronophage, ça ajoute énormément d’inertie, ce qui est coûteux pour l’entreprise au final. Si le problème n’est causé que par un seul pompier pyromane, c’est dommage de devoir en arriver là.