Le problème avec le legacy n'est bien souvent pas dans le code. C'est un leurre.

Le problème avec le legacy n’est bien souvent pas dans le code. C’est un leurre.

#

À première vue, cette affirmation peut sembler surprenante.

Quand une solution devient difficile à maintenir, truffé de bugs, avec des régressions à chaque modification, et dont plus personne n’en comprend le fonctionnement, on peut assez facilement affirmer :

Le code est mauvais.

Et en soit, c’est probablement le cas.

Cependant, allons jusqu’au bout du raisonnement.
Qui a produit ce code ? Les développeurs.

Question :

“Est-ce que pour chaque solution legacy, il y avait des mauvais développeurs ?”

Évidemment que non.
Même la meilleure des équipes, constituée exclusivement de développeurs seniors, peut produire une solution legacy.
J’ai déjà vu ce scénario se produire. Probablement vous aussi.
Si la compétence de l’équipe n’explique pas à elle seule l’apparition du legacy, alors qu’est-ce qui l’explique ?

Continuons sur ce scénario.
Nous avons maintenant une équipe très compétente, qui a produit une solution legacy via du mauvais code.

Bien… Pourquoi ils ont fait ça ???

Ajout d’une variable à l’équation.

#

Depuis le début, on parle de legacy, mais au final, c’est quoi une solution legacy ? Les définitions varient, cependant il y a consensus sur un point : la présence d’une dette technique conséquente. Une “dette”.

Nos développeurs seniors ont généré, volontairement ou non, de la dette.

Pourquoi ?

C’est ici que nous devons introduire une nouvelle variable à notre équation :
Le business.

Quand un développeur modifie ou introduit une fonctionnalité via du code, il le fait généralement pour répondre à une demande du business.

Un développeur pour y arriver doit faire avec les exigences et contraintes qu’on lui impose pour diverses raisons : les deadlines, le budget, les urgences à résoudre, etc.
Quand ces contraintes deviennent trop importantes, face à la nécessité de devoir avancer et vite, des compromis peuvent être pris pour réduire le temps de développement au détriment de la qualité du code.
De la dette technique est alors introduite dans le projet. Dette qui, comme son nom l’indique, devra être remboursée dans le futur.

Malheureusement, si vous constatez aujourd’hui cette dette, vous l’aurez compris : elle n’a pas été remboursée.

Pire. Elle a grossi.

D’abord, probablement car d’autres dettes ont été contractées entre-temps.
Ensuite, tout comme pour un prêt bancaire, une dette engendre des intérêts.

Plus la dette est remboursée tardivement, plus l’effort à fournir pour y arriver sera important.
Cette dernière ayant entre-temps probablement créé d’autres problèmes et contraintes via son existence.

Pourquoi la dette technique n’est pas remboursée ?

#

Car il n’y a pas eu d’arbitrage pour la rembourser. Tant que le “GO” n’est pas donné, avec un plan d’action et du temps alloué, le problème reste reporté à plus tard.

Problème, le temps et le budget sont limités. Du temps alloué au remboursement de la dette, c’est du temps qui ne sera pas alloué à des demandes du business.
À la différence du métier, qui réclamera si sa demande n’est pas prise en compte assez vite, personne, mis à part peut-être les développeurs, ne viendra réclamer des actions vis à vis de la dette technique.

Et vu que de part nature, dans l’IT, nous sommes très souvent à flux tendu en continu, à recevoir constamment des nouvelles demandes, des urgences, des imprévus, etc. On reportera toujours ceci à plus tard.

Le “plus tard” n’arrivera jamais. On repoussera ainsi le problème jusqu’à ce que la situation devienne incontrôlable.
C’est bien souvent ici que le piège finit par se refermer.

Cela finit souvent par se traduire par une refonte from scratch dite big-bang du projet initial, quand le budget le permet (avec son lot de nouveaux problèmes, voir mon article dédié à ce sujet).

Voilà, nous avons maintenant vu ensemble les deux faces de l’iceberg.

• La présence de la dette technique sur la partie “visible” (via les problèmes qu’elle génère).
• Et les arbitrages organisationnels qui ont repoussé son remboursement jusqu’à ce qu’elle soit incontrôlable dans la partie immergée.

Donc pour conclure, bien souvent le problème avec le legacy, c’est avant tout un problème organisationnel.
Heureusement, un arbitrage, ça peut toujours être réévalué.