Riscrivere il software da zero o sostituirlo un pezzo alla volta?
Riscrivere un software da zero conviene raramente quando il programma è grande e l’azienda non può fermarsi: conviene di più sostituirlo un pezzo alla volta, con il vecchio che resta acceso finché il nuovo non è collaudato. La riscrittura completa ha senso soprattutto per programmi piccoli, poco critici o davvero impossibili da collegare.
L’idea di ripartire da un foglio bianco è attraente, soprattutto quando il software legacy è diventato difficile da mantenere, e spesso è proprio lo sviluppatore a proporla. Il vecchio codice è disordinato e il nuovo sarà perfetto. Vediamo perché di solito le cose vanno diversamente.
Perché la riscrittura sembra la scelta ovvia
Da fuori il progetto sembra semplice: sappiamo già cosa deve fare il programma, basta rifarlo con tecnologie moderne. Si fissa una data, si lavora per mesi e a un certo punto si cambia. Il preventivo è uno e il problema si chiude per sempre.
Martin Fowler, tra gli autori più letti in questo campo, racconta di aver visto questo piano dall’aria semplice fallire nella maggior parte dei casi. Non è una legge di natura, ma è un avvertimento che vale la pena prendere sul serio.
Dove si nasconde il rischio
Il vecchio programma sa cose che nessuno ricorda
Ogni condizione strana nel vecchio codice può essere un errore, oppure la soluzione a un problema reale di dieci anni fa: quel cliente con lo sconto particolare, quella fattura con l’arrotondamento diverso. Joel Spolsky lo spiegò nel 2000 in un saggio rimasto famoso: quel codice brutto sono correzioni di errori, e quando lo butti via butti anche tutta quella conoscenza.
Di solito queste regole non sono scritte da nessuna parte. Emergono quando il nuovo programma sbaglia, cioè il giorno del passaggio.
L’azienda non si ferma ad aspettare
Una riscrittura può richiedere molto tempo. Nel frattempo il vecchio sistema continua a cambiare, perché arrivano nuove norme, nuovi clienti e nuove richieste. Così il traguardo si sposta, e devi scegliere se modificare due programmi o congelare il vecchio.
Spolsky portava l’esempio di Netscape: quando scrisse l’articolo, l’ultima versione importante del browser aveva quasi tre anni, un tempo enorme per quel mercato. Un’azienda più piccola non è Netscape, ma il meccanismo è lo stesso: finché non hai finito, non ottieni alcun beneficio.
Tutto il rischio cade in un solo giorno
Con una riscrittura completa, il momento del passaggio è un salto unico. Tutti gli errori, tutti i dati e tutte le persone da formare arrivano insieme. Se qualcosa non va, tornare indietro è difficile, soprattutto se nel frattempo sono stati inseriti nuovi dati.
Come funziona la sostituzione a pezzi
Con la sostituzione graduale, il nuovo sistema cresce accanto al vecchio. Prima si costruisce un collegamento che permette a entrambi di usare gli stessi dati, poi si sostituiscono i moduli uno alla volta. Il vecchio si spegne solo alla fine.
Non è gratis. Far convivere due sistemi richiede lavoro in più, e il collegamento va costruito e poi dismesso. Fowler stesso ammette che ha un costo, ma ritiene che il minor rischio e il valore ottenuto prima lo compensino.
Dal punto di vista di chi decide, i vantaggi sono soprattutto questi:
- Puoi fermarti. Dopo ogni modulo puoi decidere se proseguire, cambiare priorità o fermarti un momento.
- Vedi i risultati subito. Il primo modulo risolve un problema reale mesi prima della fine del progetto.
- Gli errori restano piccoli. Un problema riguarda un modulo, non tutta l’azienda.
- Le persone imparano per gradi. Si impara una parte alla volta, invece di dover cambiare tutto un lunedì mattina.
Il confronto, punto per punto
| Riscrittura completa | Sostituzione a pezzi | |
|---|---|---|
| Quando vedi i benefici | Alla fine | Dopo ogni modulo |
| Rischio al passaggio | Concentrato in un giorno | Distribuito su più passaggi piccoli |
| Fermo del lavoro | Da pianificare, spesso inevitabile | Si può evitare quasi del tutto |
| Tornare indietro | Difficile | Più semplice, modulo per modulo |
| Costo tecnico extra | Basso | Collegamento e convivenza dei due sistemi |
| Complessità di progetto | Bassa all’inizio, alta alla fine | Costante per tutta la durata |
Quando riscrivere è la scelta giusta
Sarebbe disonesto dire “mai”. Riscrivere tutto insieme può essere la scelta migliore in questi casi:
- Il programma è piccolo. Se si può sostituire in poche settimane, costruire un ponte può costare più che rifarlo.
- Non è critico. Se può restare fermo un giorno senza danni, gran parte del rischio sparisce.
- Le funzioni sono poche e chiare. Tutto si può verificare con facilità, e non ci sono anni di regole nascoste.
- Non c’è modo di collegarlo. Se è impossibile raggiungere i dati del vecchio mentre è in uso, la convivenza può non essere praticabile.
- Stai comunque cambiando il processo. Se il modo di lavorare cambia radicalmente, copiare il vecchio ha poco senso.
Un programma che regge ordini, magazzino e fatture, usato ogni giorno da molte persone, di solito non rientra in questo elenco.
Quattro domande da fare prima di firmare
Vale per qualsiasi fornitore, compresi noi.
- Cosa succede se il primo modulo non funziona? La risposta deve descrivere un meccanismo preciso, non una rassicurazione.
- Quando vedremo il primo risultato utilizzabile? Se la risposta è “alla fine del progetto”, tutto il rischio resta a tuo carico fino a quel giorno.
- Come scoprirete le regole che non sono scritte? Serve un lavoro sul vecchio programma e con chi lo usa, non solo una raccolta di requisiti.
- Chi possiede codice e dati alla fine? La risposta dovrebbe essere semplice: tu.
Per capire quale strada vale nel tuo caso serve guardare il sistema: un audit serve a questo. Il quadro completo delle opzioni è nella guida alla modernizzazione del software legacy, e sul fronte economico trovi i fattori che contano in quanto costa rifare un gestionale. Se il tuo caso è un programma desktop, l’esempio concreto è migrare un’applicazione VB6.
Domande frequenti
La sostituzione graduale costa di più?
Può costare di più in termini tecnici, perché i due sistemi devono convivere. In cambio riduci il costo di un fermo, degli errori al passaggio e di una riscrittura che si allunga. Il confronto va fatto su questi costi, non sul solo preventivo.
Quanto tempo convivono il vecchio e il nuovo?
Dipende dal numero di moduli. L’importante è che il periodo sia pianificato e che abbia una fine: lo spegnimento del vecchio fa parte del progetto fin dall’inizio.
Il mio tecnico dice che il vecchio codice è da buttare. Ha ragione?
Può darsi che il codice sia in cattivo stato, ma questo non dice ancora come sostituirlo. Si può buttare il vecchio codice anche un modulo alla volta, senza affidare tutta l’azienda a un solo passaggio. Per capire quanto pesa davvero il problema, leggi cos’è il debito tecnico.