Il debito tecnico è come il colesterolo: ce l'hanno tutti, pochi lo misurano
Cosa ho imparato dopo anni passati a inseguire il codice perfetto
[Video Youtube] La moda dei “Fractional”: perché tutti lo scrivono ma sbagliano
Oggi chiunque usa la parola Fractional. Secondo me stiamo sbagliando parola, e stiamo svuotando un concetto che ha un senso preciso. In questo video racconto da dove nasce il Fractional, che esigenza risolve davvero, e perché la C di "chief" non è un dettaglio ma è esattamente il punto. Non è una lezione, è il mio punto di vista. Ognuno poi si chiama come vuole.
👋 Ciao, sono Chri. Fractional CTO e questa è Senza Filtri: la newsletter dove condivido il dietro le quinte del mio viaggio da imprenditore (esperienze, cosa ho imparato e tanti errori) alternando a qualche deep dive sui business che mi incuriosiscono.
Il debito tecnico è quella cosa di cui tutti parlano in astratto, ma che nessuno quantifica mai sul serio.
Prova a chiedere a un CTO: “Quanto debito tecnico avete?” Ti risponderà qualcosa tipo “eh, un po’”, oppure “nella parte di autenticazione c’è da sistemare qualcosa”, oppure il classico “è sotto controllo”. Ma se gli chiedi un numero, una stima, un’idea concreta di quanto tempo il team perde ogni settimana per colpa del debito accumulato, vedrai una faccia che dice tutto.
Non lo sa, nessuno lo sa.
Non compare nei report al board, non ha un KPI in nessuna dashboard, nessun PM lo mette nel backlog come priorità alta.
Non è neanche una questione di competenza dei team, perché ho visto developer bravissimi accumulare debito tecnico come se non ci fosse un domani. Tutto questo perché nessuno gli aveva detto di fermarsi a misurare ogni tanto.
Il colesterolo buono
Qui di solito casca l’asino: non tutto il debito tecnico è cattivo.
Il colesterolo HDL, quello buono, non solo non fa male: tiene pulite le arterie e si porta via quello cattivo. In dosi giuste, serve. Il debito tecnico volontario funziona allo stesso modo. Lo prendi consapevolmente perché in quel momento ti serve qualcos’altro più della perfezione, di solito velocità. Sai esattamente dove stai tagliando l’angolo, sai perché, e da qualche parte (idealmente scritto, non solo nella tua testa) c’è il piano per tornarci.
È debito tecnico? Sì, assolutamente. Ma è debito che hai scelto di prendere, che hai documentato, e che sai dove si trova.
Quando ero un developer alle prime armi non l’avrei mai accettata come scelta. Mi sarebbe sembrata una resa. Ero quello che voleva il codice perfetto, che passava ore a rifattorizzare cose che funzionavano benissimo solo perché non gli piaceva come erano scritte. Manco fossi il custode di un tempio sacro del codice pulito (svegliati Chri)
Ci sono voluti anni e qualche scadenza saltata per capire una cosa semplice: se sai dove hai tagliato, puoi tornare a sistemare. Se non lo sai, sei nei guai. Il punto rimane la consapevolezza e non la perfezione.
Il colesterolo cattivo
E poi c’è l’altro tipo. Quello che si accumula senza che nessuno se ne accorga.
“Tanto lo sistemiamo nella prossima sprint.” “Per ora mettiamo un workaround, poi rifacciamo.” “Funziona, non tocchiamolo.”
Le conosci vero? Se avessi un euro per ogni volta che ho sentito queste frasi, potrei permettermi una Ferrari.
Nella newsletter su come valuto la qualità dei prodotti digitali avevo scritto che le scorciatoie si accumulano e ognuna sembra innocua nel momento in cui la prendi. È vero, ma c’è un pezzo che non avevo raccontato: il debito tecnico cattivo non è solo questione di scorciatoie. È anche questione di contesto perso. Un dev scrive un pezzo di codice con una logica specifica in mente, sei mesi dopo se ne va, arriva un altro che guarda il codice, non capisce perché è fatto così e ci costruisce sopra qualcosa di nuovo. Si ritrova con fondamenta incomprensibili, stratificate.
Il caso peggiore che ho visto è stato di una volta dove il mio team non riusciva più a fare deploy senza rompere qualcosa. Guardando il codice ho trovato un file di configurazione con un commento che diceva: “NON TOCCARE QUESTO FILE. SE LO TOCCHI SI ROMPE TUTTO.” E nessuno sapeva perché, sai come mai? Perché il collega che l’aveva scritto non lavorava più lì da due anni. Quel file era diventato il totem sacro che nessuno osava toccare, attorno al quale tutto il resto doveva girare.
L’abbiamo toccato (guardati questo prima di procedere): https://www.facebook.com/watch/?v=1084588443450)
Si è rotto tutto. Ci abbiamo messo una settimana a rimettere insieme i pezzi e a capire cosa diavolo faceva quel file. Ma almeno adesso il team sapeva come funzionava il proprio sistema, invece di girarci attorno come fosse una maledizione.
Lo zi, se nel tuo codice c’è un file con un commento del genere, sappi che hai un problema.
Come te ne accorgi (prima che esploda)
I sintomi del debito tecnico cattivo non arrivano tutti insieme, si innescano a catena e ognuno preso singolarmente sembra gestibile.
Prima i deploy rallentano. Facevi deploy due volte al giorno, poi una volta al giorno, poi due volte a settimana, poi “quando siamo sicuri che non si rompa niente”.
Siccome i deploy rallentano, il team inizia a raggruppare più modifiche insieme e siccome ogni deploy tocca più cose, i bug aumentano. Correggi qualcosa qui, si rompe qualcos’altro là. A quel punto nessuno si fida più della suite di test (se ce n’è una) e partono i test manuali sempre più lunghi prima di ogni rilascio. Le feature nuove richiedono sempre più tempo perché ogni modifica deve fare i conti con tutto il casino che si è accumulato. Il product manager chiede “quanto ci vuole per aggiungere questa cosa?” e la risposta del team passa da “un paio di giorni” a “dipende” a “non possiamo stimarlo finché non capiamo come si collega al resto”. Quel “dipende” è un segnale fortissimo.
E alla fine c’è il mio indicatore preferito: il tempo di onboarding di un collega nuovo.
Se un developer senior impiega più di due settimane per essere produttivo o c’è debito tecnico, o è un software davvero complesso. Significa che il codice è diventato così intrecciato che nemmeno uno sviluppatore con tanta esperienza riesce a capirlo.
La domanda che faccio sempre ai team quando entro in un nuovo progetto è semplice: “Quanto tempo perdete ogni settimana per colpa di roba che sapete che andrebbe sistemata, ma non avete mai tempo di sistemare?”
Le risposte vanno dal 10% al 40%. Il QUARANTA per cento. Quasi metà del tempo di un team che lavora su cose che non dovrebbe dover fare.
La spending review del codice
Nella newsletter su come risparmio 788 euro l’anno costruendomi i tool con l’AI raccontavo della mia spending review degli abbonamenti: apri il conto, guardi tutti gli addebiti ricorrenti e ti chiedi per ognuno se ti serve davvero.
Il debito tecnico funziona allo stesso modo, serve una spending review sul codice.
Con i miei clienti lo faccio così. Una volta al trimestre, ci sediamo col team tecnico e facciamo una mappa del debito. Non serve niente di complicato: un foglio condiviso dove ogni developer scrive le tre cose del codebase che gli fanno perdere più tempo. Le cose che lo rallentano, quelle dove ogni volta dice “questo andrebbe riscritto”.
Poi le ordini per impatto sul business, non per importanza tecnica, che è la trappola in cui cadono tutti. Quel pezzo di codice bacato nel sistema di pagamenti che costringe il team a fare check manuali ogni settimana? Priorità alta. Quella classe che ha nomi di variabili orrendi ma funziona perfettamente? Può aspettare.
E poi la parte più difficile: comunicarlo ai non-tech. Perché provare a spiegare il debito tecnico a un CEO che vuole solo nuove feature è come spiegare il colesterolo a uno che vuole solo mangiare la carbonara in pace. Non gli interessa il meccanismo, gli interessa capire cosa succede se non se ne occupa.
Io la metto così: “Ogni sprint, il 20% del tempo lo dedichiamo a ripagare debito tecnico. Se non lo facciamo, tra sei mesi quel 20% diventa 40%, e tra un anno il team non riesce più a rilasciare niente.” Di solito funziona, i numeri parlano anche a chi non capisce il codice.
Con un mio cliente abbiamo fatto esattamente questo esercizio: il suo team ha tirato fuori una lista di quattordici cose, sì, ben quattordici. Poi ne abbiamo scelte tre per il primo trimestre, le tre che facevano perdere più tempo in assoluto. Ma le altre undici stanno lì, le sappiamo, ci arriveremo, diciamo che almeno adesso le conosciamo.
Quando il debito tecnico uccide (e quando è giusto tenerlo)
Ho visto startup morire per debito tecnico, non nel senso drammatico del termine, però avevano raggiunto un punto dove aggiungere qualsiasi cosa al prodotto costava così tanto che non riuscivano più a stare al passo col mercato. I competitor più giovani, li superavano in velocità e riscrivere da zero non era un’opzione percorribile, dato che dovevi fermare il prodotto per sei mesi (e non si poteva fare).
Quello è il punto di non ritorno. E ci arrivi un commit alla volta.
Però, e qui devo essere onesto, ci sono situazioni dove il debito tecnico va bene così. Se stai validando un’idea e non sai ancora se il prodotto avrà un mercato, non ha senso investire in un’architettura perfetta. Se il mercato sta cambiando velocemente e devi pivotare, forse quel codice lo butterai via comunque tra tre mesi. Se hai una finestra di mercato stretta e devi entrarci adesso, il debito tecnico è il prezzo di ingresso.
Il punto è che l’obiettivo non è zero debito tecnico. Quello non esiste, è un’utopia da sviluppatore estremista quale ero io a ventitré anni. L’obiettivo è debito tecnico sotto controllo: sai quanto ne hai, sai dove si trova, e hai un piano per gestirlo.
Fai le analisi periodicamente, e quando i numeri salgono troppo intervieni prima che diventi un problema serio. Non è più complicato di così, anche se arrivarci lo è stato eccome.
Quand’è stata l’ultima volta che hai fatto le “analisi del sangue” al tuo codebase?
Rispondi a questa mail, sono curioso di sapere come lo gestite voi.
Ci vediamo alla prossima newsletter.
Senza filtri,
Chri
P.S. Costruiamo insieme Senza Filtri
Ho creato un breve sondaggio anonimo per capire come migliorare la newsletter ed esserti più utile. Se ti va di rispondere a qualche domanda clicca qui (meno del tempo di prendere un caffè). Grazie mille.