"Questo codice è irrecuperabile. Dobbiamo riscrivere tutto da zero." Ecco, questa frase costa quanto poche altre nel mondo dello sviluppo software. Ogni volta che la senti, puoi scommettere che la riscrittura è già costata il triplo del previsto, ha preso il doppio del tempo, e alla fine ti ritrovi con gli stessi vecchi compromessi di prima — solo che adesso si chiamano in un altro modo.
Riscrivere tutto da capo è la tentazione più forte, e anche la più rischiosa, per un team di sviluppo. Se sei un CEO, un PM o un founder, dovresti trattare questa scelta come tratteresti un investimento da centinaia di migliaia di euro. Perché, alla fine, è esattamente quello.
Perché il team vuole riscrivere
Prima di tutto, questa voglia di cancellare tutto e ripartire non viene dal nulla. Quando il team dice che il codice è un disastro, non sta inventando. Il debito tecnico esiste, le nuove feature richiedono troppo tempo, i bug spuntano come funghi, e la frustrazione di lavorare su quel codice difficile è reale.
Però c’è un salto logico tra “questo codice è ingestibile” e “dobbiamo buttare via tutto”. Sarebbe come dire: “la casa ha problemi all’impianto idraulico, quindi demoliamola.” A volte serve davvero. Quasi sempre, no.
Riscrivere da zero è così allettante perché ti fa sognare un foglio bianco. Tutti gli errori del passato spariscono, niente più compromessi, niente più codice incomprensibile. Stavolta faremo tutto bene.
Peccato che quel “tutto bene” sia solo un’illusione.
Perché le riscritture vanno male
Il vecchio sistema sa più di quanto pensi
Joel Spolsky l’ha detto nel 2000 e non è cambiato nulla: quel codice brutto, pieno di hack e workaround, contiene anni di conoscenza nascosta. Ogni if strano, ogni commento oscuro, ogni pezzo di codice scritto in emergenza rappresenta un problema già scoperto e risolto, una regola di business che nessuno si ricorda più, ma che è fondamentale.
Riscrivendo da zero butti via tutto questo. E lo riscopri nel modo peggiore: un cliente alla volta che ti segnala un bug che il vecchio sistema, per quanto brutto, gestiva.
I requisiti non aspettano
Mentre il team riscrive, il resto dell’azienda non si ferma. I clienti vogliono ancora nuove feature. I competitor lanciano aggiornamenti. Il mercato si muove.
A quel punto hai due scelte, nessuna delle due bella: o blocchi lo sviluppo del vecchio sistema per concentrarti sulla riscrittura (e il prodotto non evolve per mesi), oppure porti avanti entrambi insieme (il team si divide, le energie si dimezzano, e la riscrittura sembra non finire mai).
Le stime sono sempre sbagliate
Gli sviluppatori sbagliano a stimare quasi per definizione, ma quando si parla di riscritture è ancora peggio. Il team conta solo le cose visibili: le feature. Peccato che il vero lavoro sia tutto quello che non si vede: gestione degli errori, casi limite, integrazioni, migrazioni dati, performance.
La verità? Prendi la stima del team e moltiplica per tre. Se dicono sei mesi, preparati a diciotto. Non è pessimismo, è solo la media di come vanno davvero le riscritture.
I compromessi torneranno
Ecco la parte più dura da accettare.
I compromessi nel vecchio codice non ci sono perché chi c’era prima era incapace. Sono nati perché il business aveva limiti reali: scadenze, budget, richieste che cambiavano all’ultimo. Quei limiti sono ancora qui. Anche il nuovo team, sotto pressione, finirà per fare le stesse scelte.
Dai due anni, e il codice "nuovo" avrà già il suo debito tecnico, i suoi workaround, e qualcuno proporrà: "Riscriviamo tutto da zero." È la stessa dinamica per cui il software non è mai davvero finito.
Cosa fare invece di riscrivere
Refactoring incrementale
Non buttare via tutto. Migliora il sistema un pezzo alla volta. Parti dai moduli che causano più problemi—quelli pieni di bug, quelli dove ogni nuova feature è un incubo—e sistemali uno dopo l’altro.
Il bello di questo approccio? Il prodotto continua a funzionare, il team continua a consegnare, e ogni passo avanti si vede davvero. Non è emozionante come un foglio bianco, ma funziona.
Strangler fig pattern
Se davvero c’è una parte che non si salva, estraila. Costruisci il nuovo componente accanto al vecchio, sposta il traffico poco alla volta, e quando il nuovo funziona (con utenti veri, in produzione), spegni il vecchio.
È la versione più pragmatica della riscrittura: non butti mai tutto insieme, non rischi mai di restare senza sistema funzionante, e puoi fermarti quando vuoi, con qualcosa che già funziona.
Investi nel testing prima di toccare il codice
Se il team ha paura di cambiare perché “potremmo rompere qualcosa”, il primo investimento non è riscrivere. È avere una suite di test. Quando i test coprono i flussi critici, il refactoring diventa sicuro. Senza test, sia la riscrittura che il refactoring sono solo una scommessa.
Scrivi le regole di business
Il vero problema, spesso, non è il codice. È che nessuno sa davvero cosa dovrebbe fare il sistema. Prima di pensare a una riscrittura, fermati e documenta tutte le regole di business. Parla con chi usa il prodotto, con chi lo ha progettato, con chi si occupa dei casi limite. Quella documentazione vale più di qualsiasi nuova versione del codice.
Quando la riscrittura ha senso davvero
Ci sono casi in cui riscrivere è una scelta legittima:
La tecnologia non esiste più. Se il tuo prodotto gira su un framework abbandonato, nessuno sa più svilupparci sopra e non c’è modo di migrare — qui, riscrivere è l’unica via.
Il dominio è cambiato. Magari hai costruito un tool interno che ora dovrebbe diventare un SaaS multi-tenant con migliaia di utenti. L’architettura non regge più. Non è debito tecnico, è proprio cambiato il gioco.
Il codebase è piccolo. Se hai un MVP nato in pochi mesi, riscrivere si può fare. Il rischio è proporzionale alla dimensione: sei mesi di lavoro si rifanno, cinque anni sono un incubo.
In tutti gli altri casi — e fidati, sono la stragrande maggioranza — il refactoring incrementale è la strada giusta.
Le domande da farsi prima di dire sì a una riscrittura
Se sei CEO, PM o founder e il tuo team propone di buttare tutto e ricominciare, chiedi queste cose:
Cosa non funziona esattamente? Se la risposta è vaga (“è un casino”), fermati. Serve un’analisi precisa. Senza, qualsiasi decisione è un salto nel buio.
Abbiamo provato a migliorare il codice, poco per volta? Se no, perché? Spesso ti sentirai dire “ci metteremmo troppo”, che fa sorridere, visto che la riscrittura richiede dieci volte tanto.
Quanto ci costa non fare nulla per sei mesi? A volte il debito tecnico pesa davvero troppo. Ma mettilo nero su bianco: quanto tempo in più per ogni feature? Quanti bug finiscono in produzione? Quanti soldi perdiamo?
Quali funzionalità salteranno mentre riscriviamo tutto? Questo è il costo opportunità che quasi nessuno considera. Mesi senza novità, mentre i concorrenti vanno avanti.
Come spostiamo dati e utenti? Se il team non ha un piano preciso, non è pronto. Punto.
Riscrivere tutto è spesso il sintomo di un problema di processo, non la sua soluzione.
Lo so, è dura da accettare, ma è la verità. Se il team vuole riscrivere tutto, qualcosa si è rotto nel processo — non solo nel codice. Manca il refactoring continuo. Mancano standard. Nessuno trova il tempo per la manutenzione. È debito tecnico che si accumula sprint dopo sprint, senza mai pagarlo.
La riscrittura non aggiusta questo problema. Lo azzera per un po’, tutto qui. Se il processo resta com’era, tra due anni sarai di nuovo nello stesso punto.
Meglio investire nel processo. Meglio investire in refactoring continuo. Meglio dare al team il tempo per lavorare bene, davvero. Costa meno di una riscrittura, e porta più lontano.
Se il tuo team spinge per una riscrittura e sei in dubbio, scrivimi. Ci guardiamo insieme la situazione e ti aiuto a valutare le alternative in modo onesto.
Simone Giusti
Full Stack Developer specializzato in Laravel e Vue.js
