Comprendere il debito tecnico

Da Wikipedia: “Il debito tecnico (noto anche come debito di progettazione o debito di codice) è “un concetto della programmazione che riflette il lavoro di sviluppo aggiuntivo che sorge quando si utilizza codice facile da implementare nel breve periodo anziché applicare la migliore soluzione complessiva”.

Il debito tecnico può essere paragonato al debito monetario. Se il debito tecnico non viene ripagato, può accumulare ‘interessi’, rendendo più difficile implementare modifiche in seguito. Il debito tecnico non affrontato aumenta l’entropia del software. Il debito tecnico non è necessariamente una cosa negativa e, a volte (ad esempio, come proof-of-concept), il debito tecnico è necessario per far avanzare i progetti. D’altro canto, alcuni esperti sostengono che la metafora del “debito tecnico” tenda a minimizzarne l’impatto, il che si traduce in una prioritizzazione insufficiente del lavoro necessario a correggerlo.”

Il concetto di debito tecnico proviene dal mondo dell’ingegneria del software, ma si applica al mondo dell’IT e dell’infrastruttura aziendale altrettanto bene. Come nell’ingegneria del software, progettiamo i nostri sistemi e le nostre reti, e prendere scorciatoie nelle nostre progettazioni, il che include lavorare con progetti tutt’altro che ideali, incorporare hardware esistente e altre cattive pratiche di progettazione, produce debito tecnico. Una delle sue forme più significative deriva dall’investire nel “passato” anziché nel “futuro” ed è molto spesso innescata dalla fallacia dei costi sommersi (ovvero gettare denaro buono dietro a denaro cattivo).

È facile vedere ciò accadere nelle aziende ogni giorno. Si elaborano nuovi piani per il futuro ma, prima che vengano implementati, si effettuano investimenti per far continuare a funzionare un vecchio progetto di sistema, per farlo funzionare meglio, per espanderlo o quant’altro. Questo investimento si trasforma poi o in una perdita finanziaria pressoché immediata oppure, più spesso, diventa un incentivo a non investire nei progetti futuri con la stessa rapidità, completezza o, addirittura, a non investirvi affatto. L’investimento nel passato può diventare paralizzante nei casi peggiori.

Ciò accade in numerosi modi ed è generalmente involontario. Spesso gli investimenti sono necessari per mantenere un sistema esistente correttamente funzionante e, in condizioni normali, verrebbero semplicemente effettuati. Ma in una situazione in cui vi è un cambiamento futuro necessario o potenzialmente pianificato, questo investimento può rivelarsi problematico. In molti casi, tuttavia, una migliore analisi dei costi e una pianificazione del triage possono porvi rimedio.

In un esempio non tecnico, immaginate di possedere un’auto datata che ha servito bene ma che è destinata al ritiro tra tre mesi. Tra tre mesi prevedete di investire in un’auto nuova perché quella vecchia non è più conveniente a causa delle continue esigenze di manutenzione, della minore efficienza e così via. Ma prima che arrivi il vostro piano triennale… ovvero, prima che arrivi il vostro piano a tre mesi per acquistare un’auto nuova, la vecchia auto subisce un guasto minore e ora richiede un investimento significativo per restare in funzione. Investire denaro nella vecchia auto sarebbe un nuovo investimento nel debito tecnico. Anziché spendere un’ingente somma di denaro per far funzionare una vecchia auto per qualche mese, anticipare il momento dell’acquisto di quella nuova è ovviamente, sul piano finanziario, drasticamente più sensato. Con le automobili, lo cogliamo facilmente (nella maggior parte dei casi). Risparmiamo denaro, potenzialmente molto, acquistando rapidamente un’auto nuova. Se investissimo pesantemente in quella vecchia, perderemmo tale investimento nel giro di qualche mese oppure rischieremmo di stravolgere la nostra solida pianificazione finanziaria per l’acquisto di un’auto nuova già stabilito. Entrambi i casi sono negativi sul piano finanziario.

Con l’IT funziona allo stesso modo. Spendere una grossa somma di denaro per mantenere un vecchio sistema di posta elettronica sei mesi prima di una migrazione pianificata verso un sistema di posta in hosting sarebbe con ogni probabilità del tutto sconsiderato. L’investimento o va perso pressoché immediatamente quando il vecchio sistema viene dismesso, oppure mina i nostri buoni processi di pianificazione e ci porta a non migrare come previsto e a svolgere un lavoro mediocre per le nostre aziende, perché abbiamo permesso al debito tecnico di guidare il nostro processo decisionale anziché a una pianificazione adeguata.

Spesso un’operazione di triage carente o un’autorità impropria nell’effettuare il triage possono essere il fattore che causa investimenti d’emergenza nel debito tecnico anziché rapidi investimenti orientati al futuro. Questa è soltanto un’area in cui miglioramenti importanti possono affrontare i problemi, ma è un’area di primo piano. Ciò può inoltre essere mitigato, in alcuni casi, attraverso una pianificazione “what if” che preveda piani di investimento già pronti in funzione di emergenze comuni o attese che potrebbero sorgere, le quali possono essere tanto semplici quanto la necessità di espandere la capacità a causa della crescita, esigenza che si presenta prima che entri in gioco la pianificazione dei sistemi.

Un altro ottimo esempio di debito tecnico comune è l’espansione della capacità di storage dei server. Si tratta di uno scenario che vedo con una certa frequenza e che illustra bene il debito tecnico. È comune che un’azienda acquisti server privi di un’ampia capacità di storage interno. O immediatamente o a un certo punto in futuro, serve maggiore capacità. Se ciò accade immediatamente, possiamo constatare che il server acquistato era una forma di debito tecnico dovuta a una progettazione impropria e rappresenta evidentemente una falla nel processo di pianificazione e acquisto.

Ma un esempio più comune è la necessità di espandere lo storage due o tre anni dopo l’acquisto di un server. Le scelte di espansione comuni includono l’aggiunta di un array di storage esterno da collegare al server oppure la modifica del server affinché accolga maggiore storage locale. Entrambi questi approcci tendono a essere ingenti investimenti in un server già datato, un server che ha facilmente superato il quaranta percento o più della propria vita utile. In molti casi, lo stesso investimento, o solo lievemente superiore, in un server completamente nuovo può tradursi in hardware nuovo, CPU più veloci, più RAM, lo storage necessario, progettato e costruito su misura, allineato e con un ciclo di supporto rinnovato, un minore ingombro nel datacenter, un consumo energetico inferiore, tecnologie e funzionalità più recenti, migliori rapporti con i fornitori e altro ancora, il tutto conservando al contempo il server originale da riutilizzare, ritirare o rivendere. Un’opzione spende denaro per sostenere il passato, l’altra spesso può spendere una somma comparabile sul futuro.

Il debito tecnico è un fattore paralizzante per molte aziende. Aumenta il costo dell’IT, talvolta in modo significativo, e può portare a elevati livelli di rischio a causa della mancanza di pianificazione e del fatto che la maggior parte della spesa è basata sull’emergenza.