Modernizzare il software legacy senza una riscrittura totale

Quasi ogni azienda consolidata ne ha uno: un software che tutti detestano in silenzio. È lento, è brutto, metà del team conosce un trucco per il bug che nessuno ha mai corretto, e l'unica persona che lo capiva se n'è andata nel 2019. L'istinto è sempre lo stesso — buttarlo giù e costruirne uno nuovo. E quell'istinto, più spesso di quanto si creda, è proprio il modo in cui buone aziende perdono un anno e una piccola fortuna per nulla.

Ho visto la grande riscrittura andare storta abbastanza volte da avere un riflesso al riguardo. Un titolare mi mostra il suo cigolante sistema ordini o il suo antiquato strumento di pianificazione, sospira e dice una qualche versione di «dobbiamo solo rifare tutto». E forse un giorno lo farete. Ma la riscrittura completa — strappare via il vecchio sistema, costruirne uno scintillante in parallelo, abbassare un interruttore — è una delle mosse più rischiose in tutto il software. È costosa, richiede molto più tempo di quanto promesso e, per tutta la durata, procedete alla cieca, sperando che il nuovo copra ogni strano caso limite che il vecchio gestiva in silenzio da quindici anni.

La buona notizia è che la riscrittura totale non è quasi mai l'unica opzione, e raramente la migliore. Esiste un modo più sereno di modernizzare — incrementale, reversibile e rispettoso dell'azienda che deve comunque continuare a guadagnare mentre voi lavorate. Questa è una guida a quel modo: come capire cosa va davvero sistemato, come sostituire le parti dolorose senza mettere giù l'intero sistema, e come riconoscere quando una riscrittura completa è davvero la scelta giusta.

Perché la riscrittura totale è così allettante — e così pericolosa

La riscrittura completa è seducente perché promette una tela bianca. Niente più disordine legacy, niente più compromessi, una base di codice nuova costruita come si deve con strumenti moderni. Su una lavagna sembra ovvio. In realtà, vi state impegnando a ricostruire anni di logica di business accumulata — gran parte non documentata, una parte presente solo nella testa di persone ormai andate via — mentre l'orologio gira e arrivano le fatture.

La trappola più profonda è il problema dell'universo parallelo. Per i mesi o gli anni necessari a costruire il sostituto, avete due sistemi: il vecchio, che deve ancora mandare avanti l'azienda, e il nuovo, che non è ancora pronto. Ogni modifica di cui l'azienda ha bisogno va fatta due volte, oppure il nuovo sistema resta indietro rispetto alla realtà ancora prima di partire. I team si logorano tenendo in vita entrambi. E poiché a nessuno è permesso passare finché il nuovo sistema non fa tutto, non c'è alcuna vittoria anticipata, nessun feedback, nessuna prova che funzioni — solo una lunga, ansiosa attesa fino a un unico, enorme giorno di lancio tutto-o-niente.

C'è qui un noto detto del settore, ed è meritato: il secondo sistema, la grande riscrittura, tende a richiedere il triplo del tempo stimato e ad arrivare con meno funzionalità di ciò che sostituisce. La stima non è sbagliata per sbadataggine. È sbagliata perché all'inizio nessuno riesce a vedere tutte le piccole cose che il vecchio sistema fa bene senza dire niente.

Cosa significa davvero 'legacy' (non è questione di età)

Usiamo la parola legacy come se volesse dire semplicemente vecchio. Non è così. Moltissimo software in funzione da un decennio sta perfettamente bene — noioso, stabile, già pagato, fa il suo lavoro. L'età da sola non è una ragione per toccare alcunché. L'errore più costoso in tutto questo campo è modernizzare qualcosa che funzionava in silenzio solo perché sembrava datato.

Il software si guadagna l'etichetta legacy quando inizia a ostacolarvi attivamente. Quando non potete modificarlo in sicurezza perché nessuno lo capisce del tutto. Quando non riesce a collegarsi agli strumenti da cui oggi dipendete. Quando una sola persona è l'unica capace di tenerlo in vita. Quando è così lento o fragile che il vostro team ha costruito un intero folklore di trucchi attorno a esso. Questa è la vera definizione — non l'anno in cui è stato scritto, ma il costo che vi impone oggi e il rischio che porta verso domani.

Diagnosticare prima di toccare qualsiasi cosa

Prima che una sola riga venga riscritta, vi serve una mappa onesta di dove si annida davvero il dolore. Il più delle volte, il sistema che tutti odiano va bene per l'80%. I guai si concentrano in pochi punti precisi — una schermata lenta, un'integrazione rotta, un flusso che impone la doppia digitazione dei dati — e quei pochi punti generano quasi tutte le lamentele. Trovateli, e avrete trovato l'intero progetto.

Il modo per trovarli non è prima un audit tecnico — è una conversazione. Sedetevi con le persone che usano lo strumento ogni giorno e chiedete dove fa male. Dove aspettano? Cosa ridigitano? Cosa evitano perché è doloroso? Dove tengono un foglio di calcolo privato per aggirare il sistema ufficiale? Quei trucchi sono oro: ognuno è una radiografia precisa di un problema che vale la pena sistemare.

• Le schermate e i passaggi di cui le persone si lamentano di più — non in teoria, nel loro lavoro quotidiano reale.
• Ogni punto in cui i dati vengono digitati due volte perché due sistemi non si parlano.
• Le integrazioni che si sono rotte, o che non sono mai esistite, costringendo al copia-incolla manuale tra strumenti.
• Tutto ciò che solo una persona sa far funzionare o riparare — i vostri singoli punti di rottura.
• Le parti che vanno davvero bene, così da proteggerle e lasciarle stare.
• Ciò di cui l'azienda avrà bisogno l'anno prossimo e verso cui il sistema attuale semplicemente non può crescere.

Quando lo fate con onestà, il progetto di solito si rimpicciolisce. Il titolare entrato dicendo «sostituite tutto» esce rendendosi conto che deve sistemare tre cose. Non è una delusione — è un sollievo. Tre cose sistemabili sono un progetto che potete chiudere in questo trimestre. Una sostituzione completa è un anno a cui forse non sopravvivrete.

L'approccio strangler: sostituirlo un pezzo alla volta

Esiste un pattern per farlo in sicurezza, e ha un nome un po' cupo ma memorabile: l'approccio strangler, dal fico strangolatore — una pianta rampicante che cresce attorno a un albero e ne assume gradualmente la struttura finché, alla fine, la nuova crescita si regge da sola e il vecchio tronco è sparito. Applicata al software, l'idea è splendidamente pratica: non sostituite il vecchio sistema in un unico scambio eroico. Fate crescere il nuovo attorno a esso, un pezzo alla volta, finché del vecchio non resta nulla di cui qualcuno abbia bisogno.

In pratica funziona così. Scegliete un pezzo doloroso — diciamo il modulo di fatturazione che tutti odiano. Costruite un sostituto moderno per quel solo pezzo. Instradate la fatturazione al nuovo modulo mentre tutto il resto continua a girare sul vecchio sistema, intatto. Lo osservate per un po'. Quando è solido, quella parte del vecchio sistema si spegne e passate al pezzo successivo. Il vecchio sistema si rimpicciolisce gradualmente, come una candela, invece di essere abbattuto tutto in una volta.

Ciò che rende tutto questo molto più sicuro di una riscrittura è che ogni passo è piccolo, dal vivo e reversibile. Non procedete mai alla cieca. Ogni nuovo pezzo entra rapidamente in uso reale, così scoprite presto se funziona davvero. Se qualcosa va storto, avete rischiato solo un modulo, non l'intera azienda — e di solito potete tornare al vecchio percorso mentre lo sistemate. Raccogliete vittorie lungo la strada invece di un unico terrificante lancio alla fine. E l'azienda continua a funzionare, normalmente, per tutto il tempo.

Com'è davvero il ritmo

1. 1
   Scegliete il pezzo più doloroso e più autonomo

   Volete molto dolore e bordi netti — un modulo che fa molto male e che non ha le dita dappertutto. È il vostro primo bersaglio.
2. 2
   Mettete uno strato sottile davanti al vecchio sistema

   Un piccolo strato di instradamento decide quali richieste vanno al vecchio sistema e quali al nuovo pezzo. È la giuntura che rende possibile tutto il resto.
3. 3
   Costruite e lanciate solo quel singolo pezzo

   Sostituite un modulo, mettetelo in mani reali e instradate solo quella fetta di lavoro verso di esso. Settimane, non anni — e il resto del sistema non si è mai mosso.
4. 4
   Stabilizzate, poi passate al pezzo successivo

   Una volta che il nuovo modulo è affidabile, la parte corrispondente del vecchio sistema va in quiescenza. Ripetete con il pezzo doloroso successivo, imparando man mano.
5. 5
   Dismettete il vecchio sistema quando è vuoto

   Col tempo il sistema legacy non fa più nulla da cui qualcuno dipenda. Solo allora lo spegnete — in silenzio, senza drammi, perché tutto l'importante si è già spostato.

Notate cosa distingue questo dalla riscrittura: non c'è un unico giorno di lancio da temere. Non c'è un universo parallelo da mantenere. Il nuovo sistema è in produzione dalla terza settimana, si guadagna il pane e vi insegna delle cose, invece di aspettare in laboratorio un lancio che continua a slittare.

A volte non serve nemmeno sostituirlo

Prima di sostituire qualsiasi cosa, vale la pena chiedersi se il vecchio sistema vada sostituito o debba solo smettere di essere un'isola. Un numero sorprendente di problemi del tipo «ci serve un nuovo sistema» sono in realtà problemi del tipo «i nostri sistemi non si parlano». Il vecchio software fa bene il suo lavoro — sta solo in un silo, costringendo le persone a trasportare i dati a mano da una parte all'altra.

In quei casi, la soluzione più economica e rapida non è un nuovo sistema. È un ponte. Avvolgete il vecchio software con una connessione — un'integrazione che gli permette di scambiare dati automaticamente con i vostri altri strumenti — e uno strato moderno sopra per le parti che le persone toccano davvero. Il motore datato continua a ronzare sotto; il team ottiene una superficie pulita e la fine del copia-incolla. Non è affascinante, ma è spesso il massimo ritorno per euro di tutto lo sforzo.

Quando una riscrittura completa è davvero la scelta giusta

Ho passato l'intera guida a dissuadervi dalla grande riscrittura, quindi siamo onesti: a volte è davvero la risposta. Esistono fondamenta così marce che nessuna toppa, ponte o sostituzione pezzo per pezzo le salva, e fingere il contrario ritarda solo l'inevitabile mentre spendete denaro per puntellare un cadavere.

I segnali onesti sono precisi. La tecnologia su cui è costruito il sistema è morta o morente — niente supporto, niente aggiornamenti di sicurezza, nessuno rimasto in grado di lavorarci. L'azienda è cambiata così profondamente che il vecchio modello non corrisponde più affatto alla realtà. Oppure il sistema è così aggrovigliato che persino piccole modifiche rompono regolarmente cose in punti non correlati, il che di solito significa che non ci sono giunture pulite per applicare l'approccio strangler in primo luogo. Quando due o tre di queste cose sono vere insieme, il lavoro incrementale smette di essere la scelta più sicura.

Ed ecco la ricompensa silenziosa del fare prima il lavoro incrementale, anche se alla fine ricostruirete: quando ci arriverete, capirete il sistema molto meglio di quanto lo facevate all'inizio. Ogni modulo che avete sostituito vi ha insegnato qualcosa che gli autori originali non hanno mai messo per iscritto. Una riscrittura illuminata da quella conoscenza è un animale del tutto diverso, molto più sicuro, di quella lanciata sull'ottimismo del primo giorno.

La parte che nessuno menziona: riguarda soprattutto le persone

Ecco una cosa che le guide tecniche saltano. La parte più difficile del modernizzare un vecchio software di solito non è il codice — sono le persone che hanno passato anni ad adattarsi a esso. Ne conoscono le stranezze. Hanno memoria muscolare delle sue scorciatoie bizzarre. Un nuovo modulo oggettivamente migliore può comunque sembrare peggiore per le prime due settimane, semplicemente perché non è familiare. Se ignorate questo, persino una migrazione tecnica perfetta può fallire.

L'approccio incrementale aiuta anche qui, quasi per caso. Poiché il cambiamento arriva un piccolo pezzo alla volta, le persone lo assorbono gradualmente invece di doversi riapprendere tutto in un singolo lunedì mattina. Coinvolgete presto gli utenti quotidiani. Lasciate che plasmino il sostituto prima che sia finito. Il team che ha aiutato a progettare la nuova schermata di fatturazione la difenderà; il team a cui è stata calata addosso la rifiuterà, anche se identica. La modernizzazione è un progetto di gestione del cambiamento travestito da software.

Domande frequenti