Capita più spesso di quanto si pensi: codice scritto molto bene dal punto di vista tecnico, architettura pulita, test completi. Poi il cliente lo guarda e dice: "Non è quello che mi serve". La scelta tra codice perfetto e codice pragmatico è una delle tensioni più comuni nei progetti software: il codice non esiste per essere elegante, ma per risolvere un problema reale.
La qualità tecnica è importante. Ma solo quando è al servizio del risultato di business. Quando diventa un obiettivo in sé, rischia di rallentare il progetto senza produrre valore percepibile.
Il software è uno strumento
Chi scrive codice sviluppa naturalmente un senso estetico: si impara a distinguere codice chiaro da codice confuso, strutture solide da soluzioni improvvisate. Questa sensibilità è preziosa.
Il problema nasce quando “questo codice non mi piace” diventa un motivo sufficiente per fermarsi e riscrivere, anche se quel codice funziona e nessun utente ne percepisce i limiti.
Il software è uno strumento. Il suo scopo è produrre un risultato. La qualità interna conta, ma è subordinata a ciò che il prodotto deve ottenere all’esterno.
Quando la qualità diventa un costo
Ci sono situazioni ricorrenti in cui l’attenzione alla perfezione tecnica produce più costi che benefici.
- Moduli stabili che vengono riscritti solo per renderli più eleganti.
- Astrazioni create “per il futuro” che non arriva mai.
- Ottimizzazioni di performance su parti del sistema che hanno carichi minimi.
- Refactoring estesi — a volte vere e proprie riscritture da zero — mentre il cliente sta aspettando funzionalità nuove.
In tutti questi casi, il tempo viene investito in qualcosa che migliora il codice, ma non migliora il prodotto percepito dagli utenti.
Il punto non è scrivere codice brutto
“Meglio un codice brutto che funziona” è una frase pericolosa se presa alla lettera.
È una scala di priorità.
- Risolve il problema? Se no, tutto il resto è irrilevante.
- È affidabile? Non deve introdurre bug, problemi di sicurezza o instabilità.
- Si può modificare senza traumi? Nomi comprensibili, struttura ragionevole, assenza di trappole nascoste.
Se queste tre condizioni sono rispettate, il codice è già a un livello adeguato per la maggior parte delle fasi di un progetto. Non serve che sia “da manuale”.
Le situazioni in cui si sbaglia più spesso
Il refactoring non richiesto
Un modulo funziona da mesi senza problemi, ma “internamente è brutto”. Si decide di riscriverlo. Il risultato tipico è tempo speso senza beneficio diretto e, a volte, l’introduzione di nuovi bug in qualcosa che era già stabile.
Il codice che funziona in produzione da tempo è già stato testato dal caso reale. Cambiarlo senza una motivazione di business è spesso un rischio inutile.
L’astrazione prematura
Si introduce un pattern o un livello di astrazione pensando a futuri scenari che, nella pratica, non si presentano. I design pattern hanno valore quando risolvono un problema reale, non quando anticipano un problema immaginario. Questo rende il codice più complesso oggi per un beneficio ipotetico domani.
Le ottimizzazioni premature
Si investe tempo per rendere una parte del sistema estremamente performante quando i volumi reali non lo richiedono. Quel tempo poteva essere investito in funzionalità che gli utenti stavano aspettando.
Le euristiche pratiche: quando fermarsi e quando no
Ecco alcune regole semplici che aiutano a decidere.
Fermati a migliorare il codice se:
- sta causando bug ricorrenti;
- rende molto difficile aggiungere nuove funzionalità;
- nessuno nel team capisce come funziona;
- crea rischi di sicurezza o stabilità.
Non fermarti a migliorarlo se:
- funziona da tempo senza problemi;
- il cambiamento è solo estetico o strutturale;
- il beneficio è percepito solo dagli sviluppatori, non dagli utenti;
- ci sono feature di business più urgenti in attesa.
Queste euristiche aiutano a mantenere la qualità sotto controllo senza trasformarla nell’obiettivo principale.
Il concetto di “abbastanza buono”
“Abbastanza buono” non significa mediocrità. Significa proporzionare lo sforzo al valore.
- Nomi chiari, non necessariamente perfetti.
- Struttura leggibile, non accademica.
- Test sui flussi critici, non ovunque.
- Codice pronto a cambiare, senza prevedere ogni possibile futuro.
Questo livello è sufficiente per permettere al prodotto di evolvere senza rallentare il business.
Per chi decide
Se il tuo team consegna in ritardo ma il codice è sempre “impeccabile”, vale la pena fare una domanda semplice: quanto di quello che state facendo questa settimana sarà visibile o utile per un utente?
Se la risposta è “poco”, probabilmente c’è uno squilibrio tra qualità interna e valore esterno.
Il software migliore non è quello scritto meglio. È quello che risolve il problema giusto, al momento giusto, con il livello di qualità adeguato a quella fase del prodotto.
Simone Giusti
Consulente software strategico
