Sans rentrer dans le débat qui tend à dire qu’au fond tout ce qui est poussé en production devient automatiquement du code Legacy. J’aimerais plutôt parler du sujet qui apparaît en général comme un problème de fond.
En effet, en général les développeurs ont toujours tendance à pousser les nouveaux projets, les nouvelles tendances, les nouvelles technologies pour remplacer les anciennes… Ce n’est pas à proscrire loin de là, mais il faut également savoir remettre en question et surtout étudier le contexte qui reste toujours le maître mot.
On oublie souvent que si un vieux projet Legacy est toujours présent c’est qu’il a la haute qualité de tout simplement fonctionner, il est souvent même une des clés du rouage.
Bien sûr tout projet à une durée de vie, il faut souvent faire des opérations de maintenance sur un projet legacy afin de maintenir sa durée de vie. Tout ceci a un coût, et un développeur qui cherchera à s’épanouir poussera souvent pour abandonner le projet afin de se mettre à fond sur la nouvelle version.
Le dilemme de la baguette
Je vous préviens, la comparaison que je m’apprête à faire peut paraître un peu tirée par les cheveux et pourtant je trouve qu’elle représente bien la situation.
Imaginez, une famille anti gaspillage qui consomme une baguette de pain par jour, un jour vient ce qui devait arriver et un soir il reste la moitié d’une baguette. Ils sont dans l’impossibilité de la congeler. Le lendemain matin comme d’habitude ils achètent leur baguette qui correspond à leur consommation journalière.
Il se retrouve alors avec une demie-baguette de pain un peu durcie de la vieille qui ne donne pas envie à côté de la baguette fraîche peut-être encore un peu chaude qui sort de la boulangerie.
Quelles sont les solutions qui s’offrent alors à eux ? Manger d’abord la moitié restante puis la moitié de la nouvelle. C’est la solution qui semble la plus raisonnable. Mais elle entraîne un cycle sans fin qui fait que l’on aura toujours une partie de baguette durcie chaque matin. C’est ici la situation où l’on privilégie la maintenance du projet legacy quitte à ce que le projet ne soit jamais remplacé. Jeter la demi-baguette de la vieille et donc bafouer ses principes afin de pouvoir ne manger que du bon pain. Les principes représentent ici plutôt en général un chiffre d’affaires qui serait abandonné si on se consacrait uniquement au nouveau projet en arrêtant toute modification sur l’ancien sans avoir de garantie. Se forcer à manger plus afin de pallier le problème. On parle ici d’heures supplémentaires ou de nouvelles ressources pour gérer les deux sujets en parallèle. Encore un investissement, ici qui peut paraître moins risqué, mais peut être plus intense sur le court terme.
Il existe sûrement d’autres solutions, mais l’idée est ici de comprendre qu’il n’y a souvent pas de solution miracle. Que toute manoeuvre qui peut paraître pour l’un évidente peut être mal venue sous un autre angle. En général il faut savoir prendre du recul, analyser le contexte avec toutes les parties prenantes pour proposer les bonnes solutions.
Dans cette situation il est souvent nécessaire d’avancer à petits pas, car les actions brutales dans un sens ou dans l’autre peuvent être coûteuses que ça soit économiquement, mais dans d’autres domaines comme le moral des équipes ou autre.
Une vision généraliste
Je vous parle ici de projet Web ou tout simplement de projet informatique.
Mais à bien y réfléchir, cette problématique est bien plus ouverte que ça et peut être retrouvée dans d’autres domaines.
Un changement de vie par exemple, imaginez un salarié qui a envie de changer de domaine ou simplement se mettre à son compte. Il peut faire le choix de tout arrêter du jour au lendemain pour se consacrer à 100% à sa nouvelle vie. Cela peut également rester un rêve qui traîne sur la durée ; ou encore peut-il commencer en parallèle en rattrapant sur ses heures de temps libre.
Et là encore il n’y a pas de solution parfaite et toutes ne sont pas toujours abordables en fonction de l’environnement qu’il soit économique ou autre.
On en revient toujours à la même conclusion : tout est une question de contexte …