Ne mettez pas la complexité sous le tapis

Dans la carrière d’un développeur, il y a un apprentissage qui arrive très tôt : avec l’ajout de nouvelles fonctionnalités, la complexité du code source augmente très rapidement. Et, en peu de temps, certaines parties du code source peuvent commencer à faire peur.

Souvent c’est le début des problèmes de maintenance. L’ajout d’une nouvelle fonction devient extrêmement pénible. Et les parties prenantes qui gravitent autour du projet ne comprennent pas pourquoi ajouter une fonctionnalité prend autant de temps et devient aussi compliqué.

Et voici la spirale infernale…

Nous (développeur) ne sommes plus en situation de pouvoir évaluer le temps nécessaire à une modification dans le code. Mais pour ne pas passer pour des guignols, on estime quand même sur demande les prochains développements (en prenant une grosse marge).

Quelque temps après avoir démarré le développement, on se retrouve complètement englué dans un code incompréhensible. Chaque modification prend un temps fou et provoque des bugs en cascade.

Le temps passe (vite), et l’estimation initiale est dépassée. Forcément, c’est le moment que choisit le manager pour venir s’enquérir de l’état d’avancement (normal, on était censé avoir terminé pour cette date). Alors, on essaye de le rassurer, de lui expliquer que ça sera bientôt fini, que dans deux ou trois jours ce sera terminé, pas de soucis…

Mais le stress commence à monter, on se demande dans quoi l’on s’est embarqué. Certains développeurs commenceront à faire des heures en plus, d’autres, à raccourcir leurs pauses repas.

Cependant, on agit comme si tout allait bien, pour montrer que l'on contrôle la situation. On refuse donc toute aide qui est proposée : « non, ne t’inquiète pas, je gère, j’en ai plus pour longtemps, ça ne sert à rien maintenant, j’ai presque terminé ».

Bien entendu, une semaine après ce n’est toujours pas terminé. Des négociations ont lieu : demain c’est bon, c’est promis, c’est fini. Mais le lendemain ce n’est toujours pas terminé, ni le surlendemain ni trois jours plus tard…

L’avantage c’est que maintenant le manager s’est fait une raison, il se désintéresse du sujet. Il a autre chose à faire, dont notamment gérer le fait que la date de lancement ne sera pas respectée.

Enfin, après plusieurs semaines, c’est terminé. Le déploiement s’est fait dans la douleur, de nombreux bugs ont été trouvés, et plusieurs clients se sont plaints d’avoir un logiciel cassé. Tout ça laisse une impression aigre-douce. D’un côté, un certain soulagement. Mais de l’autre, un peu de honte. Avec une petite blessure à notre fierté (et des doutes sur nos capacités). On se dit que l’on se fera plus prendre à ce petit jeu.

Malheureusement une nouvelle fonctionnalité est demandée, et avec horreur, on se rend compte qu’elle touche la partie du code dans laquelle on vient de travailler. Et tout recommence.

Et le manager dans cette histoire ?

Maintenant prenons le point de vue du manager. Déjà imaginez sa surprise au moment où il découvre notre estimation. Elle est beaucoup plus importante que ce à quoi il s’était préparé. Pour lui c’était une simple petite modification métier.

Quand la date initiale de l’estimation arrive, il n’est pas surpris que ça ne soit pas fini : « c’est toujours la même chose avec les développeurs, ça prend toujours plus de temps que ce qu’ils disent ». C’est agaçant, mais heureusement il avait prévu une bonne marge avant de donner une date de livraison au département métier.

Par contre, une semaine après, quand ce n’est toujours pas terminé. Il commence à paniquer. La date qu’il avait donnée n’est plus respectée. Il va encore une fois passer pour quelqu’un qui ne sait pas gérer ses équipes… Après plusieurs jours de stress, finalement il abandonne « ça sera fini quand ça sera fini ».

Et, quand arrive le déploiement, ça ne marche pas, il y a des bugs, et il faut gérer des clients mécontents. C’est comme d’habitude « Dans le logiciel, ça ne marche jamais du premier coup ».

Forcément nous ne risquons pas de recevoir des félicitations de sa part. Au contraire, il se demande de quelle équipe de bras cassés il a encore hérité. Et puis il y a une nouvelle fonctionnalité à planifier…

Dans cette petite histoire…

Personne n’a réussi à être content du travail effectué, et ça finit par peser sur le moral, l’équipe n’est pas très soudée.

Et pourtant personne n’a souhaité cette situation, personne n'a voulu en arriver là. Je pense que nous sommes nombreux à avoir déjà vécu ce genre de problématique. Alors que se passe-t-il ?

Alors, comment on évite cette situation ?

Pour corriger l’origine du problème, le mieux serait de réussir à avoir un code source simple, dans lequel il est possible d’intervenir sans avoir peur que tout dérape. Et même les projets en apparence damnés peuvent être récupérés avec des techniques qui seront détaillées dans de futurs articles.

Malheureusement ce n’est pas toujours possible, on hérite souvent d’un système existant. Projet qui a de gros problèmes de qualité, et développé par plusieurs générations de développeurs dont beaucoup ont quitté l’entreprise depuis des années. Et puis on a pas le temps, il faut sortir de nouvelles fonctionnalités, il y a une roadmap à respecter.

La clé dans ces situations…

Comme souvent, la clé ne se trouve pas dans la technique. En réalité la solution est de communiquer clairement dès le début.

Si vous indiquez dès le début que vous allez travailler dans une partie du code source que vous ne maitrisez pas et qui est devenu très difficile à comprendre. Tout le monde sait à quoi s’attendre, et l’on ne vous reprochera pas les problèmes de la future livraison.

La dynamique est différente, le manager comprend la situation, il peut donc aller expliquer au département que la livraison ne peut pas être garantie. On pourra vous proposer de l’aide et vous pourrez en demander.

Et puis, ça permet aussi d’expliciter le temps perdu dans ces moments d’errance, de les rendre visibles aux gestionnaires de vos projets. De cette manière, ils commenceront à se rendre compte du temps perdu à cause des problématiques de qualité. Et ce sera d’autant plus simple de demander à avoir du temps pour résorber ces problèmes.

Si vous n’osez pas en parler

La toute première étape est de créer plus de sécurité psychologique dans votre équipe. Nous en reparlons bientôt, mais c’est un élément essentiel dans une équipe de développement.

La notion de sécurité psychologique est le fait de pouvoir exprimer nos doutes, de prévenir notre équipe quand nous nous trouvons en difficulté, sans avoir peur d’être jugé,

Si vous êtes team lead, je vous encourage fortement à montrer l'exemple, si vous ne savez pas quelque chose, dites-le et demandez de l’aide.

Pour moi, c’est d’ailleurs le point le plus important. Avoir une équipe dans laquelle je peux librement m’exprimer, sans crainte, est mon premier critère de recherche.

La première qualité d’un développeur

On me demande régulièrement ce qui fait un bon développeur. Souvent les gens s’imaginent que c’est dans les compétences techniques que se trouve la réponse.

En réalité les meilleurs développeurs sont ceux qui ne mettent pas les problèmes sous le tapis. Et qui sont capables de reconnaitre et de communiquer quand ils ne savent pas.

En effet, cela permet d'accompagner et de faire progresser tout le monde !

Vous pouvez me retrouver sur twitter

Si vous avez apprécié l’article

• Partagez l’article sur le Slack de votre entreprise, twitter ou encore Linkedin afin de le faire découvrir à des collègues, amis, ou simples connaissances qui pourraient être intéressés.
• Pour être tenu informé de la sortie des prochains articles, présentations, épisodes de podcast ou autres contenus, abonnez-vous à la newsletter grâce au formulaire juste en dessous.

Merci à @davidnotset et @SebastienChemin qui m'ont apporté leur aide pour l’écriture de cet article