5 segnali d'allarme di un debito tecnico critico

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/catch che 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:

1. Mappare — identificare le zone a rischio (complessità, accoppiamento, copertura dei test)
2. Quantificare — stimare l'impatto sulla velocità (quanti giorni persi per sprint)
3. Dare priorità — attaccare prima ciò che blocca la velocità, non ciò che disturba i puristi
4. 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.