Il debito tecnico non avvisa
Ogni startup che ho auditato aveva lo stesso discorso: «Sappiamo di avere debito tecnico, ma non abbiamo tempo di occuparcene.» Il problema è che il debito tecnico non si comporta come un debito finanziario. Non genera interessi regolari — esplode tutto in una volta, quando è ormai troppo tardi.
Dopo 14 anni e più di 30 audit tecnici, ho identificato 5 segnali che non mentono mai.
1. I tempi di deployment che si allungano
Quando un deployment richiede più di 30 minuti, raramente è un problema di infrastruttura. È un sintomo:
- Test instabili che falliscono in modo casuale e che si rilanciano «incrociando le dita»
- Pipeline CI/CD senza cache che ricostruisce tutto ad ogni commit
- Assenza di feature flags, con conseguente accumulo di codice dietro branch sempre più lunghi
La soglia d'allarme: se il vostro team esita a fare un deployment di venerdì, avete un problema.
Come misurarlo
Tempo medio tra un merge e la produzione
< 15 min → eccellente
15-60 min → accettabile
> 1h → debito critico
2. Le nuove feature richiedono 3 volte più tempo
Se una feature che «dovrebbe richiedere 2 giorni» ne richiede sistematicamente 6, non è un problema di stima. È che ogni modifica richiede di toccare 15 file, comprendere 3 livelli di astrazione inutili, e sperare di non rompere nulla.
Le cause classiche:
- Forte accoppiamento tra i moduli — non si può toccare nulla senza effetti collaterali
- Astrazioni premature create «nel caso servissero» e mai usate come previsto
- Assenza di documentazione sulle decisioni architetturali passate
3. Il bus factor a 1
Se una sola persona comprende il sistema di pagamento, l'integrazione API, o la configurazione del deployment, avete un bus factor di 1. Non è debito tecnico in senso stretto, ma è un rischio che si materializza allo stesso modo: una dimissione, e tutto si ferma.
Segnali concreti
- Le code review sono sempre assegnate alla stessa persona
- Certi file hanno un solo contributore da 12 mesi
- L'onboarding di un nuovo sviluppatore richiede più di 2 settimane
4. Gli errori in produzione sono «normali»
Quando il team tratta gli alert di Sentry come rumore di fondo, qualcosa si è rotto nella cultura della qualità. I sintomi:
- Più di 50 errori irrisolti nel tracker
- Blocchi
try/catchche inghiottono le eccezioni in silenzio - Il monitoring esiste, ma nessuno lo guarda
Da ETX Majelan, la prima cosa che ho fatto al mio arrivo è stata portare l'uptime dal 99,2% al 99,9%. Non con strumenti miracolosi — prendendo ogni errore sul serio.
5. Il team evita certe zone del codice
Se gli sviluppatori aggirano sistematicamente un modulo invece di modificarlo, è il segnale più chiaro di debito tossico. Hanno imparato per esperienza che toccare quel codice significa aprire il vaso di Pandora.
Il test semplice
Chiedete a 3 sviluppatori: «Quale parte del codice vi spaventa di più?» Se tutti e tre danno la stessa risposta, quella è la vostra priorità numero 1.
Come agire
Il debito tecnico non si ripaga tutto in una volta. Ecco l'approccio che utilizzo negli audit:
- Mappare — identificare le zone a rischio (complessità, accoppiamento, copertura dei test)
- Quantificare — stimare l'impatto sulla velocità (quanti giorni persi per sprint)
- Dare priorità — attaccare prima ciò che blocca la velocità, non ciò che disturba i puristi
- Budgettare — allocare il 20% di ogni sprint alla remediation, non uno «sprint debito» ogni 6 mesi
Il debito tecnico non è un fallimento. È il risultato naturale di decisioni prese con i giusti vincoli del momento. Il problema è non misurarlo.