Il debito tecnico nello sviluppo

Oggi parliamo di un tema che spesso e volentieri viene rimosso dalle discussioni nei team Agile: il debito tecnico. Quest'ultimo è tanto pericoloso quanto quello monetario e in fondo è anche un debito monetario: prima o poi devi ripagare entrambi. 

In questo articolo andiamo ad esplorare che cos'è il debito tecnico, come si forma, perché è pericoloso se non viene prontamente affrontato e soprattutto, quali strategie esistono per ridurlo o per evitarlo del tutto. 

Il termine "debito tecnico" (in inglese technical debt) è stato coniato da Ward Cunnigham, uno degli autori del manifesto Agile, per descrivere i compromessi tecnici tra qualità e velocità. Il debito tecnico è confrontabile con quello finanziario. Si effettua una decisione a breve termine per raggiungere velocemente un obiettivo, ma si deve poi convivere con le conseguenze di tale scelta, sotto forma di molta manutenzione, bug o una pessima qualità del codice. 

Il debito tecnico può nascere per diverse ragioni. Tra le più comuni vi sono

Il problema principale è che il debito tecnico rallenta lo sviluppo e abbassa la produttività del team. 

Vediamo ora qualche scenario tipico in cui si può formare il debito pubblico.

Innanzitutto, rilasci affrettati senza garanzia di qualità. Si tratta di un classico: un'azienda vuole portare online una nuova funzionalità nel giro di qualche settimana. Per risparmiare tempo i test e le review del codice vengono completamente saltati. La funzionalità viene rilasciata, ma presenta numerosi bug. Nel giro di qualche mese l'intero team si ritrova impegnato a dover risolvere i bug, invece di creare valore aggiunto. Sicuramente è un valore aggiunto anche non avere bug, ma quello si ottiene alla radice quando non si portano bug al cliente in primis, preservando così anche la propria reputazione. Test automatizzati e peer review sono essenziali, la qualità di un prodotto non deve mai essere trascurata.

Un altro scenario è dato dal codice sorgente senza documentazione. Il team di sviluppo lavora da anni ad un sistema datato che non è stato più aggiornato. Il sistema viene sostituito, ma richiede comunque attenzione e nessuno riesce a capire come funziona il codice. Ogni piccola modifica porta a effetti indesiderati inaspettati che non possono essere ignorati. In casi come questi sono necessari un refactoring continuo e una buona documentazione, ovvero le soluzioni per evitare queste problematiche. Una buona documentazione dovrebbe contenere il necessario per comunicare ai colleghi che subentreranno nello sviluppo che cosa è importante sapere.

Il terzo scenario riguarda le scelte tecnologiche senza prospettive sul futuro. Questo scenario si applica particolarmente nel settore delle start up, dove si tende a scegliere tecnologie veloci, ma poco scalabili. Dopo un paio d'anni si scopre che la tecnologia scelta non riesce più a tenere il passo con i requisiti. Il prodotto è buono, ci sono molti clienti e la migrazione ad una nuova piattaforma è cara e dispendiosa. Quando si tratta di scegliere tecnologie bisognerebbe avere una strategia e un approccio alla scalabilità orientati al lungo termine. Per esempio prevedendo soluzioni cloud, invece di preparare server interni.

Un primo segnale per identificare in anticipo il debito tecnico arriva da revisioni del codice regolari e sistematiche: nel team è importante dedicare momenti di confronto per valutare la leggibilità, la coerenza e la stabilità del codice. Inserire le code review come parte integrante della Definition of Done assicura che nessuna user story sia considerata conclusa senza un’attenta verifica della qualità e della manutenibilità.

Un altro punto chiave per riconoscere il debito tecnico è la qualità del codice. Si possono usare dei tool che misurano la difficoltà di manutenzione di un codice, come problemi di complessità ciclomatica, duplicazioni, scarsa copertura dei test e altre debolezze strutturali che rendono il codice fragile nel tempo.

Infine, esistono indicatori indiretti ma altrettanto significativi: una crescente frequenza di bug, numerosi ticket rimasti aperti a lungo, errori in produzione o rallentamenti nel rilascio di nuove funzionalità sono sintomi di un debito tecnico non affrontato. Tenere traccia di questi segnali consente al team di agire in anticipo, intervenendo sul debito tecnico prima che diventi una vera e propria zavorra per lo sviluppo del software.

Il debito tecnico riduce l'efficienza dello sviluppo IT (in particolare velocità, capacità e morale del team) con cui il sistema IT esistente può essere ulteriormente sviluppato con nuove funzioni e caratteristiche qualitative migliorate.

Spesso peggiora l'esperienza utente (in particolare l'efficienza operativa e la soddisfazione) di un'applicazione sempre più rigida, fragile e lenta, e aumenta il rischio di errori del sistema IT, che nel peggiore dei casi portano a danni professionali significativi.

Infine porta un'azienda a pagare ripetutamente interessi tecnici sotto forma di tempo, qualità e costi (o nervosismo) per il funzionamento, l'ulteriore sviluppo e l'utilizzo del sistema IT.

Il debito si accumula con l'evoluzione del sistema e generalmente aumenta con il progressivo ciclo di vita. Di conseguenza cresce anche l'onere degli interessi. 

Come si può ridurre il debito tecnico o tenerlo a bada in un contesto sano? Innanzitutto, dando la giusta priorità ai debiti tecnici. Non sempre, infatti, sono negativi. A volte ha senso optare per una soluzione a breve termine per raggiungere un obiettivo aziendale. La cosa importante è che questa scelta venga consapevolmente documentata e programmata.

In secondo luogo, integrare frequentemente il refactoring nel processo di sviluppo. Il codice non deve solo essere scritto, ma anche aggiornato regolarmente. Può essere utile il cosiddetto Boy Scout Principle: "Lascia il tuo codice in uno stato migliore di quello in cui lo trovi". È altrettanto cruciale la definizione di "fatto" nel progetto Scrum.

Nei meeting di pianificazione, è necessario includere uno spazio per definire i miglioramenti tecnici. I team che funzionano, riservano consapevolmente il 10-20% di capacità dello sprint per la riduzione di debito tecnico e pianificano lo sprint riempiendolo al 100%.

Un altro aspetto importante riguarda la capacità di prendere sul serio il feedback degli sviluppatori. Gli sviluppatori, specie quelli che lavorano da un pezzo sul progetto, sanno cosa causa il debito tecnico. Se si lavora quotidianamente ad un progetto, si sviluppa anche una buona intuizione su quali sono le cause dei problemi e incontri regolari aiutano a identificare i punti di attrito più grandi. 

Il debito tecnico è una realtà inevitabile nello sviluppo software, ma non per questo deve essere trascurato o ignorato. Come un debito finanziario, può essere utile nel breve termine per guadagnare velocità, ma richiede consapevolezza, gestione e interventi costanti per non compromettere la qualità del progetto nel lungo periodo.

Riconoscerlo, monitorarlo e affrontarlo in modo sistematico - attraverso revisioni del codice, buone pratiche ingegneristiche e strumenti di analisi - consente ai team di mantenere il controllo sul codice e preservare la sostenibilità dello sviluppo. Investire nella riduzione del debito tecnico non è tempo perso, ma un atto di cura verso il futuro del software, la soddisfazione del team e la competitività dell’intero prodotto.