DetteTechnique

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

Auteur : Martin Fowler (@martinfowler)
Source : TechnicalDebt
Date : 01/10/2003 - 21/05/2019


Traducteur : Fabrice Aimetti
Date : 16/05/2020


Traduction :

Les systèmes logiciels sont sujets à l'accumulation de code mal conçu[1], des faiblesses dans la qualité interne qui rendent plus difficile qu'il ne le serait théoriquement de modifier et d'étendre le système. La dette technique est une métaphore, inventée par Ward Cunningham, qui explique comment gérer ce code mal conçu, en le considérant comme une dette financière. L'effort supplémentaire qu'il faut fournir pour ajouter de nouvelles fonctionnalités est l'intérêt payé sur la dette.

Sketch-technical-debt-martin-fowler fr.png

Imaginez que j'ai une structure de code compliquée dans mon code base. Je dois ajouter une nouvelle fonctionnalité. Si la structure du code était claire, il me faudrait quatre jours pour ajouter la fonctionnalité, mais avec ce code mal conçu, il me faut six jours. La différence de deux jours est l'intérêt sur la dette.

Ce qui m'attire le plus dans la métaphore de la dette, c'est la façon dont elle oriente ma réflexion sur la manière de gérer ce code mal conçu. Je pourrais prendre cinq jours pour nettoyer la structure du code, supprimer ce code mal conçu, en remboursant métaphoriquement le principal. Si je ne le fais que pour cette seule fonctionnalité, ce n'est pas un gain, car je prendrais neuf jours au lieu de six. Mais si j'ai deux autres fonctionnalités similaires à venir, alors je finirai plus rapidement en supprimant d'abord le code mal conçu.

En d'autres termes, il s'agit simplement d'utiliser des chiffres et tout responsable disposant d'un tableur devrait faire des choix. Malheureusement, comme nous ne pouvons pas mesurer la productivité (en), aucun de ces coûts n'est objectivement mesurable. Nous pouvons estimer le temps nécessaire pour réaliser une fonctionnalité, estimer ce à quoi elle pourrait ressembler si le code mal conçu était supprimé, et estimer le coût de la suppression du code mal conçu. Mais la précision de ces estimations est assez faible.

Dans ces conditions, la meilleure solution est généralement de faire ce que nous faisons habituellement avec les dettes financières, à savoir rembourser le principal progressivement. Pour la première fonctionnalité, je vais passer quelques jours de plus pour enlever une partie du code mal conçu. Cela peut être suffisant pour réduire le taux d'intérêt sur les futures améliorations à un seul jour. Cela prendra encore plus de temps, mais en supprimant le code mal conçu, je réduis le coût des futures modifications de ce code. Le plus gros avantage d'une amélioration progressive comme celle-ci est que cela signifie naturellement que nous passons plus de temps à retirer le code mal conçu dans les parties que nous modifions fréquemment, qui sont exactement les parties du code base où nous avons le plus besoin que le code mal conçu soit supprimé.

Le fait de penser que l'on paie des intérêts plutôt que le principal peut aider à décider quel est le code mal conçu à traiter. Si j'ai une partie du code base qui est déplorable, un véritable cauchemar à modifier, ce n'est pas un problème si je n'ai pas à la modifier. Je ne déclenche un paiement d'intérêts que lorsque je dois travailler avec cette partie du logiciel (c'est un endroit où la métaphore s'effondre, puisque les paiements d'intérêts financiers sont déclenchés par le temps qui passe). On peut donc laisser les parties du code qui sont mal conçues mais stables. En revanche, les parties du code souvent modifiées nécessitent une tolérance zéro vis-à-vis du code mal conçu, car les paiements d'intérêts sont extrêmement élevés. Ceci est particulièrement important car le code mal conçu s'accumule lorsque les développeurs apportent des modifications sans se soucier de la qualité interne ; plus les modifications sont nombreuses, plus le risque de mal concevoir le code est grand.

La métaphore de la dette est parfois utilisée pour justifier le fait de ne pas tenir compte de la qualité interne. L'argument est qu'il faut du temps et des efforts pour empêcher l'accumulation de la dette. Si de nouvelles fonctionnalités sont nécessaires de toute urgence, il est peut-être préférable d'assumer la dette, en acceptant que cette dette doive être gérée ultérieurement.

Le danger ici est que la plupart du temps, cette analyse n'est pas bien faite. Le code mal conçu a un impact rapide, ralentissant le développement des nouvelles fonctionnalités qui sont demandées rapidement. Les équipes qui font cela finissent par dépasser la limite de leurs cartes de crédit, mais livrent toujours plus tard qu'elles ne l'auraient fait si elles avaient fait l'effort d'améliorer la qualité interne. Ici, la métaphore conduit souvent les gens à s'égarer, car la dynamique ne correspond pas vraiment à celle des prêts financiers. S'endetter pour accélérer la livraison ne fonctionne que si l'on reste en dessous de la limite de rentabilité de l'hypothèse de robustesse de la conception (en)[2], et les équipes atteignent cette limite en quelques semaines plutôt qu'en quelques mois.

Il y a régulièrement des débats pour savoir si les différents types de code mal conçu doivent être considérés comme de la dette ou non. J'ai trouvé utile de réfléchir à la question de savoir si la dette est acquise délibérément et si elle est prudente ou imprudente - ce qui m'a conduit au Quadrant de la Dette Technique (fr).

Lectures complémentaires

  • Pour autant que je sache, Ward a introduit ce concept pour la première fois dans un retour d'expérience lors de OOPSLA 1992. Il a également été discuté sur le wiki.
  • Ward Cunningham a fait une conférence vidéo où il parle de cette métaphore qu'il a créée.
  • Dave Nicolette développe le point de vue de Ward sur la dette technique avec une belle étude de cas de ce que j'appelle la dette intentionnelle prudente (fr)
  • Quelques lecteurs ont communiqué des noms similaires. David Panariti qualifie la programmation crade de programmation déficiente. Il semble qu'il ait commencé à l'utiliser il y a quelques années, lorsqu'elle s'intégrait à la politique gouvernementale ; je suppose que c'est à nouveau à l'ordre du jour maintenant.
  • Scott Wood a suggéré que "l'inflation technique pourrait être considérée comme le retard pris lorsque le niveau actuel de la technologie dépasse celui des fondations de votre produit au point qu'il commence à perdre sa compatibilité avec l'industrie du logiciel. Par exemple, le retard pris dans les versions d'un langage au point où votre code n'est plus compatible avec les compilateurs du marché".
  • Steve McConnell a souligné plusieurs bons points de la métaphore, en particulier la façon dont le fait de maintenir votre dette non intentionnelle à un faible niveau vous donne plus de latitude pour vous endetter intentionnellement quand il est utile de le faire. J'aime aussi son concept de paiements minimums (qui sont très élevés pour régler les problèmes liés aux systèmes embarqués par opposition aux sites web).
  • Aaron Erickson parle du mode de financement Enron.
  • Henrik Kniberg affirme que c'est la vieille dette technique qui pose le plus de problèmes et qu'il est judicieux de plafonner la dette qualitative pour se permettre de la gérer.
  • Erik Dietrich parle du coût humain de la dette technique : les luttes intestines au sein des équipes, les compétences atrophiées et l'épuisement.

Notes

  1. Cruft
  2. DesignStaminaHypothesis