La dette technique

debtC’est quoi?

Le terme de « dette technique » a été introduit en 1992 par Ward Cunningham.

C’est est une métaphore qui permet de dénoncer, dans le contexte du développement logiciel, les problèmes résultant d’un travail trop rapide, qui semble pourtant bien être terminé.

Le concept est intéressant car le niveau de qualité d’un développement n’est pas forcément visible par les utilisateurs a court terme. Cela permet d’expliquer pourquoi le temps de développement de fonctionnalités pourtant triviales devient ridiculement élevé sur des projets mal développés.

Les dettes s’additionnent avec le temps, et ses effets sont de plus en plus visibles.

Une dette non remboursée fait perdre du temps régulièrement, tout ce temps perdu est l’équivalent des intérêts de la dette.

Comment créé-t-on de la dette technique?

Tout le problème démarre lorsque vous expliquez au client de choisir. « Fast, Good and Cheap, you can pick two ». La réponse est toujours la même : je veux ma fonctionnalité et vite. Le sacrifice est trop souvent fait sur la qualité, car elle n’est pas visible par les utilisateurs en général. La seule chose visible pour un utilisateur c’est si la fonctionnalité est disponible ou non.

Qui accepteraient un coût plus grand pour une implémentation propre d’une fonctionnalité plutôt qu’une implémentation avec du code sale? La réponse est : un chef de projet expérimenté et engagé dans son projet a long terme.

La qualité est vu par les non-développeur et les médiocres comme du temps perdu. Alors que c’est la clef pour garder une bonne capacité a délivrer et pour minimiser les bugs et régressions.

En tant que bon développeur pour votre intérêt et l’intérêt de votre client vous devez chercher a améliorer la qualité de votre code.

 

A mort la dette?!

A l’instar d’une dette financière, la dette technique n’est pas forcement mauvaise, mais elle doit être une décision consciente.

D’ailleurs la dette technique fait partie du processus de développement, ce n’est pas toujours le choix d’un développeur.

Se battre obstinément pour éviter toute forme de dette est contraire aux méthodes agiles, ce serait perdre en flexibilité. Pousser rapidement en production une nouvelle version avec une fonctionnalité attendue et régler la dette ensuite est plus intelligent que de perdre des précieuses semaines en gardant une qualité maximale.

De la dette maîtrisée booste les développements, le problème arrive lorsqu’elle est hors de contrôle.

 

Vive la dette?!

Le problème de la dette en général, c’est que personne n’a envie de s’en occuper. Et cette tendance s’accentue jusqu’au moment ou elle est hors de contrôle. Un effet pervers apparaît alors : le signal que la dette est acceptable est reçu par les développeurs, ils relâchent leur standard de qualité et se permettent d’écrire du code de moins en moins propre, c’est l’hypothèse de la vitre brisée.

On arrive a un code peu lisible, qui résiste au changement. Personne ne veux travailler sur ce genre de code. Les développeurs se démotivent, créent encore plus de dette technique pour respecter les délais.

Exemple de réaction normale face a de la dette technique : “Je ne vais pas faire des tests unitaires : ce projet n’en n’a pas, je ne vais pas commencer maintenant!”.

S’il est possible de ne jamais rembourser totalement une dette technique, on n’échappe jamais aux intérêts.

Les intérêts se manifestent de plusieurs façons : contracter une dette ralenti considérablement les développements suivants et les rend plus dangereux.

Je pense que le pire problème de la dette technique est son coût « humain » : en effet, par simple mécanisme d’usure par « friction » à du code qui « résiste » aux changements, la dé-mobilisation des équipiers peut se faire sentir très vite. Comme l’a souligné Kent Beck : « la qualité a un effet sur les gens », personne n’aime travailler dans de mauvaises conditions ou en produisant du code que l’on sait pertinemment sentir mauvais.

A la suite d’un bug, il faut plus de temps pour le reproduire , repérer le code impacté, le comprendre. Il faut plus d’effort pour s’assurer de ne pas introduire de régression en fixant ce bug, plus d’effort pour s’assurer de ne pas en introduire de nouveaux.

Un code sans qualité est un code instable, C’est un code peu lisible, seul le propriétaire du code est capable de travailler dessus sans peur ce qui rend la maintenance plus chère et moins agréable, et le départ du propriétaire du code endetté peut devenir un risque non négligeable pour la survie du projet.

Comment l’éviter

Comme d’habitude, il faut agir en bonne intelligence

L’important est de comprendre le concept, l’idéal étant de prendre les mesures nécessaires avant que la situation ne dégénère:

Le vaccin contre la dette technique c’est la qualité, qui va de paire avec les méthodes Agiles.

Si le mal est fait, il faut le reconnaître, en prendre conscience. C’est le premier pas vers une solution. Ensuite il faut en discuter au sein de l’équipe pour trouver des solutions.

Les deux questions a se poser sont les suivantes : Est-ce une bonne idée de rembourser? (code ne changeant que très peu, voué a disparaître rapidement) . Peut-on se permettre de le faire?

Il faut toujours garder en tête qu’on ne code pas pour soit, ou pour le compilateur. La difficulté de la programmation est de coder pour la prochaine personne qui va travailler sur le code, et de tout faire pour lui faciliter la vie.

Le cauchemar du nouveau arrivant qui doit intervenir sur du code non testé, qui nécessite des outils qui ne sont plus supportés ou devenus difficiles à installer, nécessitant une licence non fournie ou sans environnement de tests arrive plus souvent qu’on le pense. Et lorsqu’il demande de l’aide la réponse est souvent que le développeur travaillant sur ce projet est partit depuis deux mois, oui tu es tout seul.

Mais quel plaisir de travailler sur un code plus propre. Tu vois ca ne coute pas plus cher de bien coder.

Aller plus loin : http://martinfowler.com/bliki/TechnicalDebt.html

Comments are closed.