Riscrivere un software da zero: quando ha senso e quando no

"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. Chi prende decisioni sul prodotto dovrebbe trattare questa scelta come tratterebbe 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: è la media di come vanno davvero le riscritture che ho visto.

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 ha costi di manutenzione continui.

Cosa fare invece di riscrivere

Refactoring incrementale

Non buttare via tutto. Migliora il sistema un pezzo alla volta. Questo è il refactoring incrementale: cambiare e ripulire il codice senza riscrivere l’intero prodotto da capo. Parti dai moduli che causano più problemi, quelli pieni di bug e 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 è una suite di test, non la riscrittura. 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, sta nelle regole di business che nessuno sa davvero spiegare, più che nel codice. 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. Se il tuo prodotto gira su una tecnologia abbandonata, che nessuno sa più mantenere e da cui non esiste una migrazione praticabile, la riscrittura può essere l’unica strada. Lo stesso vale quando il dominio è cambiato davvero: magari hai costruito un tool interno che ora deve diventare un SaaS multi-tenant con migliaia di utenti, e l’architettura originaria non regge più. In quel caso non stai inseguendo il refactoring di un difetto, stai affrontando un cambio di natura del prodotto.

La riscrittura può anche avere senso se il codebase è ancora piccolo. Un MVP nato in pochi mesi si può rifare; cinque anni di lavoro, molto meno. In quasi tutti gli altri casi, però, il refactoring incrementale resta la strada più sensata.

Le domande da farsi prima di dire sì a una riscrittura

Se il tuo team propone di buttare tutto e ricominciare, le domande da fare sono molto concrete. Che cosa non funziona esattamente? Se la risposta resta vaga, del tipo “è un casino”, bisogna fermarsi e pretendere un’analisi precisa. Avete già provato a migliorare il codice poco per volta? Se no, vale la pena capire perché.

Poi c’è il lato economico: quanto ci costa non fare nulla per sei mesi? Quanti bug finiscono in produzione, quanto tempo in più richiede ogni feature, quanti soldi perdiamo? E quali funzionalità smetteremo di sviluppare mentre il team riscrive tutto? Questo è il costo opportunità che quasi nessuno considera.

Infine c’è la domanda più pratica di tutte: come spostiamo dati e utenti? Se il team non ha un piano preciso, non è pronto a riscrivere.

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.