Cos’è il debito tecnico e come evitarlo?

Un incubo? Eppure è proprio così che funziona il debito tecnico, che si trasforma inesorabilmente in un costo e potenzialmente in un debito finanziario.

Non è quindi un argomento solo per “tecnici”, ma lo è anche e soprattutto per chi dirige un’azienda.

Il debito tecnico è presente in tutti i prodotti digitali, ma non è solo una questione tecnica, anzi è soprattutto una questione business che CTO, imprenditori digitali e responsabili aziendali non devono sottovalutare.

In questa puntata spiego cosa è il debito tecnico, perché si verifica, quali sono le sue conseguenze anche e soprattutto a livello business e come evitarlo.

La guida gratuita sul debito tecnico di cui si parla nella puntata si trova all’indirizzo www.debitotecnico.com.

Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.

Trascrizione

Ciao da Alex Pagnoni e benvenuto nel CTO Podcast, dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.

Nella scorsa puntata ho parlato del refactoring e della riscrittura completa di una piattaforma digitale già esistente, che è ciò che si fa spesso quando si accumula troppo debito tecnico.

Ma cosa è questo debito tecnico?

Ed è proprio ciò di cui parlerò in questa puntata, dove spiegherò cosa è il debito tecnico, perché si verifica, quali sono le sue conseguenze anche e soprattutto a livello business e come evitarlo.

Innanzitutto il debito tecnico non è certo una novità, perché è da quasi 30 anni che si usa questo termine, anche se solo in questi ultimi anni soprattutto con lo sviluppo agile è iniziato a diffondersi come concetto.

In sostanza il debito tecnico è il costo che cresce nel tempo oltre alla perdita di agilità della tua azienda sulla base di precedenti decisioni prese per risparmiare tempo o denaro quando si è sviluppato un nuovo sistema o si è fatta della manutenzione su un sistema già esistente.

E proprio come il debito vero, è un qualcosa che si ripaga nel tempo e con gli interessi, spesso ben superiori a quello che ci si aspettava.

Questo succede in particolare quando alcune parti del codice vengono rimandate per far sì che le altre vengano rilasciate più velocemente.

Questo in certi casi nel breve termine può essere una scelta appropriata, ad esempio per garantire il time to market di un prodotto digitale che deve essere rilasciato per una certa data, ma spesso poi successivamente ha un costo enorme se in un secondo momento non vengono gestiti e sistemati, ad esempio dopo che è rientrata l’emergenza di rilasciare il software in tempi rapidi.

Alcuni esempi sono il taglio dei test unitari e funzionali, l’utilizzo di workaround temporanei per far funzionare una parte di codice che poi puntualmente diventano definitivi, l’impiego di sviluppatori che non hanno sufficiente esperienza, codice duplicato senza usare design pattern e tutte quelle cose che portano ad una eccessiva complessità del codice prodotto.

Oppure alla necessità di lavoro di manutenzione per far stare in piedi un sistema, funzionalità difficili da adattare e cambiare, dipendenze che rendono difficili gli aggiornamenti, scelte progettuali nel codice delle quali poi ci si pente, e così via.

In questo senso è però importante chiarire che il debito tecnico non è quasi mai una scorciatoia presa semplicemente per fare le cose alla buona o per pigrizia, per così dire, e neanche un bug, ma è praticamente sempre il frutto di un compromesso preso intenzionalmente.

Come ad esempio la semplice scelta di aggiungere un indice nella colonna di un database è un compromesso a tutti gli effetti, perché decidiamo che la velocità di lettura deve essere più importante della velocità di scrittura o dell’uso dello spazio sul disco.

Lo stesso vale per altri parametri che vengono spesso considerati nel modo in cui si struttura del codice, come ad esempio la velocità di esecuzione, la leggibilità del codice, il tempo o il costo di sviluppo, la facilità nel programmare, la testabilità ma anche certe volte quanto è “figo” o di “moda” strutturarlo in un certo modo rispetto a quello che, tra virgolette, non è più come si fanno le cose oggi.

Oppure può capitare di prendere in carico del codice scritto da altri e riscontrare del debito tecnico, ma anche in questo caso non è che gli sviluppatori venuti prima di noi erano per forza incompetenti o avevano cattive intenzioni.

Molto probabilmente non hanno fatto errori, ma hanno preso attentamente delle decisioni sulla base di informazioni, peraltro quasi sempre incomplete, considerando i compromessi da prendere e decidendo di dare la priorità ad uno o più degli elementi che ho elencato sopra a discapito di altri.

Mentre oggi, magari, quelle priorità sono cambiate e ci ritroviamo a questo punto con quello che è a tutti gli effetti del debito tecnico.

Mi viene in mente un esempio recente di un mio cliente per il quale abbiamo svolto una grossa operazione di refactoring, dove ci siamo ritrovati di fronte ad una grande massa di codice legacy pieno fino all’osso di debito tecnico.

In quel caso, buona parte del problema era derivato dalla necessità di rilasciare rapidamente funzionalità provenienti dalle richieste più disparate di diverse funzioni aziendali senza poter disporre di programmatori dedicati, creando un patchwork di codice immantenibile e pieno di bug che però aveva raggiunto buona parte dello scopo di ottenere rapidamente le funzionalità richieste.

Sistemare quel codice però ha comportato un successivo costo molto elevato per il cliente e il dover rimettere mano a tanti aspetti che non funzionavano a dovere.

Il debito tecnico, da questo punto di vista, non è solo una questione appunto tecnica, è anzi un qualcosa che soprattutto chi non è tecnico e dirige un’azienda deve comprendere pienamente, perché il debito tecnico comporta sempre una serie di costi spesso enormi che però si vedono solo indirettamente e che possono a loro volta trasformarsi in vero debito finanziario.

Dico indirettamente perché il debito tecnico non corrisponde ad una specifica voce di costo in un bilancio, ma si manifesta aggiungendo o incrementando altri costi, sono quindi sostanzialmente dei costi nascosti che proprio per il fatto di non essere immediatamente visibili sono particolarmente insidiosi e pericolosi.

Questo soprattutto se il management o il cliente che impartisce certe direttive non si rendono conto del fatto che i compromessi, o le richieste urgenti, o il “va fatto per questa sera”, il “ah ma costa troppo, fallo più semplice”, e così via portano a debito tecnico che si trasforma necessariamente in costi sproporzionati.

Come ho detto in passato, certe volte quando il proprio team di sviluppo, interno o esterno che sia, fornisce delle stime che possono sembrare non realistiche, è sempre corretto discuterne col team per capirne le ragioni,

Molte volte, e ne parlerò in una puntata apposita del podcast, effettivamente le stime sono sbagliate, e questo accade per tanti fattori.

In questi casi serve un confronto tecnico da parte di una persona che ha delle competenze tecniche e al contempo la capacità di identificare il valore per il business di certe richieste, come dovrebbe appunto essere un CTO.

Però quando poi il team di sviluppo fa presente che per lavorare bene e non ritrovarsi successivamente in un bagno di sangue sono comunque necessari certi tempi o certi costi, bisogna ascoltarlo perché è lì che si genera la necessità di prendere i compromessi più costosi.

Ritornando però al concetto di equivalenza tra debito tecnico e debito finanziario, c’è da aggiungere che il debito tecnico è ancor più insidioso.

Questo perché, mentre il debito finanziario è visibile e le aziende hanno molti controlli per evitare che qualcuno all’interno generi dei costi non a budget che si tramutano in debiti, così non avviene quasi mai per il debito tecnico.

O almeno se non c’è un forte CTO o responsabile tecnologico in grado di governare la situazione e dall’altra parte un management o un cliente disposti a comprendere e valutare attentamente le conseguenze delle decisioni che si prendono.

Certamente non è una bella situazione non sapere quanto debito si ha, o addirittura neanche sapere di essere indebitati.

Così come non è immaginabile essere nella situazione in cui chiunque in azienda può generare debiti senza chiedere il permesso.

In realtà è proprio ciò che avviene con il debito tecnico.

Quali sono i costi indiretti del debito tecnico?

Quindi alcuni di questi costi indiretti di cui ho accennato prima sono ad esempio:

• La necessità di avere più persone dedicate alla manutenzione di un sistema già esistente;
• Il tempo aggiuntivo degli sviluppatori da dedicare nello sviluppo di nuove funzionalità;
• Danni e ordini persi per via di malfunzionamenti dei sistemi;
• Servizio clienti inefficiente che porta a perdita di clienti;
• Multe e perdita di dati in caso di attacchi di sicurezza su codice scritto male;
• Produttività ridotta e ore di lavoro perse per via di applicazioni bloccate;
• Tempo e attenzione dei manager da dedicare ai problemi indotti dal debito tecnico;
• Ecc.

Questi fattori si evidenziano spesso anche in forma di scarsa agilità, così come avviene quando il business deve aspettare mesi per ottenere migliorie applicative apparentemente semplici che poi spesso non funzionano neanche come ci si aspetta.

Questi tipi di sintomi sono causati dall’eccesso di complessità, derivante da scelte architetturali e implementative problematiche basate sui compromessi di cui ho parlato prima e che portano ad anni di modifiche su modifiche, e modifiche alle modifiche stesse.

Questo si può vedere quando il reparto IT, invece di semplificare, aggiunge sempre più strumenti e persone e allo stesso tempo nessuna persona riesce più a spiegare come funziona il sistema da cima a fondo o quali sono le cause radice dei problemi principali.

Quindi è chiaro fino a questo momento che i fattori principali che portano al debito tecnico sono i vincoli relativi alle tempistiche, anche se nel business ovviamente il tempo è in generale un fattore estremamente critico, e la tentazione di ottenere dei risparmi nel breve termine che però si trasformano in maggiori costi nel tempo.

Quando però in azienda si verificano spessi problemi come quelli elencati sopra, come blocchi e incidenti frequenti nella propria piattaforma digitale, il fatto che sviluppare nuove funzionalità o modificare quelle esistenti richiede troppo tempo o che le stime che ci vengono fornite per sviluppare nuovi progetti sono esplosive, bisogna interrogarsi anche lato management se sia ora di valutare a quanto ammonti questo debito tecnico.

E questo va fatto ancora prima di sparare al team di sviluppo pensando che sia composto solo da incompetenti.

Tutto ciò perché ogni azienda ha al proprio interno del debito tecnico, è inevitabile, anche perché la tecnologia si evolve sempre più rapidamente e al tempo stesso l’obsolescenza del nostro codice aumenta con lo stesso ritmo.

Per questo diventa importante verificare quanto debito tecnico ci siamo accollati e quanto ci costa, per poi limitare l’introduzione di nuovo debito tecnico e ridurre quello esistente.

All’indirizzo www.debitotecnico.com ho preparato una guida che si può scaricare gratuitamente contenente ulteriori approfondimenti sul tema del debito tecnico e soprattutto quali sono le modalità per evitarlo e ridurre quello già esistente, basandomi sull’esperienza che abbiamo accumulato in Axelerant nell’analisi del codice di molti clienti che si sono trovati proprio nella situazione che ho descritto e nelle tecniche di refactoring adottate per ridurre il debito tecnico.

Grazie per aver ascoltato questa puntata del podcast dedicata al debito tecnico.

Se vuoi approfondire questo argomento o vuoi riportare la tua esperienza, oppure se vuoi suggerire un argomento per le prossime puntate, puoi scrivere nel gruppo Facebook del podcast cercando CTO Mastermind su Facebook, oltre a scaricare la guida gratuita su www.debitotecnico.com.

Nei prossimi episodi parlerò di vari argomenti tra i quali quello dei tipici problemi che affrontano CTO e imprenditori digitali quando si deve stimare lo sviluppo di nuove funzionalità richieste dal mercato o dal business.

Grazie di nuovo e alla prossima puntata, ciao da Alex.