Per un progetto recente mi è toccato riaprire un vecchio sito costruito anni fa con Jekyll. Appena ho visto il codice, mi sono messo le mani nei capelli: dipendenze fossilizzate, plugin dimenticati e un workflow che oggi sembrava provenire da un’altra epoca.
Da lì è nata una riflessione che va oltre la singola esperienza: cosa succede quando il tempo passa anche per il software? E cosa significa, oggi — nell’era dell’intelligenza artificiale e dei tool che cambiano ogni sei mesi — ritrovarsi a lavorare su un pezzo di storia tecnologica che non ti segue più?
Per chi non vive ogni giorno nel codice: un software non è un blocco unico, ma un insieme di componenti che lavorano insieme — framework, librerie, plugin, dipendenze. Ciascuno di questi elementi evolve nel tempo, riceve aggiornamenti, correzioni, nuove versioni. Quando uno di questi pezzi resta fermo, o smette di essere compatibile con gli altri, l’intero sistema inizia a scricchiolare. È un po’ come cercare di far funzionare un’app moderna su uno smartphone di dieci anni fa.
Il costo dell’obsolescenza
Nel software, il tempo ha un altro ritmo. Sei mesi possono bastare perché un progetto perda la sua freschezza, un anno perché diventi difficile da toccare, cinque anni perché sembri scritto in un’altra lingua.
Rimettere mano a un vecchio progetto è come aprire una capsula del tempo: scopri librerie scomparse, pattern che oggi sembrano goffi e strumenti che non si usano più. Non è solo nostalgia, è la prova concreta di quanto la tecnologia corra — e di quanto restare fermi significhi, in realtà, tornare indietro.
Mi è successo proprio con quel progetto: un vecchio sito sviluppato con Jekyll, un generatore di siti statici che, qualche anno fa, era una scelta popolare per molti web developer. Il problema? Oggi il panorama è completamente cambiato. In un mondo in cui soluzioni come Next.js dominano la scena, rimettere mano a un progetto Jekyll non è stato solo un viaggio nel tempo, ma la prova concreta di quanto la tecnologia possa diventare un freno se non viene aggiornata.
1. Dipendenze tossiche, archeologia del codice
Prima di tutto, un po’ di contesto: dopo aver completato il progetto, anni fa avevamo consegnato il pacchetto al cliente, che da allora lo gestiva in autonomia.
La codebase però, da quel momento, non era stata più aggiornata nelle sue dipendenze e librerie. Probabilmente perché, essendo un generatore di pagine statiche, Jekyll presentava rischi di sicurezza limitati e non richiedeva particolari manutenzioni.
Il problema è che questa “pace apparente” ha un costo nascosto. Quando siamo stati richiamati per un progetto di restyling mantenendo la stessa codebase, la developer experience si è trasformata in un piccolo, grande incubo.
La prima sfida è stata semplicemente riuscire a far funzionare di nuovo il progetto sul mio computer. Versioni di Ruby incompatibili, dipendenze ormai deprecate e plugin non più mantenuti hanno reso ogni passaggio un piccolo rompicapo. La documentazione ufficiale era superata, e trovare soluzioni aggiornate è diventato un vero lavoro di archeologia digitale.
Ma il vero ostacolo non erano solo le librerie obsolete, bensì il codice stesso: mancava una tipizzazione, cioè un sistema che ti aiuta a definire in anticipo che tipo di dati può contenere una variabile e come vengono usati nel progetto. Senza questa guida, orientarsi nel codice era complicato: nessuna struttura chiara, nessuna mappa dei dati. Lavorare su un progetto così è come leggere un libro con metà delle pagine strappate — puoi intuire la trama, ma il rischio di sbagliare è altissimo.
Con uno stack moderno, come Next.js e TypeScript, sarebbe stata tutta un’altra storia. Next.js è un framework JavaScript pensato per costruire siti e applicazioni web in modo veloce e flessibile, con strumenti che semplificano lo sviluppo e migliorano le prestazioni. TypeScript, invece, è un linguaggio che aggiunge la tipizzazione a JavaScript: in pratica, ti permette di definire chiaramente che tipo di dati stai usando e di intercettare molti errori ancora prima di eseguire il codice.
Senza una tipizzazione robusta, ogni modifica diventa un salto nel buio: il debug si trasforma in una caccia al tesoro e anche i bug più banali finiscono per far perdere ore. Ecco perché oggi usiamo TypeScript per la maggior parte dei nostri progetti — non solo per scrivere codice più sicuro, ma per lavorare con maggiore serenità.
Per approfondire: Perché usare uno static type checker nello sviluppo di app JavaScript.
2. Workflow a passo di lumaca
La richiesta del cliente era semplice: aggiornare alcuni contenuti e aggiungere nuove sezioni. In teoria, niente di complicato. In pratica? Un inferno.
Ogni piccola modifica con Jekyll richiedeva la ricostruzione completa del sito. Niente hot reload, niente aggiornamenti in tempo reale, niente anteprime dinamiche come avrei avuto con Next.js e Sanity, strumenti che permettono di vedere subito cosa stai cambiando mentre lavori. Il risultato? Ogni operazione era più lenta del previsto — e il fatto che fossero anni che non toccavo più Jekyll e il suo templating in Liquid non aiutava.
Anche qui la mancanza di una tipizzazione chiara si è fatta sentire. In un sistema moderno, TypeScript mi avrebbe mostrato a colpo d’occhio quali dati erano disponibili, che tipo avevano e dove c’erano errori, ancora prima di lanciare il codice. Con Jekyll, invece, l’unico modo per scoprirlo era... provarci, sbagliare, correggere e ripetere. Decisamente non il workflow ideale.
A un certo punto, mi sono reso conto che stavo combattendo con il tool stesso, invece che concentrarmi su ciò che davvero dovevo fare.
3. Software d’epoca, problemi moderni
La mia impressione è che Jekyll, costruito su Ruby, resti uno strumento solido e ben progettato, ma oggi non sia più al centro del panorama web. Non perché non funzioni — anzi, fa ancora bene ciò per cui è nato — ma perché il modo di costruire e mantenere i siti è cambiato. Oggi molti nuovi progetti nascono su framework moderni come Next.js o Astro, che offrono flussi di lavoro più rapidi, un’esperienza di sviluppo più fluida e un ecosistema molto più vasto.
Questo rende l’esperienza con Jekyll un po’ più faticosa: meno sviluppatori che lo usano, meno risorse aggiornate e qualche difficoltà in più nel trovare soluzioni immediate ai problemi. Me ne sono accorto quando ho provato ad aggiungere un semplice video YouTube e ho scoperto che il plugin disponibile non veniva aggiornato da anni. Niente di grave, ma sufficiente a ricordarmi quanto sia rischioso lavorare con dipendenze che appartengono a un’altra epoca.
Non è solo un tema tecnico, ma anche umano: quando il software invecchia, richiede più tempo, più attenzione e più pazienza. E alla lunga, è proprio la pazienza di chi ci lavora sopra a diventare la risorsa più fragile.
Alla ricerca del tempo (e del budget) perduto
Tutto questo si traduce in più tempo perso e più costi. Per una semplice modifica ci ho messo ore, ore che avrei potuto investire in qualcosa di più utile se avessi lavorato con tecnologie moderne.
E poi c’è la manutenzione. Quando lavori su un progetto obsoleto, non è solo questione di scrivere codice: passi più tempo a capire come farlo funzionare senza che tutto si rompa. È come cercare di riparare un’auto d’epoca senza avere i pezzi di ricambio giusti. Ogni piccolo problema diventa una battaglia, e ogni soluzione richiede più tempo di quanto dovrebbe.
E se tutto questo non bastasse, c’è anche il tema della sicurezza. Spesso non ci si rende conto di quanto anche software apparentemente semplici — come quelli che generano siti web statici — dipendano da librerie e pacchetti esterni. Se queste dipendenze non vengono aggiornate, col tempo possono diventare una fonte di vulnerabilità o di malfunzionamenti inattesi.
E vale un po’ per tutto, anche per i framework più moderni come Next.js: ogni ecosistema vive e si evolve, e mantenere il passo richiede attenzione costante.
Alla fine, il vero costo di restare indietro non è solo tecnico, ma anche economico e mentale. Per il cliente, significa spendere di più per ottenere di meno. Per chi ci lavora sopra, significa perdere tempo su problemi evitabili e accumulare frustrazione.
Ecco perché non mantenere aggiornato un progetto nel tempo non è mai una buona idea. Prima o poi il passato tecnologico ti presenta il conto. E, di solito, non è mai un conto leggero.
Developer Experience = Business Value
Lavorare con strumenti moderni non è solo una comodità per i developer: è una scelta strategica che incide direttamente sulla qualità del prodotto e sui risultati di business. Un software aggiornato è più semplice da sviluppare, più stabile da mantenere e più sicuro nel tempo. Meno bug, meno interventi d’emergenza, meno costi imprevisti.
Anche l’esperienza utente ne beneficia. Un’infrastruttura moderna consente di migliorare il prodotto in modo rapido e continuo, adattandolo alle esigenze reali. Se invece ogni modifica richiede giorni di lavoro perché il codice è fragile, il rischio è di restare fermi mentre il mercato si muove.
C’è infine un tema di attrattività. Oggi chi lavora nel digital riconosce subito la differenza tra un prodotto curato e uno trascurato. E questo vale per tutti: per i clienti, ma anche per i developer. Nessuno vuole lavorare con uno stack obsoleto che rallenta ogni passo e rende ogni aggiornamento un piccolo incubo.
Legacy vs Replatforming: quando ha senso
Ripartire da zero o mantenere un software legacy? È una domanda che molte aziende si pongono di fronte a un sistema datato. La tentazione di lasciarlo com’è, “perché funziona ancora”, è forte. Ma funzionare non significa essere efficiente.
Un software che invecchia diventa presto un freno: ogni nuova funzionalità è più difficile da integrare, ogni bug richiede più tempo e ogni modifica porta con sé nuovi rischi. Intanto, la tecnologia continua ad avanzare.
La soluzione, però, non è quasi mai riscrivere tutto da zero. Meglio modernizzare in modo progressivo, partendo dalle aree che mostrano già criticità. Aggiornare gradualmente lo stack o sostituire moduli obsoleti permette di evolvere senza bloccare le attività.
In quest’ottica, aggiornare non è solo un costo ma un investimento: ritarda l’obsolescenza, riduce i rischi e mantiene il software allineato alle esigenze di business. Perché aspettare che qualcosa si rompa, di solito, è la strategia più costosa di tutte.
Il futuro è oggi
Ogni riga di codice che scriviamo oggi sarà legacy domani. È inevitabile. Ma questo non significa inseguire ogni nuovo trend o riscrivere tutto da zero ogni due anni. La chiave è un mindset orientato alla manutenibilità: progettare pensando all’evoluzione continua, con tecnologie flessibili e scalabili nel tempo.
Rimandare gli aggiornamenti può sembrare comodo nel breve periodo, ma è un’illusione. Più il tempo passa, più il codice diventa rigido e costoso da mantenere. E quando arriva il momento di intervenire, il conto è sempre più salato.
Oggi, poi, il punto non è solo mantenere il software aggiornato, ma sfruttare le nuove opportunità. L’intelligenza artificiale sta cambiando il modo in cui sviluppiamo, testiamo e ottimizziamo: non sostituisce i developer, ma ne amplifica le capacità. Strumenti come Cursor, GitHub Copilot o i sistemi di refactoring assistito non scrivono codice al posto nostro, ma ci liberano dal peso della manutenzione per concentrarci sulle decisioni che contano davvero.
Aggiornare il proprio stack tecnologico, quindi, non significa solo adottare versioni più recenti, ma ripensare il modo stesso in cui costruiamo software: più scalabile, più sicuro, più sostenibile.
Se c’è una cosa che ho imparato riaprendo quel vecchio progetto, è che aggiornare oggi significa risparmiare domani. Non si tratta solo di evitare problemi tecnici, ma di mantenere il passo con il futuro — prima che sia il passato tecnologico, ancora una volta, a presentarci il conto.
Per approfondire: L’AI è il futuro dello sviluppo, ma non come immaginavo.
