IL DEBITO TECNICO

Introduzione

È un normalissimo giovedì mattina del mese di gennaio per un’impresa specializzata nel settore IT,  i programmatori stanno lavorando a delle nuove funzionalità su un nuovo software che l’azienda vuole proporre.

Tutto sta procedendo tranquillamente come pianificato dal project manager a inizio settimana, ma a un certo punto sopraggiunge un fatto che destabilizza i piani: i responsabili dell’area marketing e commerciale vogliono anticipare la deadline di 10 giorni per necessità incombenti da parte di un cliente molto importante.

Qual è la scelta giusta da fare in questo momento? Seguire le procedure come da protocollo, con il rischio di non soddisfare il cliente, o ridurre i tempi di rilascio per andare incontro alle richieste pervenute? Privilegiare la qualità del codice prodotto o soddisfare le esigenze di bilancio economico e di soddisfazione del cliente?

Alla fine si sa, il cliente ha sempre ragione; i programmatori sono costretti a ridurre drasticamente le tempistiche, tagliando le attività di controllo qualità e di ottimizzazione del codice.

Risultato?

• Il reparto marketing e commerciale riuscirà a esaudire le richieste pervenute;
• il cliente si riterrà appagato del prodotto e soprattutto del servizio tempestivo;
• i programmatori riusciranno a compiere tutti i task in tempi record.

Ma siamo sicuri che vi siano solo aspetti positivi da questa situazione? Effettuiamo un’analisi più approfondita, perché in questo scenario si annida un nemico insidioso: il debito tecnico.

Tech deb: siamo consapevoli?

Il debito tecnico è un termine che sentiamo spesso nominare, ma ne conosciamo realmente il significato?

Esso rappresenta l’incremento dei costi nel tempo, compresa la perdita di agilità da parte dell’azienda, sulla base di decisioni adottate in passato con l’illusione di risparmiare tempo e denaro sul rilascio di un nuovo sistema o sulla manutenzione di uno già esistente.

Il debito tecnico può essere paragonato al debito reale, ovvero qualcosa che si paga nel tempo con interessi ben superiori a quelli che si prevedeva. Tutto ciò si concretizza quando alcune attività vengono “rimandate” in modo tale da rilasciare un applicativo più velocemente. Ma, a differenza del debito finanziario, quello tecnico è subdolo perché non si percepisce e risulta di difficile interpretazione.

Debito tecnico: scelta strategica o azzardata?

In alcune rare situazioni può essere una scelta oculata per garantire il time to market di un prodotto digitale che deve essere rilasciato entro determinate tempistiche prestabilite. Spostando il focus di osservazione però, si rischia di incorrere in costi elevati se le attività di refactoring o manutenzione dei sistemi vengono costantemente ignorate o rimandate.

Alcuni esempi di situazioni che possono provocare l’accrescere del tech debt sono:

• il mancato utilizzo di procedure di testing strutturate;
• utilizzo di workaround temporanei per far funzionare parti di codice che poi puntualmente diventano definitive;
• l’impiego di sviluppatori che non hanno sufficiente esperienza (duplicazione di codice, mancato utilizzo di opportuni design pattern);
• scelte architetturali prese alla leggera, che portano a un'eccessiva complessità del design prodotto;
• eccessivo lavoro di manutenzione per garantire il funzionamento di un sistema difficile da cambiare o adattare; 
• scelte progettuali nel codice errate e così via.

Nella maggioranza dei casi, il debito tecnico non rappresenta esclusivamente una scorciatoia per compiere un lavoro nel minor tempo possibile, ma un compromesso a cui si scende intenzionalmente. 

Molto spesso ci si può imbattere in porzioni di codice sviluppate da altre persone e notare che vi siano delle incongruenze o degli errori facilmente riscontrabili a una prima analisi.

Probabilmente, questi errori sono frutto di decisioni basate su un background di informazioni incomplete, considerando i compromessi da adottare e dando priorità a certi elementi a discapito di altri.

Dal momento in cui è stato scritto il codice, le priorità progettuali sono logicamente cambiate e questo comporta necessariamente la concretizzazione del debito tecnico.

Il debito tecnico non è solo una questione tecnica

Per le figure chiave che dirigono un’impresa, comprendere l’importanza del debito tecnico è fondamentale. La manifestazione, e in particolare il suo protrarsi nel tempo, può comportare una moltitudine di costi indiretti difficilmente riscontrabili. Il risultato sarà la loro trasformazione in costi diretti, ovvero debito finanziario.

Debito tecnico non è associato a una specifica voce di costo in bilancio ma si manifesta facendo incrementare altri costi, particolarmente insidiosi se il management o il cliente non sono consapevoli che i compromessi adottati concorrono alla formazione di tech debt. Successivamente questo modus operandi porterà inevitabilmente a costi sproporzionati.

I rischi del debito tecnico nascono proprio dalla sua natura intrinseca, ovvero l’essere “poco visibile”.

Mentre il debito dinanziario è tangibile ed è oggetto di numerosi controlli, tutto ciò non è riscontrabile nel tech debt a meno che in azienda non sia presente un comparto tecnico (tech lead) che sia in grado di analizzare la situazione oppure un management o cliente propenso a comprendere decisioni anche scomode.

Alcuni esempi di costi indiretti citati precedentemente sono:

• la necessità di avere più personale dedicato alla manutenzione di un sistema già esistente;
• il tempo aggiuntivo degli sviluppatori da dedicare allo sviluppo di una funzionalità; 
• i danni causati da malfunzionamento dei sistemi che poi portano ad una conseguente perdita economica o di tempo;
• perdite di dati in casi di attacchi di sicurezza su codice obsoleto;
• produttività ridotta e ore di lavoro perse per applicazioni bloccate.

Ogni azienda ha al suo interno del debito tecnico e questo fattore risulta ancora più accentuato dal fatto che la tecnologia si evolve sempre più velocemente, riducendo così il lasso di tempo con cui il codice diventa obsoleto. 

Precedentemente è stato citato il concetto di antifragile, termine coniato da Nassim Taleb in uno dei suoi libri di maggior successo, L’Antifragile. Prosperare nel Disordine.

Il termine "antifragilità" indica tutti quei sistemi che si evolvono, accrescono o prosperano in contesti di stress e instabilità, come il mercato attuale.

Vi è una  correlazione tra il concetto di Debito Tecnico e Antifragilità. Per rendere efficienti e antifragili i nostri sistemi aziendali, risulterà fondamentale individuare quanto tech debt abbiamo accumulato e i relativi costi, per poi in un secondo momento cercare di ridurre o limitare quello presente.

Come mitigare il debito tecnico? Best Practice

Le modalità per prevenire l’insorgere del debito tecnico non si possono riassumere in una presunta formula “magica”, ma in un insieme di best practice da adottare prima, durante e dopo la realizzazione di un sistema digitale.

Alcune di queste possono essere riassunte in: 

• utilizzo di procedure di test automatizzate per testare in maniera pervasiva e costante un sistema;
• code review per aumentare la qualità del codice;
• budgettizzare una parte delle risorse nel refactoring e manutenzione;
• incentivare un clima aziendale predisposto verso la continua formazione e aggiornamento;
• adottare una visione strategica a lungo termine, evitando esclusivamente di focalizzarsi sulle esigenze del momento;
• limitare le richieste di intervento dell’ultimo minuto all’interno di sprint già pianificati.

Quindi come comportarsi? 

Vogliamo tranquillizzarti: è normale che il debito tecnico sia presente.

Come per il debito pubblico di uno Stato, i problemi reali arrivano quando il debito cresce a tal punto che tutti gli sforzi vanno impegnati esclusivamente per ripagare gli interessi che questo debito ha generato. Di fatto, questo meccanismo non apporterà nessun valore al sistema. 

Il focus deve essere incentrato quindi sul contenimento del debito tecnico entro limiti gestibili e, in particolar modo, essere a conoscenza della sua presenza. Solo attraverso questa presa di coscienza avremmo una visione ad alto livello e saremo in grado di prendere delle decisioni basate sul principio dell’antifragilità.