Notizia
Riscrivere da zero fallisce quasi sempre, avverte Simon Willison
Secondo Willison la strategia della riscrittura crea incentivi per peggiorare il debito tecnico e genera nuovi progetti incapaci di riprodurre il comportamento reale del sistema [S1].
Riscrivere da zero fallisce quasi sempre, avverte Simon Willison
«È così raro che funzioni». Simon Willison stronca l’idea di buttare giù tutto e ricominciare. Lo fa in un post del 6 settembre 2026, scritto in risposta a chi proponeva una riscrittura totale per uscire dal debito tecnico [S1].
Prima scena: qualcuno dichiara l’attuale sistema irrecuperabile. Nasce un team dedicato alla riscrittura. Parte il lavoro, lontano dalla produzione [S1].
Nel frattempo il software in esercizio sostiene il core business. Cambia ogni settimana. Servono nuove funzionalità, fix, integrazioni. Chi lo mantiene sa che il progetto nuovo lo sostituirà. Quindi investe il minimo necessario. Così cresce il debito tecnico [S1].
Sull’altro fronte, la ripartenza entusiasma. Greenfield, ambizione alta, pochi vincoli. L’energia iniziale nasconde il problema centrale: nessuno possiede una mappa affidabile del comportamento reale da sostituire. Willison osserva che, se la piattaforma fosse ben documentata e coperta da test solidi, non servirebbe rimpiazzarla [S1].
Passano i mesi. A volte gli anni. In produzione non arriva valore. La pressione a “spedirlo” aumenta. Arriva la scelta tipica: lanciare una versione che copre solo un sottoinsieme del perimetro precedente. Il resto rimane fuori, con promesse di completamento che slittano [S1].
Schema noto, esito frequente. La linea di produzione si deteriora perché riceve solo interventi minimi per tenere il passo. La riscrittura corre finché evita gli angoli bui del comportamento storico. Poi rallenta quando serve replicare casi limite, differenze sottili, convenzioni non scritte. Documentazione scarsa e test incompleti non aiutano: se coprissero la realtà, quella realtà non chiederebbe una riscrittura [S1].
Risultato: due fronti che perdono. Il sistema vivo accumula debito tecnico. Il progetto nuovo fatica a centrare ambito e comportamento. Dopo un lungo periodo senza consegne utili, arriva un go-live forzato di una soluzione parziale. L’organizzazione paga doppio: mesi o anni senza miglioramenti e un sostituto che non regge tutto ciò che c’era prima [S1].
Willison non elenca eccezioni né ricette miracolose. Parla per esperienza diretta: «È così raro che funzioni». La causa, dice, sta negli incentivi. Chi mantiene il vecchio lavora al minimo, perché sa che morirà. Chi costruisce il nuovo scopre tardi di non conoscere il terreno [S1].
Da qui una conseguenza pratica implicita nel suo ragionamento: investire prima in documentazione e test riduce la tentazione — e il rischio — della riscrittura totale. Se comprendiamo davvero ciò che il sistema fa oggi, ricominciare da zero diventa meno attraente. E, soprattutto, meno necessario [S1].