Con questo termine ci riferiamo all'insieme di scorciatoie o agli aspetti negativi che infettano il nostro codice, come ad esempio:
- **design inadatto (cattivo):** un design che una volta aveva senso ma non ha più;
- **difetti:** problemi noti nel software per i quali non abbiamo ancora investito tempo nella rimozione;
- **copertura dei test insufficiente:** aree in cui sappiamo che dovremmo eseguire più test, ma non lo facciamo;
- **test manuali eccessivi:** test manuali quando dovremmo davvero avere test automatizzati;
- **scarsa integrazione e gestione dei rilasci:** esecuzione di queste attività in modo dispendioso in termini di tempo e soggetto a errori;
- **mancanza di esperienza con la piattaforma:** ad esempio applicazioni scritte in COBOL ma non abbiamo molti programmatori esperti;

e molti altri, perché il termine debito tecnico oggi è davvero usato come *segnaposto per un problema multidimensionale*.

Talvolta, contrarre questi **debiti** è inevitabile: inevitabili debiti tecnici maturano indipendentemente dalle misure preventive che adottiamo. Il debito tecnico ingenuo deriva dall'immaturità dei membri del team, dell'organizzazione e/o dei processi. Il debito strategico è qualcosa che potremmo scegliere di assumere quando i benefici derivanti dall'accumulo del debito superano sostanzialmente il costo del debito. Ci sono numerosi punti:
- *pressione per rispettare una scadenza:* provoca debito tecnico sia strategico che ingenuo;
- *tentativo di accelerare la velocità:* al team che esegue il lavoro viene detto di accelerare la propria velocità per raggiungere la data di rilascio desiderata;
- *mito, meno test possono accelerare la velocità:* il mito è che il test sia un sovraccarico aggiuntivo. Ridurre i test aumenterà il debito e ci farà rallentare;
- *il debito si accumula rapidamente in aggiunta al debito tecnico esistente:* il debito tecnico inizia a crescere, iniziano a manifestarsi conseguenze economicamente dannose.

Non sempre contrarre un debito gioca a nostro svantaggio, anzi questo può avere un utilizzo **strategico**. Basti pensare all'esigenza di accelerare determinate parti dello sviluppo per raggiungere degli obiettivi immediati.  

Ciononostante ci sono alcune ripercussioni:
- il debito cresce in maniera imprevedibile e non lineare. Si arriva ad un punto, comunemente chiamato **"tipping point"**, in cui anche la modifica più insignificante potrebbe compromettere tutto. Questo comporta un innalzamento del rischio di business;
- aumento dei tempi di consegna, naturalmente è necessario "ripagare" questi debiti e automaticamente si va ad intaccare lo scheduling previsto;
- aumento dei bug e di difetti del codice con conseguenti problemi di manutenibilità;
- aumento dei costi di sviluppo e di supporto;
- atrofizzazione del prodotto e diminuzione della prevedibilità: per risolvere i problemi è necessario diminuire il numero di nuove feature rilasciate. Oltreché avere numerosi debiti aumenta il margine di incertezza;
- diminuzione dell'interesse del customer, diminuzione delle performance, e frustrazione universale: andando a rallentare l'intera catena di lavoro gli stessi componenti del team oltre che il customer risultano scontenti e non motivati a portare avanti il progetto.

## Far fronte al debito
Per far fronte al debito contratto ci sono un insieme di strategie, tra cui:
- *utilizzare le good-practice:* sfruttare il test driven development, refactoring (*regola del boy-scout*, cioè miglioro il codice ogni volta che ci metto mano). Migliorare la definizione di **completato**;
- *cercare di darne una rappresentazione tangibile:* generalmente si realizza andando a realizzare un *Tecnical Debt Backlog* associato al product backlog.

Inoltre non tutto il debito contratto deve essere necessariamente ripagato. Per esempio, nello sviluppo dei prototipi o di prodotti che hanno vita breve, è inutile andare a pagarne i debiti poiché sono stati concepiti per essere *"usa e getta"*.  

Sarebbe opportuno inoltre: 
- limitare il numero di grandi investimenti e quindi andare a pagare il debito in maniera incrementale;
- cercare di focalizzarsi sui debiti che comportano un alto rischio o un alto interesse;
- ripagare il debito durante lo sviluppo di feature di valore per il customer.

I vantaggi del rimborso durante l'esecuzione del lavoro prezioso del cliente sono:
- allinea il lavoro di riduzione del debito con il lavoro prezioso per il cliente a cui il proprietario del prodotto può dare la giusta priorità;
- rende chiaro a tutti i membri del team di sviluppo che la riduzione del debito tecnico è una responsabilità condivisa e non qualcosa da rinviare e delegare a qualcuno o qualche altro team per ripulire;
- rafforza le capacità tecniche di prevenzione e rimozione dei debiti perché tutti possono esercitarle in ogni momento;
- ci aiuta a identificare le aree ad alto interesse su cui concentrare il servizio tecnico del debito;
- evita lo spreco di ripagare il debito tecnico in aree in cui davvero non è necessario.