Dette technique
La dette technique est un concept du développement logiciel inventé par Ward Cunningham en 1992[1]. Le terme vient d'une métaphore, inspirée du concept existant de dette dans le domaine des finances et des entreprises, appliquée au domaine du développement logiciel. Elle désigne la difficulté à faire évoluer et à corriger un code source qui a été mal conçu initialement.
Historique
Le terme est utilisé en mars 1925 dans le domaine littéraire pour décrire l'influence des romanciers français sur la technique des biographes et essayistes anglais[2].
Dans le contexte de l'Informatique, Cunningham trace pour la première fois en 1992 un parallèle entre dette économique et dette technique :
« Sortir une première itération de code, c'est comme s'endetter. Une petite dette accélère le développement tant qu'elle est remboursée rapidement par une réécriture... Le danger survient lorsque la dette n'est pas remboursée. Chaque minute passée sur un code pas tout à fait correct compte comme un intérêt sur cette dette. Des organisations entières peuvent être paralysées sous la charge de la dette d'une implémentation non consolidée, qu'elle soit orientée objet ou autre[3]... »
— Ward Cunningham, 1992
Explication
Un projet de développement logiciel inclut souvent une conception logicielle, formalisée ou non. L'écriture du code source, selon la conception définie, assure la cohérence du projet et facilite sa maintenance :
- maintenance corrective : corriger les bugs informatiques ;
- maintenance évolutive : ajouter de nouvelles fonctionnalités au logiciel.
La dette technique peut être accrue lors d'un codage non optimal. Une conception logicielle négligée induit des coûts futurs, les intérêts, à rembourser sous forme de temps de développement supplémentaire, et des bugs de plus en plus fréquents[4]. La dette technique doit être remboursée rapidement pour éviter l'accumulation de ces intérêts, d'où l'analogie avec le concept de dette financière.
Des projets dépendant d'éléments externes (bibliothèques, API, modèles, architectures, etc.) génèrent également une dette technique, car les éléments externes évoluent en parallèle, ce qui provoque l'obsolescence de certaines parties du code, donc la nécessité de créer des mises à jour.
La dette technique est inévitable dans le développement logiciel et perdure tout au long de la vie du produit. Elle peut cependant être contrôlée, notamment avec l'extreme programming, une méthode axée sur la productivité et la réduction des coûts en informatique et en génie logiciel[5].
Junade Ali écrit à propos du développement PHP en 2014 :
« Le coût lié au non-remboursement de cette dette technique est clair : à terme, la livraison de nouvelles fonctionnalités deviendra si lente qu'il sera facile pour un logiciel concurrent bien conçu de dépasser le logiciel mal conçu en termes de fonctionnalités. D'après mon expérience, un logiciel mal conçu peut également conduire à une main-d'œuvre plus stressée, ce qui conduit à un taux de renouvellement du personnel plus élevé (ce qui affecte à son tour les coûts et la productivité lors de la livraison des fonctionnalités). »
— Junade Ali, Mastering PHP Design Patterns[6]
Intentionnalité et durée (court terme et long terme)
Une dette technique peut être intentionnelle ou non.
Une dette technique non intentionnelle est due à des malfaçons : non-respect de la conception, non-respect des règles de codage, etc. Il n'y a aucun bénéfice à retirer de ce type de dette.
Une dette technique intentionnelle est calculée à l'avance. Puisque favoriser la qualité de la conception augmente la charge de travail, les développeurs d'un logiciel peuvent choisir de sacrifier la qualité pour en retirer un bénéfice. Par exemple, s'il faut rendre rapidement une nouvelle version du logiciel, respecter la conception idéale peut mettre en péril la livraison du produit, causer des répercussions financières ou même légales dans le cas de service-level agreements (SLA). Dans cette situation, l'objectif (la sortie de la nouvelle version) est prioritaire. L'intentionnalité de la dette technique serait donc de contracter une dette à court terme pour favoriser l'évolution du projet à long terme. L'essentiel serait alors de rembourser cette dette rapidement, une fois l'objectif atteint, pour éviter l'accumulation des intérêts.
La dette technique était estimée par le cabinet Gartner à 500 milliards de dollars en 2010[7].
Notes et références
- Gérer la dette technique Écrit par Sven Johann & Eberhard Wolff, traduit par Philippe Mioulet le 20 août 2013
- « Les Nouvelles littéraires, artistiques et scientifiques : hebdomadaire d'information, de critique et de bibliographie », sur Gallica, (consulté le ).
- Ward Cunningham, « The WyCash Portfolio Management System », (consulté le )
- (en) Managing Technical Debt in Software-Reliant Systems [PDF]
- (en) https://www.techopedia.com/definition/27913/technical-debt
- (en) Junade Ali, Mastering PHP Design Patterns | PACKT Books, Birmingham, England, UK, Packt Publishing Limited, , 1re éd. (ISBN 978-1-78588-713-0, lire en ligne), p. 11
- http://www.sciencedirect.com/science/article/pii/S0164121213000022
Voir aussi
- Mesure de la dette technique avec SQALE
- Code smell
- Antipattern
- Érosion de l'architecture logicielle
- Grande boule de boue
- Programmation spaghetti
Liens externes
- (en) Technical debt par Martin Fowler
- (fr) DetteTechnique par Martin Fowler
- (en) Paying Down Your Technical Debt sur Coding Horror
- (en) Technical Debt par Steve McConnell (en)
- (fr) Maîtriser sa dette technique Posté le 11/02/2014par Julien Kirch