Debito tecnico è una delle espressioni più temute della tecnologia. Proprio come nella vita, la sola menzione di un debito evoca la sensazione di essere appesantiti, sotto stress. E liberarsi dei debiti è un lavoro ingrato. In particolare, nell’ingegneria del software, il debito tecnico si riferisce generalmente a un sistema che sta invecchiando e consumando tempo prezioso per gli ingegneri. Il debito tecnico è qualcosa da affrontare, gestire, ridurre al minimo per non essere schiacciati dal suo peso.

Una scuola di pensiero che si sta diffondendo afferma che il debito tecnico dovrebbe essere una parte fondamentale del lavoro di tutti gli sviluppatori di software e che, gestendolo in modo proattivo, permette ai team di superare la concorrenza.

Cos’è il debito tecnico?

Originariamente coniato dall’informatico Ward Cunningham nel 1992, il debito tecnico è l’idea che la costruzione di soluzioni a breve termine per i sistemi tecnici comporta una serie di compromessi, con conseguenti obblighi futuri che devono essere rimborsati sotto forma di lavoro di ingegneria.

Come lo ha descritto lo sviluppatore di software Martin Fowler nel 2003: “In questa metafora, fare le cose in modo rapido e approssimativo crea un debito tecnico, che è simile a un debito finanziario. Come un debito finanziario, il debito tecnico comporta pagamenti di interessi, che si presentano sotto forma dello sforzo aggiuntivo che dobbiamo fare nello sviluppo futuro”.

In media, uno sviluppatore di software trascorre più di 13 ore alla settimana per far fronte al debito tecnico, secondo il report Developer Coefficient di Stripe del 2018. Ora, poiché le applicazioni diventano sempre più complesse , la gestione di quel debito non è mai stata così critica.

Il debito tecnico assume una grande varietà di forme. “All’estremità inferiore, può essere una piccola area di codice che richiede refactoring, librerie che devono essere aggiornate o unit test che devono essere corretti”, scriveva lo scorso anno Isaac Sacolick, editorialista di InfoWorld. “Nella fascia più alta, il debito tecnico include la reingegnerizzazione di complesse applicazioni monolitiche, il porting di protocolli di servizi Web obsoleti, il consolidamento di più piattaforme su un unico standard, la pulizia dei dati, la modernizzazione dell’infrastruttura, l’introduzione di pratiche di osservabilità o l’automazione di un backlog di casi di test manuali. Il peggior tipo di debito tecnico è una ‘piattaforma in fiamme’, ovvero una piattaforma con interruzioni e incidenti ricorrenti che hanno un impatto sull’attività”.

Mentre lavorare su qualsiasi cosa descritta come una piattaforma in fiamme può sembrare meno allettante rispetto alla fornitura di nuove brillanti funzionalità, solo attaccando il debito tecnico come una squadra, in modo proattivo e continuo, gli sviluppatori possono evitare problemi a lungo termine.

“La gestione del debito tecnico spesso diventa poco accorta, perché così facendo raramente si risponde a un’esigenza aziendale urgente e, soprattutto per i casi non urgenti, il ROI non è chiaro e quindi percepito come differibile”, ha scritto Sacolick . “È un problema classico per tutto ciò che riguarda la manutenzione, che si tratti di codice o case”.

Guardare più da vicino il debito tecnico

Per Mik Kersten, autore di Project to Product e fondatore di Tasktop, “il debito tecnico deve essere una priorità, e va affrontato in modo proattivo. Sfortunatamente, in molti casi, questo non è un concetto familiare”.

Per molti team di ingegneri, in particolare quelli in organizzazioni in rapida crescita, il debito tecnico può sembrare in contrasto con l’importante lavoro di rilascio di nuove funzionalità. Ma per Honeycomb, CTO e cofondatore di Charity Majors, lo stesso debito tecnologico è “un segno di successo, significa che sei ancora vivo”.

Anche se può essere facile a dirsi, affinché il debito tecnico venga preso sul serio deve avvenire un cambiamento culturale nell’intera organizzazione.

“Riuscire ad avere un vero arretrato che ha la priorità è una sfida per molte imprese, specialmente quelle che arrivano a un punto in cui hanno incentivi per distribuire cose nuove, ma tendono a non avere alcun tipo di incentivo specifico basato sulle prestazioni per gestire allo stesso tempo il loro debito tecnologico”, ha sottolineato Rachel Stephens, analista di RedMonk.

Come farsi carico del proprio debito tecnico

Secondo John Kodumal, CTO e cofondatore di LaunchDarkly,”il debito tecnico è inevitabile nello sviluppo del software, ma essere proattivi sulla riduzione del debito nel tempo è molto più salutare che interrompere altri lavori”.

Questo approccio proattivo alla lotta contro il debito tecnico comporta il trattamento di qualsiasi cosa si possa considerare come debito tecnico come un’altra parte del lavoro di funzionalità da includere nel normale processo Agile.

“Il segreto per mantenere le applicazioni ed evitare, o almeno ritardare, lo stato legacy, risiede nel modo in cui le organizzazioni e i team gestiscono il debito tecnico”, ha scritto Sacolick. La chiave è essere proattivi, il che significa “stabilire politiche, convenzioni e processi per ammortizzare il costo della riduzione del debito nel tempo”.

Molti team saranno tentati di dedicare una certa quantità di capacità per affrontare il debito tecnico, come il 20% di ogni sprint. Tuttavia, Kersten di Tasktop consiglia di adottare un approccio più dinamico che tenga conto del contesto delle prossime scadenze o della capacità del team.

“Dovresti misurare i risultati aziendali e l’investimento nel debito tecnologico e assicurarti che questi si riequilibrino“, ha affermato Kersten. “Rendi visibile il debito tecnico in modo da sapere sempre quanto stai gestendo. Una volta che è visibile, imposta una percentuale di consegna target, che deve essere dinamica nel tempo“.

Per Ben Kus, CTO presso la società di cloud storage Box, il pagamento del debito tecnico è qualcosa che tutti i team di ingegneri devono includere nel loro backlog. “Ovviamente, questa idea viene respinta”, ma Kus non consiglia di scegliere qualcuno per affrontare il debito tecnico.

In Box il lavoro viene diviso in modo uniforme tra i team di ingegneri e si cerca di risolvere i problemi durante il processo di sprint o nelle analisi post evento. “Abbiamo un rigido processo di analisi e identifichiamo le cose da risolvere per evitare che si ripetano gli stessi problemi”, spiega Kus. “Non siamo così presuntuosi nel dire ‘abbandona tutto per risolvere qualcosa’, ma chiariamo che se un problema si ripresenta, diventa un problema di responsabilità. È estremamente spiacevole se è la seconda volta che succede qualcosa”.

Il caso del Financial Times

Il Financial Times ha passato gli ultimi sei anni a rimodellare il suo approccio al debito tecnico. Nel 2015, il sito web del quotidiano britannico era alimentato da un’app monolitica chiamata Falcon. Nel 2016, gli sviluppatori dell’azienda hanno convertito Falcon in un insieme di microservizi chiamato Next. I 332 repository di codice risultanti sono gestiti da un insieme di team con responsabilità definite, che vanno da applicazioni, scoperta di contenuti e annunci, a piattaforme centrali, che sono responsabili da sole di 72 repository.

“Nel giro di circa un anno, le cose hanno iniziato a non andare così bene“, ha detto Anna Shipman, direttore tecnico per i prodotti per i clienti del Financial Times, durante la conferenza QCon che si è tenuta a Londra lo scorso aprile.

I team avevano perso di vista la strategia tecnologica generale e chi possedeva quali servizi. Ciò ha portato a un crescente cumulo di debiti tecnici, “foreste infestate”, ovvero basi di codice orfane che nessuno voleva toccare e un numero sempre più ridotto di ingegneri disposti a intervenire fuori orario.

Reagire richiedeva uno sforzo consapevole per muoversi verso l’ordine, rimuovendo quelle foreste infestate e accettando la complessità in modo che potesse essere gestita in modo più efficace. Solo quando i team avessero avuto la chiara proprietà dei loro stack tecnologici, l’organizzazione avrebbe potuto affrontare in modo più consapevole quei debiti tecnici.

“Non è qualcosa da fare insieme alla normale consegna delle funzionalità, è qualcosa a cui devi dedicare e programmare il tempo per farlo”, ha detto Shipman. “Non è un’operazione una tantum. Non basta fare un po’ di ordine per far andare tutto bene”.

Sebbene non ci sia un approccio rigido per assegnare, per esempio, il 20% del tempo alla gestione del debito tecnico, Shipman ritiene che i team abbiano ora maggiori poteri per bilanciare la consegna delle funzionalità rispetto al debito tecnico.

Coinvolgere il business

Una volta rivalutata la relazione con il debito tecnico attraverso l’ingegneria e che gli sviluppatori hanno compreso il valore del “rallentamento” per affrontare il debito tecnico su base continuativa, la sfida non è finita: bisogna comunicare quel valore al management.

“I responsabili del prodotto e dell’ingegneria dedicano il loro tempo all’aggiunta di valore aziendale, ma a volte il valore più grande è la messa a punto della struttura portante”, ha affermato Majors di Honeycomb.

Affrontare il debito tecnico può essere la prima cosa che viene trascurata nel perseguimento degli obiettivi aziendali, ma è imperativo che i responsabili dell’ingegneria cambino questa narrativa.

“Una delle lamentele più comuni degli ingegneri è che sentono di dover lavorare continuamente sulle funzionalità, mentre il software e gli strumenti con cui lavorano diventano più fragili, incoerenti e frustranti, e diventa sempre più difficile per loro portare a termine il lavoro“, ha scritto David Van Couvering, senior principal architect di eBay, in un post all’inizio di quest’anno.

Tradurre i rischi di questi fragili sistemi spesso richiede di parlare la lingua del business, sottolineando come l’attacco al debito tecnico possa consentire ai team IT di muoversi più velocemente in futuro, garantire che il software sia più sicuro e rendere felici i membri del team o impedire loro di andarsene.

Il rischio di non gestire il debito tecnico

Gestire con successo il debito tecnico richiederà molti sforzi per cambiare culture e modi di lavorare radicati, oltre a migliorare la comunicazione tra l’IT e il business in generale. Gli incentivi a cui gli sviluppatori stanno lavorando potrebbero dover cambiare, ma i rischi di ignorare i crescenti cumuli di debiti tecnici sono potenzialmente esistenziali.

“La tua argomentazione contro il debito tecnico sarà rafforzata se ti concentri sull’aiutare la tua controparte aziendale a capire come le decisioni di oggi aumentano il rischio futuro. Parla della perdita di prevedibilità nel progetto. Mostra come i compromessi di oggi porteranno a un degrado delle prestazioni in futuro”, scriveva nel 2017 Rachel Stephens, analista di RedMonk.

E’ vero che nuove e brillanti funzionalità rendono felici clienti e manager, ma i sistemi carichi di debiti possono portare a una brusca battuta d’arresto, difficile da affrontare a “danno” fatto.