Debito Tecnico - esposto

Il significato e l’origine del “debito tecnico”

La metafora del debito tecnico (TD) nel contesto del software è stata coniata da Ward Cunningham che all'epoca stava lavorando alla codifica di un sistema finanziario. Ha utilizzato la metafora per spiegare ai suoi colleghi finanziari le ragioni per il refactoring e la riscrittura di parti di codici man mano che la conoscenza dei requisiti si evolveva.

“Quando si prendono scorciatoie e si consegna codice che non è del tutto adatto all’attività di programmazione del momento, un team di sviluppo incorre in TD. Questo debito diminuisce la produttività. Questa perdita di produttività è nell’interesse del TD”.

La spiegazione originale prevista da Ward era piuttosto ristretta e specifica, ma ora la metafora ha acquisito vita propria:

Al giorno d'oggi il debito tecnico significa diverse cose:

• Codice che deve essere modificato per eliminare scorciatoie problematiche, create prima della nostra comprensione evoluta di ciò che è necessario. (significato originale).
• Codice difettoso.
• Difetti nell'architettura e nel design che erano scorciatoie create da decisioni tattiche
• Codice difficile da mantenere
• Codice che dipende da librerie, sistemi operativi o altri componenti tecnici non aggiornati
• Difetti nei requisiti che sono stati creati perché sono state prese scorciatoie per comprendere i requisiti.

La distinzione tra debito tecnologico, legacy e obsolescenza del software:

Sistemi legacy

TD di solito riguarda le scorciatoie tecniche che sono state prese e che causano problemi. Le applicazioni software e i componenti obsoleti, basati su una tecnologia che oggi non si sceglierebbe, sono spesso classificati come sistemi legacy. Nel momento in cui furono costruiti, forse non furono prese scorciatoie, quindi non ci sarebbe stato alcun debito tecnologico. Spesso le persone classificano erroneamente un sistema legacy come debito tecnologico, mentre in realtà potrebbe essere prossimo all’obsolescenza. Se un sistema legacy dispone di interfacce adeguate con altri sistemi e svolge il suo ruolo principale in modo impeccabile, potrebbe essere legacy ma potrebbe non essere né TD né obsoleto. Quando un sistema non è più utile all'azienda, anche se lo è stato per un po', lo consideriamo un obsoleto sistema, non necessariamente TD.

Obsolescenza del software

Il valore di un software per un'organizzazione diminuirà nel tempo. Dopo anni di utilizzo, è probabile che le ragioni economiche per mantenere il vecchio sistema diminuiscano. L'applicazione ha una durata di vita e alla fine è più economico ritirarla o sostituirla piuttosto che mantenerla in funzione. Il software diventa obsoleto quando l'ambiente operativo che deve eseguire non è più supportato (hardware, sistema operativo, librerie) o quando il software stesso non serve più allo scopo per cui è necessario.

Una volta scritto e distribuito un nuovo software, è prudente che i dirigenti pianifichino alcuni anni di aggiornamenti e il suo eventuale pensionamento/sostituzione. La durata economica di un software varia. Alcuni tipi di software diventano obsoleti dopo pochi anni (molti software consumer), mentre altri possono diventarlo solo dopo decenni (ad esempio i sistemi bancari COBOL oi sistemi di registrazione in generale). L’obsolescenza non è la stessa cosa del debito tecnologico. Un software molto affidabile potrebbe diventare obsoleto e tuttavia non avere TD.

Il costo del debito tecnico

Continuando con la metafora finanziaria possiamo dire che per alcune applicazioni software il tasso di interesse su quel TD può essere molto alto, mentre per altre potrebbe essere più basso. Se il costo per l’azienda derivante dalla mancata risoluzione del problema è basso, allora il tasso di interesse sul TD è basso. Il costo complessivo del TD varia a seconda del suo impatto sulle operazioni e sulle direzioni aziendali. Prendiamo ad esempio un progetto in cui vengono prese scorciatoie con i requisiti di qualità. La conseguenza di ciò è che il software DOVRÀ essere riscritto prima di essere pubblicato. Si tratta di una creazione insensata di TD, che è probabilmente evitabile e spiega in gran parte perché alcuni progetti software che trascurano i requisiti sono in ritardo o falliscono. Per la valutazione dell’impatto è necessario un approccio caso per caso, ma per l’entità del debito si può prendere in considerazione un approccio più generico.

Dimensionamento COSMIC del debito tecnico

Il codice TDin può essere misurato in CFP.

Il modo in cui nasce il TD può essere dovuto a requisiti scadenti, decisioni sull'architettura e progettazione e scorciatoie. Ciò si traduce quindi in codice che fa la cosa sbagliata o lo fa in un modo che causerà funzionalità inappropriate.

Quantificazione del debito tecnico

Queste sono le domande che i dirigenti prudenti dovrebbero porsi:

• Quanto è grande il TD?
• Qual è il costo se non risolviamo il problema?
• Qual è il costo se lo facciamo?

Per le organizzazioni che eseguono centinaia di applicazioni con dati operativi e strategici, è utile normalizzare la risposta a queste domande in modo che si possa dare priorità agli investimenti per affrontare il TD.

Dimensioni e costi di riparazione

Il dimensionamento funzionale è un approccio eccellente per standardizzare il dimensionamento del TD. L'unità di misura è il Punto Funzione COSMIC o Punto Funzione. Ad esempio, l'applicazione ha una dimensione totale di 1000 CFP di cui 100 CFP sono interfacce che necessitano di riscrittura (TD). Il costo per CFP o il costo per FP per sostituire o riscrivere la scorciatoia può solitamente essere determinato facilmente utilizzando dati di riferimento. Il costo di riparazione potrebbe essere $800 – $1500 per CFP. L'utilizzo di un approccio di dimensionamento universale significa che può essere applicato a tutto TD nel codice, nella progettazione, nell'architettura e persino nei requisiti. È molto importante considerare anche il costo della migrazione dallo stato prima e dopo, nonché eventuali impatti non tecnici, come le persone e i cambiamenti dei processi.

Impatto sulle imprese

Quando si determina il costo complessivo del TD, è necessario considerare sia l'entità dell'impatto sull'attività sia il costo per ripararlo. L’approccio caso per caso alla valutazione d’impatto è appropriato. E questo di solito può essere determinato solo da personale tecnico e aziendale che collabora per rispondere a “in che misura le scorciatoie tecniche impediscono all’azienda di raggiungere i propri obiettivi”

Esposizione del debito tecnico

Esporre TD è utile in quanto può aiutare a fornire informazioni tempestive per decisioni strategiche sui sistemi software. Ad esempio, un sistema gravato da TD può essere candidato ad una sostituzione anticipata. Mentre un altro software con TD limitato potrebbe essere più adatto per estenderne la durata.

Individuazione del debito tecnico nella tua organizzazione

Se un'applicazione software viene costantemente descritta come inflessibile a causa del modo in cui memorizza/gestisce/struttura i dati, allora potrebbe essere TD che ti trattiene. In altre parole, scorciatoie tecniche o decisioni progettuali inadeguate che non sono mai cambiate per soddisfare le esigenze delle aziende.

Se un progetto volto a implementare alcune novità o modifiche al software sperimenta lunghi periodi di correzione di bug o refactoring, ciò potrebbe essere causato da lavoro con scarsi requisiti che ha generato debito tecnico.

Evitare il debito tecnico

Questo è l'approccio più prudente in assoluto. È l'idea che sia più economico sviluppare il software correttamente la prima volta. Tuttavia, rispettando la definizione originale del termine data da Ward Cunningham, ciò non è possibile. Se la necessità (strategica) e l'utilizzo del software non erano noti al momento della scrittura del codice, allora qualche TD era inevitabile. Tuttavia, dovrebbero essere compiuti tutti gli sforzi possibili per mantenere questa rielaborazione al minimo indispensabile. L'approccio per farlo è quello di concedere tempo e risorse sufficienti per eseguire adeguatamente i requisiti, l'architettura e il lavoro di progettazione prima che inizi la codifica. Ciò dovrebbe esporre le incognite conoscibili in modo da evitare la creazione e l'eliminazione di TD.

Ridurre il debito tecnico

Esistono due approcci generali per ridurre il TD:

1. Eseguire la riscrittura dettagliata per eliminare la scorciatoia o i difetti problematici.

2. Scavalcare il debito. Effettuare una sostituzione completa del TD con un codice riutilizzabile adeguato. ("Leapfrog the Legacy", l'idea di scavalcare l'eredità non è nuova, anche se ho coniato questa frase perché penso che aiuti le persone non tecniche a comprendere il caso di alcune decisioni tecniche coinvolte.)