Cos’è il debito tecnico e come affrontarlo in modo Agile

“Conosci il tuo nemico, conosci te stesso, e in cento battaglie non sarai mai sconfitto”Sun Tzu

La settimana scorsa mi sono imbattuto in questo vecchio articolo di Rands sul managementese. È un grande saggio sulla comunicazione – e come nella vita, quanto sul posto di lavoro – più la comunicazione è chiara, più diventa veloce, in maniera assolutamente naturale.

Frasi strane su cui spesso ridiamo su, come “action item”, o “circling back”, sono in realtà espressioni capaci di esprimere concetti complessi in pochissime parole e di essere compresi veramente da tutti. 

Una di queste espressioni è la grande metafora del debito tecnico.

Cos’è il debito tecnico, significato

Il debito tecnico è ampiamente usato e discusso all’interno dei team di sviluppo per un paio di ragioni che vi elenco di seguito:

• E’ intuitivo e supportato dal buon senso: si tratta di qualcosa che si accumula e ti rende sempre più lento, proprio come l’interesse sul debito esistente;
• Il management lo capisce: ma rimane sotto il controllo del team di sviluppo.

Questi elementi lo rendono una leva perfetta quando si negoziano priorità, scadenze e risorse.

Tuttavia, è davvero così chiaro come sembra?

È un dato di fatto che, con il tempo, tutti i team di sviluppo vengono rallentati dalla code base esistente. Ma perché?
È perché la manutenzione è inevitabile? Oppure perché potremmo fare qualcosa di meglio in primo luogo? O entrambe le cose?

Perché si verifica il debito tecnico?

Se provate a cercare “Technical Debt” su Google e provate a guardare ai primi risultati, troverete una sorta di consenso tra i vari siti o articoli che trattano il tema. Sembra che si tratti di qualcosa che si accumula a causa di alcune “dirty practice”.
Se ciò è vero, potremmo dedurre che se scrivessimo un codice pulito fin dall’inizio (elaborando una perfetta documentazione, facendo test puntuali, ecc.), il debito non si accumulerebbe mai o, quantomeno, ciò succederebbe in maniera ridotta.

Naturalmente, se avete qualche esperienza di lavoro in un team di sviluppatori, sapete che non è vero. Il debito tecnico si insinua anche quando si lavora con le migliori intenzioni e si seguono le migliori pratiche. Ma perché?

Il Technical Debt come “disaccordo”: la metafora di Ward Cunnigham

Provate a dare un’occhiata a questo breve video di Ward Cunnigham.

Ward è l’inventore originale del termine “Debito Tecnico”, ed è interessante sentire la frase in cui questa metafora è stata usata per la prima volta (i grassetti sono miei):

If we fail to make the program aligned with what we understand to be the proper way to think about our […] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

Ward descrive il debito come il risultato naturale dello scrivere codice su qualcosa di cui non abbiamo una comprensione adeguata. Non parla di codice scadente che – secondo lui – rappresenta una parte molto piccola del debito. Parla, invece, di disagreement tra i bisogni del business e il modo in cui il software è stato scritto.

Ma come si arriva a questo disagreement? Nella mia esperienza, ci sono due colpevoli da individuare:

• Wrong Design: quello che abbiamo costruito era sbagliato fin dall’inizio:
• Rapid Evolution: abbiamo costruito la cosa giusta, ma il panorama è cambiato rapidamente e l’ha resa obsoleta.

Vediamoli nel dettaglio 👇

Come ridurre il debito tecnico: partire dal Wrong Design

Può capitare che il team progetti una soluzione che non si adatti alla perfezione ai requisiti di business. I requisiti possono anche essere soddisfatti in superficie, ma qualcosa è sbagliato alla radice (un’astrazione imprecisa, qualche duplicazione, problemi di scalabilità, e così via).

Certamente, questo genere di cose possono verificarsi quando il team ha scarse skill di sviluppo. Ma nella mia esperienza, la maggior parte delle volte ciò accade perché gli sviluppatori non hanno ben capito cosa dovesse essere fatto.
Se questo si verifica regolarmente, la risposta naturale è quella di investire di più nella fase di progettazione.
Questo significa, ovviamente, un’analisi più approfondita da parte degli sviluppatori, ma anche più momenti di confronto con gli stakeholder. Dovreste discutere sia il qui e ora, sia l’evoluzione futura del progetto.

Soffermarsi di più sulla fase di Design può, nel tempo, indebolire i risultati. Dunque, sta a te trovare lo “sweet spot” giusto, che si baserà su quanto è solida la pianificazione della tua azienda rispetto a quanti cambiamenti puoi aspettarti in futuro.

Debito Tecnico svantaggi, la Rapid Evolution: come migliorare?

Il secondo scenario è quando le cose cambiano così rapidamente che non ci si può fidare dei requisiti di oggi. In altre parole: anche se lavoriamo per costruire la cosa giusta, quest’ultima rischia di diventare obsoleta velocemente a causa del panorama aziendale in continua evoluzione.

Una fase di progettazione troppo approfondita fornisce una protezione limitata contro i cambiamenti futuri. Dunque, un ciclo più snello potrebbe funzionare meglio:

1. Rush: scrivere e rilasciare il codice velocemente;
2. Learn: imparare più cose possibili sulla vostra realtà aziendale;
3. Refactor: fare tesoro di quello che si è appreso nello sviluppo del software.

Prendiamo, fondamentalmente, un pezzo dello sforzo di progettazione e lo spostiamo in avanti, in una fase di refactoring che avviene ogni volta che alcuni pezzi si sono consolidati e sono pronti per “essere messi al sicuro”.

In questo scenario, stiamo accettando la creazione di un debito, confidando nella nostra capacità di ripagarlo nel breve termine.

Tutto si può riassumere in tre elementi:

1. Scrivere codice che sia pulito da “refactorare“: che è molto diverso da “pulito”.
   Quel codice sarà simile a quei nodi da marinaio che dovrebbero essere abbastanza forti da reggere per un po’, ma facili da smontare quando non servono più;
2. Imparare davvero lungo la strada: analizzare, anche attraverso l’aiuto degli stakeholder, cosa va ancora bene e cosa sta per trasformarsi in un debito;
3. Dedicare tempo regolare al refactoring: rivedere periodicamente il codice secondo quanto si è appreso.
   E’ facile dimenticarsene, lasciando che il debito si accumuli e diventi tutto troppo oneroso, ma fare piccoli passi alla volta sarà più sostenibile sia per il vostro business che per il vostro team di sviluppo.

Technical debt: key takeaway

Come sempre, provo a riassumere i punti principali dell’articolo in questa sezione finale. Un modo utile a voi lettori, ma anche un controllo per me e per capire se quello che ho scritto ha senso da cima a fondo:

Dunque, se avete fretta, questo è ciò che dovreste ricordare:

1. Il debito tecnico è causato da una mancanza di comprensione: deriva dal disaccordo tra le esigenze del business e dal modo in cui il software è stato scritto;
2. Puoi limitare questo disaccordo: come? Soffermandoti di più sulla fase di progettazione e discutendo in maniera più accurata i requisiti con gli stakeholder;
3. …o lo si può abbracciare: pianificando rilasci “snelli” e seguendo la rielaborazione. Questa, a mio avviso, è la scelta migliore quando il futuro è incerto e potrebbe portare cambiamenti radicali.

Risorse Utili

Alcune risorse che mi hanno aiutato a scrivere questo articolo, e che possono essere utili per scavare più a fondo:

– Debt Metaphor: un breve video di Ward Cunningham che spiega la relazione tra debito e comprensione.

– Technical Debt as a Lack of Understanding: un recente articolo di Dave Rupert che riflette sulla definizione di Ward e aggiunge una preziosa esperienza del mondo reale.

– Technical Debt Quadrant: un saggio di Martin Fowler su cosa sia realmente il debito tecnico e i sulle diverse tipologie.

– Managementese: un grande articolo di Rands sul linguaggio del management e la comunicazione in ufficio.

Qual è la vostra esperienza con il debito tecnico? Fatemelo sapere nei commenti!

Se ti è piaciuto quello che ho scritto e vuoi saperne di più su di me vai su Refactoring.fm e iscriviti alla Newsletter! Questo invece l’articolo in inglese: The True Meaning of Technical Debt.