Gestire il debito tecnico senza bloccare la delivery

Il debito tecnico viene spesso trattato come un fallimento morale, un lavoro sciatto di cui qualcuno dovrebbe vergognarsi. Questa visione è sbagliata e porta a decisioni sbagliate. Il debito è uno strumento: a volte si prende deliberatamente una scorciatoia per rispettare una scadenza o testare un'idea, e questa è una scelta razionale. Il problema non è contrarre debito; è farlo alla cieca e non pagarne mai gli interessi. L'obiettivo non è zero debito, ma un debito gestito.

Non tutto il debito è uguale

La metafora finanziaria è genuinamente utile. Alcuni debiti sono prestiti intelligenti a basso interesse; altri sono prestiti predatori che strangolano la vostra velocità. Classificateli con onestà:

• Deliberato e prudente: "Per ora lo hardcodiamo e lo generalizziamo quando avremo un secondo caso d'uso." Accettabile.
• Deliberato e sconsiderato: "Non abbiamo tempo per testare niente di questo." Pericoloso.
• Accidentale: decisioni di design che si sono rivelate sbagliate solo dopo l'evoluzione del prodotto. Inevitabile e normale.

Ciò che conta è il tasso d'interesse, ovvero quanto un determinato debito rallenta il lavoro settimana dopo settimana. Il debito ad alto interesse in un percorso critico vale la pena ripagarlo subito; quello a basso interesse in un angolo stabile che nessuno tocca può restare lì indefinitamente.

Rendetelo visibile

Il debito che non si vede non si può gestire. L'errore più comune è che esiste solo nella testa degli ingegneri senior come un vago disagio. In alternativa:

1. Mettetelo per iscritto. Aprite ticket per il debito noto, con una nota sul problema che causa e su dove si trova.
2. Lasciate segnali nel codice. Una convenzione consistente come // TODO o // DEBT su cui fare grep trasforma la conoscenza tribale in un elenco ricercabile.
3. Osservate i segnali. Un aumento dei bug in un modulo, una delivery sempre più lenta o la stessa area che si rompe ripetutamente indicano dove il debito si sta accumulando.

Rendere il debito leggibile trasforma conversazioni ansiose nei corridoi in un elenco prioritizzato e decidibile.

Ripagarlo in modo continuo, non tutto in una volta

L'impulso di fermare tutto il lavoro sulle funzionalità per uno "sprint di refactoring" tende quasi sempre a ritorcersi contro: il business lo subisce con insofferenza, e una riscrittura massiva è di per sé un rischio. Il rimborso continuo e incrementale funziona molto meglio:

• Riservate una quota di ogni ciclo, diciamo dal 15 al 20 percento, per il debito e la manutenzione. Prevedibile e sostenibile.
• Applicate la boy-scout rule: lasciate il codice un po' più pulito di come l'avete trovato ogni volta che lo toccate per una funzionalità.
• Ripagare il debito dove state già lavorando. Fare refactoring del modulo che state per estendere è conveniente; farlo su un modulo tranquillo e non correlato è speculativo.

Questo mantiene il codebase in salute senza mai fermare completamente la delivery, che è esattamente il punto.

Collegatelo ai risultati di business

Il motivo per cui "dobbiamo fare refactoring" cade nel vuoto è che viene presentato come igiene tecnica. Traducetelo nel linguaggio su cui gli stakeholder agiscono: questo debito è il motivo per cui le ultime tre funzionalità hanno richiesto ciascuna una settimana in più del previsto, oppure è per questo che siamo in allerta ogni weekend. Quando si collega il debito alla velocità di rilascio, all'affidabilità e ai costi, prioritizzarlo smette di essere una battaglia.

L'equilibrio

Gestire il debito tecnico è un esercizio continuo di giudizio, non un progetto di pulizia che si conclude. Contraetelo deliberatamente, tracciatelo apertamente, ripagando dove gli interessi sono più alti, e non lasciate mai che diventi invisibile. Un team che fa questo rilascia velocemente e mantiene un codebase in cui riesce ancora a muoversi un anno dopo: non è necessario scegliere.

Se la vostra delivery sta rallentando e il debito tecnico è il sospettato, parlateci.