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.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!