Secondo Ward Cunningham il debito tecnico deriva dalla negligenza nella programmazione del codice, che, a causa di vincoli di tempo o di budget, porta a una risoluzione dei problemi più rapida, ma errata. Un codice accurato e completo è complesso e lungo. Di conseguenza, gli sviluppatori possono scegliere di utilizzare un codice sporco, per risparmiare tempo e fatica. Questi risparmi sono però ottenuti attraverso il debito.
Per Cunningham questo aspetto economico della programmazione non è insolito o innaturale. Ma se il debito tecnico non viene compensato dal refactoring e il codice non viene regolarmente ottimizzato, lo sviluppo si interrompe o si ferma a causa dei tassi di interesse.
Martin Fowler, autore di “Refactoring: Improving the Design of Existing Code”, ha concretizzato la metafora di Cunningham e ha suddiviso il debito tecnico in quattro tipi, illustrati nel quadrante del debito tecnico qui riportato:
| Debito imprudente | Debito prudente |
Debito volontario | - Mancanza di tempo/budget
- Refactoring trascurato
| - Priorità di consegna rapida del software e impegno nel refactoring
|
Debito involontario | - Mancanza di qualifiche
- Documentazione insufficiente
- Overengineering
- Antipattern
- Code erosion
| - Il refactoring costante corregge errori e carenze di programmazione sviluppati nel tempo e aiuta a imparare dagli questi ultimi.
|