Quadrant de la Dette Technique

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Martin Fowler (@martinfowler)
Source : TechnicalDebtQuadrant
Date : 14/10/2009


Traducteur : Fabrice Aimetti
Date : 23/08/2015


Traduction :

Ces deux derniers mois, il y a eu quelques articles sur la Dette Technique. Ils posaient la question des types de défauts de conception qui devraient ou ne devraient pas être considérés comme faisant partie de la Dette Technique.
Un bon exemple est l'article d'Oncle Bob qui déclare que le Code sale n'est pas de la dette. Son argument consiste à dire que le code sale, écrit par des personnes qui sont ignorantes des bonnes pratiques de conception, ne devrait pas être considéré comme de la dette. La Dette Technique devrait être réservée à des situations où les personnes ont pris la décision réfléchie d'adopter une stratégie de conception qui n'est pas maintenable sur le long terme, mais qui génère un bénéfice court terme, par exemple livrer une version. L'intérêt c'est que la dette apporte de la valeur plus tôt, sachant qu'elle doit être remboursée le plus tôt possible.
Selon moi, la question de savoir si un défaut est ou non de la dette est une mauvaise question. La Dette Technique est une métaphore, la vraie question est donc de savoir si la métaphore de la dette est utile lorsqu'on réfléchit sur la façon de traiter les problèmes de conception, et sur la façon de communiquer cette réflexion. Un avantage spécifique à cette métaphore de la dette, c''est qu'elle est très pratique pour communiquer avec des personnes qui ne sont pas techniques.
Je pense que la métaphore de la dette fonctionne bien dans deux cas, la différence portant sur la nature de la dette. Un code sale est une dette irréfléchie qui se traduit par des paiements d'intérêts écrasants ou par une longue période de remboursement du capital. Nous sommes tombés sur quelques projets où nous avons repris un code avec une dette conséquente et nous avons trouvé la métaphore très utile lorsque nous avons discuté avec le management du client pour savoir comment gérer cette dette.
La métaphore de la dette nous rappelle les choix que nous pouvons faire avec les défauts de conception. La dette réfléchie pour livrer une version ne vaut peut-être pas le coup d'être remboursée si le paiement des intérêts est suffisamment faible, comme s'il s'agissait de parties du code rarement impactées.
Par conséquent, la distinction utile à faire n'est pas entre ce qui est ou non de la dette, mais entre une dette réfléchie ou irréfléchie.
Il y a une autre distinction intéressante à faire dans l'exemple que je viens d'exposer. Non seulement il y a une différence entre une dette réfléchie et irréfléchie, mais il y a aussi une différence entre une dette intentionnelle et involontaire. L'exemple de la dette réfléchie est intentionnel parce que l'équipe sait qu'elle va assumer cette dette, et qu'elle a donc évalué si le profit réalisé en livrant plus tôt une version était ou non supérieur aux coûts de remboursement. Une équipe ignorante des pratiques de conception assume une dette irréfléchie sans même réaliser dans quel pétrin elle se met.
Une dette irréfléchie peut ne pas être involontaire. Une équipe peut connaître les bonnes pratiques de conception, même être capable de les mettre en oeuvre, et décider de faire du "rapide et sale" parce qu'elle ne peut pas s'offrir le temps nécessaire à écrire un code propre. Je suis d'accord avec Oncle Bob lorsqu'il dit qu'il s'agit généralement d'une dette irréfléchie, parce que les personnes sous-estiment où se trouve la zone de compromis entre la qualité du code et le délai de mise sur le marché (NdT : DesignPayoffLine). L'intérêt d'une bonne conception et d'un code propre est de vous rendre plus rapide, sinon des personnes comme Oncle Bob, Kent Beck et Ward Cunningham n'auraient pas passé autant de temps à en parler.
Diviser la dette entre réfléchie/irréfléchie et intentionnel/involontaire peut être représenté sous forme d'un quadrant, mais jusque-là j'ai uniquement parlé de trois cases de ce quadrant. Il y aurait donc une dette réfléchie et involontaire ? Même si cela semble étrange, je sais que ça l'est, ce n'est pas seulement habituel mais inévitable pour les équipes qui sont d'excellentes conceptrices.
Je discutais récemment avec un collègue qui venait juste de sortir d'un projet qui a livré un logiciel de grande valeur, avec un client heureux et un code propre. Mais lui n'était pas heureux du code. Il estimait que l'équipe avait fait du bon boulot, mais il se rendait maintenant compte de la façon dont le logiciel aurait dû être conçu.
J'entends cela tout le temps de la part des meilleurs développeurs. L'idée c'est que pendant que vous développez, vous apprenez. C'est souvent le cas, cela peut prendre une année de développement sur un projet avant de comprendre quelle aurait dû être la meilleure approche. Peut-être que l'on devrait planifier des projets en passant une année à construire un système que vous jetez pour ensuite le reconstruire, comme le suggère Fred Books, mais c'est un planning difficile à vendre. Au lieu de cela, c'est le moment où vous réalisez ce que la conception aurait dû être, vous réalisez aussi que vous avez une dette involontaire. C'est le genre de dette dont parle Ward dans sa vidéo.
La décision de payer les intérêts ou de rembourser le capital s'applique encore ici, la métaphore est donc encore utile dans ce cas. Par contre, le problème en utilisant cette métaphore, c'est que je ne peux pas établir un parallèle avec une dette financière réfléchie-irréfléchie. Par conséquent, je pense qu'il serait très difficile d'expliquer aux managers pourquoi cette dette est apparue. Mon point de vue, c'est que ce type de dette est inévitable et que l'on doit donc s'y attendre. Même les meilleures équipes génèrent de la dette pendant le projet, ce qui est une raison supplémentaire pour ne pas accumuler du code sale de façon irréfléchie.
techDebtQuadrant_fr.png