Le code legacy n’est pas simplement un problème technique. Il représente un code qui existe et fonctionne effectivement quelque part, qui est utilisé, maintenu et géré par une équipe composée de vraies personnes. Ces personnes doivent faire face aux conséquences des décisions prises dans le passé, que celles-ci aient été le fruit de leurs choix, des directives de la direction ou des actions d’anciens collègues externes. Elles sont également responsables en cas de bug ou de problème de production survenant en pleine nuit. Cette position n’est pas facile et elle est souvent négligée lorsqu’il s’agit de moderniser des logiciels.
Lorsque qu’une migration ou une mise à jour du code est décidée ou lorsqu’une réécriture est mis en œuvre, l’approche habituelle consiste à embaucher des personnes externes dans l’équipe pendant un certain temps pour commencer à mener l’utilisation de la nouvelle technologie. Cela peut être en partie dû au fait qu’il n’y a pas suffisamment de connaissances internes, mais aussi parce que l’équipe est déjà occupée par ses tâches quotidiennes.
Imaginez que vous êtes en pleine évolution de langage, de Java 8 à Java 21, que vous êtes en train de migrer d’un cadre propriétaire vers un cadre open source ou que vous commencez à utiliser des bibliothèques et des dépendances plus récentes. Dans tous les cas, il s’agit de connaissances qui ne sont pas nécessairement bien réparties au sein de l’équipe, car dans la généralement, il n’y a pas de temps alloué à une formation continue et dédiée.
Dans la majorité des cas, c’est une question de stratégie à long terme au sein du management de l’équipe ou de l’organisation : se concentrer sur les livrables à court terme, négligeant le phase de maintenance et la vie future du logiciel.
Ainsi, quelle qu’en soit la raison, il peut exister un fossé entre les technologies les plus récentes et les compétences communes partagées par l’équipe. Souvent, les décideurs pensent qu’en recrutant des personnes qui connaissent les aspects techniques et en les intégrant à l’équipe, les compétences seront acquises par une sorte d’osmose.
L’apprentissage ne se fait pas par magie
J’ai observé plusieurs problèmes avec cette logique dans divers projets et organisations :
- Le logiciel n’est pas seulement « technique », il intègre une logique métier qui peut être perdue ou négligée par des personnes externes qui se concentrent uniquement sur des améliorations techniques sans collaborer efficacement avec le reste de l’équipe.
- Si aucune stratégie claire n’est définie pour le partage des connaissances et si un temps d’apprentissage n’est pas dédié, cela ne fera que mettre davantage de pression sur l’équipe pour qu’elle puisse maintenir son niveau de compétence tout en effectuant ses tâches quotidiennes. Les connaissances ne sont transférées que si l’on travaille activement pour les acquérir.
- Après un certain temps, les externes termineront leur mission, et l’équipe principale devra gérer, maintenir et mettre à jour les technologies et la codebase développées par des personnes qui ne sont plus là, qui ne connaissaient pas le fonctionnement de l’entreprise et qui utilisaient des technologies qui pourraient ne plus être utilisées.
- Cela ajoute de la frustration et de la pression à l’équipe principale, car, en fin de compte, c’est elle qui devra gérer et faire face aux conséquences de tous ces changements. Elle devra donc travailler sur un logiciel legacy différent. Un logiciel legacy qui pourrait dépendre de nouveaux outils, mais dont les conséquences sont similaires à celles des autres systèmes legacy.
Expériences
Deux expériences dont j’ai été témoin me viennent à l’esprit.
La première concernait la migration d’un middleware d’intégration propriétaire vers une réécriture sur un framework open source. Au lieu de permettre à certaines personnes très compétentes déjà présentes dans l’équipe d’acquérir de nouvelles compétences, la direction a décidé de faire appel à un consultant externe en tant que développeur principal. C’était une personne qui connaissait la technologie cible, mais qui ne connaissait rien du fonctionnement de l’entreprise. Cela a bien sûr entraîné une frustration à différents niveaux, car ce nouveau développeur a mis beaucoup plus de temps que prévu initialement par la direction pour être productif et fournir un code adapté à l’entreprise. Cela n’a pas non plus aidé les membres de l’équipe interne à développer leurs compétences, car les directives données au développeur externe étaient de produire uniquement du code. Une meilleure alternative aurait été d’aider l’un des membres de l’équipe d’origine à devenir développeur principal, en tirant parti de ses connaissances et de son expérience et en lui apportant le soutien nécessaire pour maîtriser la nouvelle technologie.
La deuxième expérience fut un projet de réécriture complète, où l’on ajouta une équipe de développeurs externes à l’équipe dev principale noyau pour reconstruire entièrement une application. Cela s’est soldé par un mélange de personnes qui connaissent la logique commerciale mais doivent travailler sur des technologies qu’elles ne connaissent pas et des personnes qui connaissent les technologies mais rien sur la logique commerciale. Conséquences : problèmes d’erreurs et de maintenabilité, tant dans la logique commerciale que dans la technologie. Concernant cette dernière, même si elle était correctement utilisée, elle n’était pas comprise correctement par l’équipe dev principale, ce qui s’est traduit en problèmes de soutien tout au long du projet.
Encore une fois, le souci résidait dans la conviction de la direction que l’ajout pur et simple de membres à un groupe garantirait un fonctionnement harmonieux, avec un transfert de connaissances sans aucune difficulté.
Que devons-nous faire ?
Il est essentiel d’avoir une vision à long terme et de réaliser que l’intégration de personnes externes possédant une expertise spécifique dans un projet ne devrait pas se limiter à la livraison de code ou de fonctionnalités pour pallier l’équipe centrale. Leur rôle principal doit être d’aider l’équipe à s’adapter aux nouvelles technologies. Avoir au moins une personne qui code aux côtés de l’équipe est primordial, la guidant et créant des opportunités d’apprentissage pour favoriser le développement des compétences de l’équipe. Cela peut se concrétiser à travers des initiatives de développement mobile, des sessions de formation, des révisions de code et tout autre moyen adapté aux besoins de l’équipe.
Deux conditions cependant : l’équipe doit avoir le soutien de sa direction et l’objectif de mise à niveau de compétences doit être clair.
S’il n’y a pas de confiance, il n’existe pas d’espace sûr permettant à l’équipe de reconnaître ses besoins d’apprentissage, rendant ainsi cet objectif inaccessible. La situation est tout aussi problématique lorsque la direction insiste pour maintenir, voire augmenter, le rythme de livraison, car un soutien externe existe. Cela conduit inévitablement à un blocage dans le processus de développement.
En un mot : votre stratégie doit prévoir un temps d’apprentissage. Il en va de l’avenir de votre équipe et de votre logiciel.
Cela ne signifie pas qu’il ne faut pas demander à des externes de produire du code ou de livrer. Cependant, il est essentiel qu’elles sachent clairement ce qu’elles doivent accomplir. Elles doivent être conscientes qu’il est préférable de choisir de coder en collaboration avec quelqu’un d’autre plutôt que de le faire rapidement en solo, afin de favoriser le partage des connaissances. Une fois de plus, l’apprentissage prend du temps ; il convient donc de planifier en conséquence pour réussir cette intégration.
Et si vous voulez une équipe résiliente, prête pour l’avenir, vous avez besoin d’une équipe qui ne sera pas frustrée par les choix faits par d’autres qui n’ont pas à vivre avec les conséquences de leurs actions. Vous avez besoin d’une équipe qui a participé au changement. Une équipe qui n’est pas contrainte de s’adapter sans avoir son mot à dire sur le processus.
Le code, ce sont aussi les personnes qui en sont propriétaires.