Nel 1992 un programmatore di nome Ward Cunningham doveva spiegare al suo capo, che non scriveva codice, perché il software su cui stavano lavorando andava continuamente rimesso a posto. Usò una parola che il capo conosceva bene: debito. Scrivere codice in fretta, disse, è come contrarre un prestito. Ti permette di muoverti subito, ma da quel momento paghi un interesse su ogni cosa che ci costruisci sopra. Finché restituisci in fretta, il prestito è un buon affare, invece, se non lo restituisci mai, l'interesse ti mangia vivo.
È una delle metafore più fortunate della storia dell'informatica, e anche una delle più fraintese. Cunningham non parlava di codice scritto male per pigrizia. Parlava di codice scritto bene rispetto a quello che si sapeva in quel momento, con l'impegno implicito di tornare a sistemarlo quando si fosse capito di più. Il debito, nella sua versione originale, è un atto onesto: una scorciatoia consapevole che ci si ripromette di ripagare. Il problema nasce quando la promessa non viene mantenuta, ci si dimentica del prestito, e si continua a costruire come se non esistesse.
Vale la pena tenerlo a mente, perché chiarisce subito una cosa: il debito tecnico non è pigrizia e nemmeno il segno che qualcuno ha lavorato male. Quasi sempre è il contrario. È il residuo di decisioni ragionevoli, prese sotto pressione da persone competenti, in un momento in cui erano la cosa giusta da fare.
Cosa succede davvero quando un sistema invecchia
Per capire come si accumula, conviene guardarlo nascere. Prendiamo un sito aziendale, perché è l'oggetto digitale che quasi tutti hanno e quasi nessuno presidia davvero.
Immagina un sito costruito nel 2019, su un CMS solido, con un page builder che permette al marketing di muoversi in autonomia. All'inizio funziona tutto. Poi arriva una campagna che ha bisogno di una landing page per ieri, e qualcuno la mette online in un pomeriggio con un plugin trovato in un tutorial, o portato da un fornitore abituato a lavorare così. Nessuno dei due sa che il sito quello strumento ce l'ha già. La campagna finisce, la landing resta, e gli strumenti per fare la stessa cosa adesso sono due. Sei mesi dopo si migra ad un nuovo Analytics, ma il vecchio tracciamento non viene rimosso del tutto, così per un periodo convivono due sistemi che contano le stesse visite in modo leggermente diverso. Arriva l'esigenza del retargeting e si aggiunge un terzo script. Poi il banner per il consenso, montato sopra a tutto il resto, che però non blocca davvero gli script che dovrebbe bloccare. Il form di contatto viene collegato al CRM tramite un connettore che configura una persona sola, in mezz'ora, e quella persona poi cambia lavoro. Un anno dopo si rinnova l'homepage: nuovi colori, font nuovo, fotografia diversa. Ma le pagine interne, i template delle email, il PDF del listino e la presentazione commerciale restano com'erano.
Nessuna di queste scelte è sbagliata. Ognuna, presa da sola, era la mossa più sensata in quel momento. Eppure la somma produce un sistema che nessuno conosce più per intero. Le pagine si caricano un po' più lente perché tre script di tracciamento partono in cascata. I numeri di Analytics non coincidono esattamente con quelli della piattaforma pubblicitaria, e non si capisce a quale dei due credere. Quando arriva un lead dal form, non è del tutto chiaro dove finisca e se ci finisca davvero. E soprattutto: nessuno tocca volentieri l'header. Là dentro, negli anni, si sono accumulati tre tracciamenti, un pixel, script incollati da persone diverse in momenti diversi, e nessuno ricorda più quale serva a cosa. Toglierne uno sbagliato significa perdere dati senza accorgersene.
Il prestito è stato contratto pezzo per pezzo, senza che nessuno avesse l'impressione di indebitarsi e ora il sistema lo presenta al conto. Quel rischio, quella paura di toccare, quei minuti in più di caricamento, quel tempo perso a riconciliare due dati che dovrebbero essere uno solo: quello è l'interesse.
Il debito è silenzioso finché non hai fretta
La caratteristica più insidiosa del debito tecnico è che, in condizioni di operatività quotidiana, non si vede. Il sito funziona, le email partono, i lead arrivano. Tutto sembra a posto perché il sistema viene usato sempre nello stesso modo, lungo i percorsi che ormai si conoscono a memoria.
Il technical debt si manifesta esattamente nel momento in cui si deve accelerare. Quando serve lanciare una nuova linea, riposizionare il brand, aprire un mercato, costruire un funnel di lead generation o, oggi, implementare l'intelligenza artificiale dentro i processi. È lì che si scopre che pubblicare una landing richiede tre persone e una settimana invece di un pomeriggio, che non esiste una fonte unica e affidabile su chi siano davvero i tuoi clienti, che il rebranding fatto sulla homepage non è mai arrivato sui documenti che leggono davvero le persone. La velocità che ti serve non c'è, e non perché manchino le idee o le risorse per eseguirle, ma per la carenza dell'infrastruttura che sostiene il sistema.
Questo è anche il motivo per cui il debito tecnico viene quasi sempre sottovalutato dal management. Non compare in nessun report, non fa rumore, non rompe niente di visibile; è un costo reale che però non ha una riga di bilancio dedicata, e per questo è facile far finta che non esista, fino al giorno in cui blocca qualcosa di importante.
Dove il problema tecnico diventa un problema di brand
C'è un punto in cui questa storia smette di appartenere solo ai tecnici, ed è proprio quello che interessa di più a chi si occupa di comunicazione. Un brand, oggi, non vive solo nel logo o nel tono di voce bensì vive nell'esperienza completa: la velocità con cui si apre una pagina, la pulizia di un form, la coerenza tra l'email che ricevi e il sito che visiti, l'affidabilità del dato che ti fa arrivare il messaggio giusto invece di quello sbagliato. (da controllare) Una campagna che comunica valore ma porta a una landing lenta crea una dissonanza che l'utente la sente percepisce ancora prima di leggere il copy. Una promessa di innovazione appoggiata su modelli datati e meccanici genera sfiducia, perché la forma smentisce il contenuto.
Si potrebbe dire così: ogni punto di attrito tecnico è anche un punto di attrito narrativo. Quando il sistema è appesantito dal debito, la promessa non viene meno perché manca l'intenzione, ma perché manca la capacità di onorarla con la fluidità che il messaggio prometteva
L'intelligenza artificiale non risolve la confusione. La scala.
Qualunque discorso sui sistemi digitali, oggi, finisce per incrociare l'AI, e vale la pena affrontare l’argomento senza retorica. L'intelligenza artificiale promette di accelerare tutto: codice, contenuti, automazioni, report, personalizzazione.
Qualunque discorso sui sistemi digitali, oggi, finisce per incrociare l'AI, che l’intelligenza artificiale velocizzi tutto (codice, contenuti, automazioni, report…) è ormai assodato; il problema è che questa accelerazione è cieca perché non distingue ciò che è in ordine da ciò che non lo è. Quando la AI si appoggia su dati non verificati e processi opachi finisce per produrre l'opposto della semplificazione che promette. Un chatbot addestrato su informazioni vecchie, per esempio, continuerà a rispondere con la stessa sicurezza cose che non valgono più, mentre un modello lasciato libero di produrre contenuti senza un'architettura editoriale restituirà volume privo di coerenza. Su un sistema indebitato l'AI funziona da moltiplicatore, perché amplifica lo stato in cui lo trova, ma orientata nella direzione opposta si rivela altrettanto efficace nel rimettere ordine, dal riconoscere le pagine duplicate al ricostruire la documentazione di automazioni mai scritte nero su bianco, fino a normalizzare le tassonomie di un CRM: operazioni che a mano richiederebbero settimane. Tutto, alla fine, dipende da dove la si orienta: verso la pulizia o verso l'ennesimo strato di disordine.
Come si ripaga il technical debt
Nei sistemi digitali di oggi bisogna avere un'infrastruttura capace di sostenere la velocità e con l’innovazione che promettono, e questo vale sia per il codice che per una strategia di marketing. Il punto non è evitare ogni scorciatoia, perché a volte muoversi in fretta è necessario, ma riconoscere ogni volta il prezzo della scelta che si sta facendo: chiedersi se valga davvero la pena risparmiare un mese oggi per pagarne molti domani, se quel prestito sia inevitabile o se, più semplicemente, si stia rimandando una cura che avrebbe dovuto stare all'inizio. E quando il debito esiste già, ripagarlo non vuol dire rifare tutto da capo, che è il modo più rapido per contrarne uno nuovo e più grande, ma procedere per gradi: un inventario dei sistemi presenti, una classificazione fredda tra ciò che è utile, obsoleto, rischioso o ridondante, una scelta di priorità che parta da ciò che rallenta di più la velocità, sporca di più il dato e incrina di più la coerenza del brand.
Saldare il technical debt è un lavoro scomodo proprio perché sembra invisibile: costa prima di produrre qualcosa di nuovo. Ma ogni sistema, prima o poi, presenta il conto della propria costruzione. Una casa fatta in fretta può stare in piedi per un po', una strategia improvvisata può funzionare per una campagna, un'organizzazione può reggersi per anni su eccezioni, file duplicati e decisioni non documentate; poi arriva il momento in cui serve crescere, cambiare direzione, accelerare, e ciò che sembrava solo un dettaglio tecnico diventa una fragilità insanabile all’interno della struttura.
Il technical debt, in fondo, è ciò che succede quando un'azienda continua ad aggiungere futuro senza prendersi cura del passato. La buona notizia è che questo debito si può rinegoziare, a patto di smettere di fingere che non esista e ponendosi delle domande oneste, essendo disponibili ad accettare le risposte, anche quando queste fanno male.
