Contenuti
- Una personalizzazione può sembrare una buona idea
- Il sistema continua a evolvere
- Il problema può emergere molti anni dopo
- Quando la conoscenza si perde, aumenta il costo
- L’override è un esempio, non il problema
- Il debito tecnico è anche questo
- Una scorciatoia non è necessariamente una pezza
- La pezza più pericolosa
- Il costo emerge quando il sistema deve cambiare
- Il costo non è soltanto economico
- Il debito tecnico non si elimina evitando ogni personalizzazione
Un sito può funzionare perfettamente e avere già al suo interno un problema che emergerà soltanto molto più avanti.
Non necessariamente perché il codice contiene un errore.
Può essere sufficiente che, nel corso degli anni, siano state aggiunte personalizzazioni, modifiche e soluzioni che nessuno ha più avuto occasione di riconsiderare.
Il risultato è quello che viene comunemente definito debito tecnico.
Una personalizzazione può sembrare una buona idea
Quando nasce un’esigenza, la soluzione più semplice può essere modificare direttamente il comportamento del sistema.
Si aggiunge una personalizzazione.
Si modifica un componente.
Si introduce un override.
Si interviene sul codice esistente.
Il problema viene risolto.
Il sito continua a funzionare.
In quel momento la scelta può essere perfettamente ragionevole.
Il problema può arrivare molto più avanti.
Il sistema continua a evolvere
Nel frattempo il CMS viene aggiornato.
I componenti cambiano.
Il tema viene sostituito o modificato.
Le funzionalità vengono riscritte.
Le tecnologie evolvono.
Ma una personalizzazione introdotta anni prima può rimanere lì.
Il sistema sottostante cambia.
La personalizzazione no.
A quel punto nasce una situazione particolare: una parte del sito continua a dipendere da una scelta fatta in un contesto che non esiste più.
Ed è proprio qui che il debito tecnico può diventare un rischio operativo.
Il problema può emergere molti anni dopo
In una casistica reale, una personalizzazione introdotta molti anni prima era ancora presente nel sistema.
Il problema era che non era più chiaro perché fosse stata realizzata.
Confrontando il codice con una versione più recente era possibile capire che quella modifica serviva a introdurre un comportamento specifico.
Ma mancava un’informazione fondamentale:
era ancora necessaria?
Non era possibile rispondere con certezza.
Rimuoverla avrebbe potuto eliminare una personalizzazione ormai inutile.
Ma avrebbe anche potuto rompere qualcosa che dipendeva ancora da quella modifica.
La soluzione più prudente non era quindi cancellare semplicemente il codice.
Prima bisognava capire.
Quando la conoscenza si perde, aumenta il costo
Questo è uno degli aspetti meno evidenti del debito tecnico.
Il problema non è necessariamente che una personalizzazione sia vecchia.
Il problema è che nessuno sa più spiegare perché esista.
Finché tutto funziona, questa situazione può passare inosservata.
Quando arriva il momento di aggiornare o modificare il sistema, invece, diventa necessario ricostruire quella conoscenza.
Bisogna capire:
- perché è stata fatta quella modifica;
- quale problema risolveva;
- da cosa dipende;
- cosa potrebbe essere influenzato dalla sua rimozione;
- se il comportamento che introduce è ancora necessario.
Il tempo necessario per rispondere a queste domande è già un costo.
L’override è un esempio, non il problema
Il fenomeno può presentarsi in molti modi.
Un override può essere perfettamente legittimo.
Una personalizzazione può essere necessaria.
Una modifica al codice può essere la soluzione migliore disponibile in quel momento.
Il problema nasce quando il sistema continua a evolversi e le personalizzazioni non vengono più riesaminate insieme al resto.
Un componente può cambiare comportamento mentre il codice che lo modifica continua a seguire la logica di molti anni prima.
A quel punto ogni aggiornamento può richiedere un confronto.
Bisogna verificare cosa è cambiato nel sistema originale e cosa è stato modificato localmente.
Il tempo necessario per fare questo lavoro è il costo della complessità accumulata.
Il debito tecnico è anche questo
Il debito tecnico non è semplicemente codice vecchio.
Non è nemmeno sinonimo di codice scritto male.
È il costo futuro che una scelta tecnica può introdurre quando rende più difficile modificare, comprendere o mantenere il sistema.
Come un debito finanziario, può sembrare poco importante quando viene contratto.
Poi arrivano gli interessi.
Ogni aggiornamento può richiedere più attenzione.
Ogni modifica può richiedere più verifiche.
Ogni problema può richiedere più tempo per essere diagnosticato.
E quando nessuno conosce più il sistema nel suo insieme, anche una modifica apparentemente banale può diventare rischiosa.
Una scorciatoia non è necessariamente una pezza
Non tutte le soluzioni rapide sono sbagliate.
Una scorciatoia può essere una scelta perfettamente ragionata.
Se conosci le alternative, hai valutato i costi, comprendi le conseguenze e sai come quella soluzione dovrà essere mantenuta, può essere una scelta sensata.
Diverso è intervenire soltanto perché costa meno.
“Questa soluzione non costa nulla.”
“Per fare l’altra servono cento euro di lavoro.”
Se il confronto si ferma qui, non stiamo necessariamente risparmiando.
Potremmo semplicemente spostare il costo nel futuro.
E se l’intervento elimina soltanto il sintomo senza individuare o risolvere la causa del problema, nella terminologia di Sito Fermo siamo davanti a una pezza.
Una pezza può risolvere immediatamente il problema.
Ma se rimane nel sistema per anni, può diventare difficile persino ricordare che quella parte del sistema era nata come soluzione temporanea.
La pezza più pericolosa
C’è un paradosso.
Una pezza che non funziona viene individuata rapidamente.
Una pezza che funziona può rimanere nel sistema per anni.
Poi il sistema cambia.
La tecnologia evolve.
La persona che aveva realizzato quella modifica non è più coinvolta nel progetto.
E qualcuno, molti anni dopo, si trova davanti a una parte del sistema della quale non conosce l’origine.
A quel punto non deve soltanto risolvere il problema.
Deve prima scoprire la storia del sistema.
Il costo emerge quando il sistema deve cambiare
Il debito tecnico diventa particolarmente evidente durante gli Eventi di Cambiamento.
Un aggiornamento.
Una nuova funzionalità.
Una migrazione.
La sostituzione di un componente.
Un cambiamento dell’infrastruttura.
È in questi momenti che le vecchie decisioni tornano a presentare il conto.
Una soluzione che sembrava conveniente anni prima può rendere oggi più difficile effettuare una modifica che, in un sistema progettato diversamente, sarebbe stata banale.
Per questo il debito tecnico è anche un rischio operativo.
Non perché il sito debba necessariamente rompersi.
Ma perché aumenta la difficoltà di prevedere cosa accadrà quando il sistema cambierà.
Il costo non è soltanto economico
Il debito tecnico può produrre almeno tre tipi di costo.
Tempo.
Serve più tempo per capire e intervenire.
Denaro.
Più tempo significa maggiore costo di sviluppo, manutenzione o assistenza.
Rischio.
Più è difficile comprendere il sistema, più diventa difficile prevedere le conseguenze di una modifica.
E c’è un quarto costo che per un sito può essere ancora più importante:
il tempo durante il quale il sito non riesce a fare ciò per cui è stato realizzato.
Se una modifica richiede giorni invece di ore per essere compresa e ripristinata, quella differenza può diventare un problema operativo.
Il debito tecnico non si elimina evitando ogni personalizzazione
Non è questo l’obiettivo.
Un sistema reale deve evolvere.
Le esigenze cambiano.
Le tecnologie cambiano.
A volte è necessario introdurre soluzioni personalizzate.
Il punto è un altro:
ogni scelta dovrebbe essere fatta sapendo che resterà parte del sistema fino a quando qualcuno non deciderà di rimuoverla.
E prima o poi qualcuno dovrà comprenderla, modificarla o sostituirla.
La domanda quindi non dovrebbe essere soltanto:
“Funziona?”
Ma anche:
“Quanto sarà facile capire, mantenere e modificare questa soluzione quando il sistema cambierà?”
Questa domanda appartiene all’analisi e alla progettazione.
Perché il costo di una scelta tecnica non termina quando il codice viene messo online.
Continua per tutta la vita del sistema.
