Dette technique

/ 12 September 2017 / 0 Comments

Qu'est-ce que la dette technique ?

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham en 1992.

C'est un concept de développement de logiciel qui reflète le coût implicite du travail supplémentaire causé par le fait de privilégier une solution facile à implémenter dans l'immédiat à une meilleure approche technique qui prendrait plus de temps.

Il s’agit de l’ensemble des coûts cachés qui grèvent la rentabilité d’un logiciel :

Le coût lié à la perte de productivité des développeurs face à un code source incohérent, inutilement complexe ou de mauvaise qualité : perte de temps pour comprendre le fonctionnement du programme et rechercher de l’information.
Le coût lié à la correction de bugs : perte de temps pour corriger des dysfonctionnements (si cela touche un utilisateur final, il y a en plus une perte d’image pour le logiciel).
Le coût de modification du code source : le logicielle devient de plus en plus difficile à modifier sans effet de bord (défaillances en cascades sur d’autre partie du logiciel).

Elle peut être comparée à la dette monétaire. Si la dette technique n'est pas remboursée, elle peut accumuler des "intérêts", ce qui complique la mise en œuvre des changements par la suite. La dette technique mal gérée augmente l'entropie logicielle. La dette technique n'est pas nécessairement une mauvaise chose et parfois (par exemple, une preuve de concept), elle est nécessaire pour faire avancer les projets. D'un autre côté, certains experts affirment que la métaphore de la "dette technique" tend à minimiser l'impact, ce qui se traduit par une hiérarchisation insuffisante du travail nécessaire pour le corriger.

Lorsqu'un changement est commencé sur le code, il est souvent nécessaire de faire d'autres changements coordonnés en même temps dans d'autres parties du code ou de la documentation. Les modifications requises qui ne sont pas effectuées sont considérées comme des dettes qui doivent être payées à un moment donné dans le futur. Tout comme la dette financière, ces changements inachevés entraînent des intérêts en plus des intérêts, ce qui complique la construction d'un projet. Bien que le terme soit principalement utilisé dans le développement de logiciels, il peut également être appliqué à d'autres professions.

Par ignorance, la dette technique est malheureusement rarement prise en compte. L'évaluation de la perte liée à la dette technique est un exercice complexe car les coûts sont liés à une perte de productivité et sont donc difficiles à évaluer. La correction et la prévention de la dette technique, par l'amélioration du code, est souvent considéré comme un investissement inutile car n’apportant aucune fonctionnalité supplémentaire, tout en pouvant ralentir le projet en consommant du temps de développement.

Quelle relation entre dette technique et agilité ?

L'agilité est à double tranchant, lorsque les bonnes pratiques comme le refactoring sont appliquées, elles peuvent nous aider à éliminer la dette technique. Par contre, lorsque les bonnes pratiques sont négligées, l'agilité peut être une machine génératrice de dette technique.

Gérer la dette technique permet d'être agile sur le long terme.

Résumé

Construire un logiciel de qualité ne veut pas dire rechercher la perfection absolument et bâtir une cathédrale pour chaque produit.
Il ne s’agit pas non plus de construire au plus vite l’application qui répond au besoin mais risque de s’effondrer à tout instant.

Construire un logiciel de qualité, c’est chercher cet équilibre, créer un système qui réponde à des besoins tout en reposant sur des bases saines.