Selon Ward Cunningham, une dette technique provient de négligences dans le code auxquelles on apportera des solutions rapides mais incomplètes pour des raisons de délai et de budget. Écrire un code solide et sans faille demande du travail et du temps. C’est pourquoi, dans certaines circonstances, les développeurs optent pour un code rapide afin de gagner du temps et se faciliter la tâche. Cette économie engendre des dettes.
Pour W. Cunningham, cet aspect économique de la programmation n’est pas inhabituel ni contre nature. En revanche, si la dette technique n’est pas compensée par un réusinage du code et si le code n’est pas régulièrement optimisé, le développement devra s’interrompre ou s’arrêter pour payer ces intérêts métaphoriques.
Martin Fowler, auteur de Refactoring: Improving the Design of Existing Code, a étayé la métaphore de Cunningham et a divisé les dettes techniques en quatre types qu’il a représentés dans un quadrant de la dette technique :
| Dette irréfléchie | Dette réfléchie |
Dette intentionnelle | - Délai/budget trop serré
- Réusinage négligé
| - Priorité accordée à une livraison rapide du logiciel et réusinage obligatoire
|
Dette involontaire | - Manque de qualifications
- Documentation insuffisante
- Overengineering
- Anti-patrons
- Érosion du code
| - Un réusinage permanent permet de corriger les erreurs et les défauts de programmation historiques et d’apprendre des erreurs
|