Il debito tenico è stato definito nel 1992 da Ward Cunningham per descrivere quello che accade quando si gestisce malamente quello che lui definisce il codice “immaturo”:
Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unconsolidated implementation.
Nei sistemi complessi di oggi il debito tecnico si manifesta anche in:
- Bug noti che non vengono risolti per fare spazio a nuove feature
- Test coverage non sufficiente
- Design architetturale mediocre e bassa qualità del codice
- Codice che non viene cancellato se inutilizzato
- Codice su cui il team non ha esperienza e perciò non riesce a modificare o manutenere.
- Migrazioni incomplete
- Tecnologie obsolete
- Documentazione di bassa qualità
Azioni
Per ridurre intenzionalmente il debito tecnico, secondo Martin Fowler, dobbiamo lavorarci quotidianamente tramite il refactoring.