Dette fonctionnelle vs Dette technique dans le développement de logiciels
Auteur : Roman Predein
Source : Functional Debt Vs. Technical Debt In Software Development
Date : 25/04/2020
Traducteur : Fabrice Aimetti
Date : 01/03/2024
Traduction :
Toute personne ayant participé au développement d'un logiciel connaît probablement le terme "dette technique". Il s'agit d'une métaphore brillante issue du monde de la finance qui représente le comportement de la maintenance du code et de l'évolutivité au fil du temps. J'aimerais parler aujourd'hui de la dette logicielle, de la dette fonctionnelle et de la dette technique.
Dette technique
Chaque fois que vous êtes obligé de laisser certaines parties de votre code avec une mention "à faire", "à remanier" (à refactorer) ou "à revoir plus tard", c'est un élément de dette supplémentaire que vous accumulez. De cette façon, vous prenez de l'argent pour acheter du temps. Vous respectez le délai, vous lancez le produit à temps et vous avez un prototype à présenter lors d'un cycle d'investissement. Mais vous ne pouvez pas oublier les réductions de la qualité du code, car il s'agit de votre dette. C'est quelque chose dont vous êtes redevable, c'est quelque chose que vous devez rembourser.
Si vous l'ignorez et que vous continuez à construire dessus, votre produit deviendra progressivement moins stable et moins évolutif, et son coût de maintenance montera en flèche. Pour garder l'analogie avec le monde réel, c'est comme si vous preniez un nouveau prêt pour rembourser celui que vous avez pris plus tôt, de manière répétée.
Au début, tout semble bien se passer. Mais au fur et à mesure que le prêt augmente pour couvrir les intérêts et les autres dépenses, c'est comme une boule de neige que l'on ne peut pas arrêter. C'est pourquoi il est important d'allouer le temps nécessaire au remaniement (refactoring) et même parfois à la refonte des parties du code qui ont été identifiées.
Même si nous connaissons très bien cette situation, nous avons trouvé une solution pour respecter le délai (livrer à temps) et éviter la dette technique. Mais en fin de compte, nous obtenons une nouvelle forme de dette. Quelque chose que j'aime appeler la dette fonctionnelle.
Dette fonctionnelle
J'ai fait une petite recherche sur cette idée et je n'ai trouvé que quelques références sur ce phénomène, et pour être honnête, ce n'est jamais la façon dont je le vois personnellement. Dans cet article de Mark Barnes, le phénomène est décrit comme la non-réalisation du principe de YAGNI. Lorsque nous choisissons un framework très lourd et puissant pour ce qui devrait être un projet "léger" et de petite taille. Lorsque les fonctionnalités que nous offrons surpassent celles dont nous avons besoin, le développement et la maintenance de ces extras deviennent une dette fonctionnelle.
Lorsque j'imagine une dette fonctionnelle, ce n'est pas exactement ce à quoi je pense. La façon dont je vois les choses, c'est que pour livrer le produit dans les délais, la fonctionnalité est mise en œuvre partiellement. La fonctionnalité elle-même subit des réductions. Disons que nous devons livrer un simple formulaire avec quelques champs et la saisie d'un fichier. Comme nous sommes pressés par le temps et que nous ne voulons pas introduire un déficit technique, nous décidons de "simplifier" la fonctionnalité. Nous éliminons le 'drag & drop' pour joindre les fichiers, le support pour les fichiers multiples, et les vérifications des champs sur la légitimité des données saisies.
Notre application fonctionne parfaitement, le code est propre (les parties présentes n'ont pas besoin d'être modifiées) et nous la livrons à temps. C'est un miracle. En fait, ce n'est pas le cas. En faisant cela, nous conservons des données invalides dans notre base de données et l'expérience de l'utilisateur n'est pas assez bonne. Notre code est impeccable et fait exactement ce que nous attendons. Nous n'avons pas de dette technique. Notre dette est fonctionnelle.