Una nuova tecnologia può essere disponibile molto prima di diventare comune. Tra l'annuncio e l'adozione ci sono migrazioni, costi, verifiche e persone che devono imparare un modo diverso di lavorare.

Nel video mi concentro soprattutto sull'informatica: linguaggi di programmazione, nuove versioni e applicazioni già in uso. La domanda non è perché manchi l'innovazione, ma perché sostituire ciò che esiste richieda spesso molto tempo.

Migrare significa preservare un comportamento

Uso l'analogia della traduzione di un testo molto lungo. Aiuta a immaginare la quantità di lavoro, ma nel software c'è una difficoltà ulteriore: non basta tradurre le parole, bisogna mantenere i comportamenti necessari.

Un'applicazione può dipendere da librerie, formati, servizi e abitudini degli utenti. Cambiare un linguaggio o una versione può richiedere di controllare tutti questi collegamenti.

Una funzione deprecata, inoltre, non è necessariamente già rimossa. È un segnale da interpretare attraverso la documentazione e il percorso previsto dal progetto, senza confondere ogni avviso con un guasto immediato.

Il costo non coincide con la riscrittura del codice

Tempo di sviluppo, formazione, prove e gestione della transizione fanno parte dello stesso investimento. Nel frattempo, il sistema esistente potrebbe dover continuare a funzionare.

Un miglioramento tecnico può quindi essere interessante senza risultare prioritario in quel momento. È necessario confrontare benefici attesi, risorse disponibili e problemi che la migrazione dovrebbe risolvere.

Questo non significa che rimandare sia sempre prudente. Anche mantenere il vecchio sistema può avere costi crescenti, soprattutto quando dipendenze e competenze diventano difficili da reperire.

Vecchio non significa automaticamente inutilizzabile

Ricordo un avvertimento del mio professore di programmazione: entrando nel lavoro potremmo trovare tecnologie molto precedenti al nostro percorso di studi.

Nel video cito BASIC e Pascal con una generalizzazione eccessiva sul loro abbandono. Esistono strumenti e comunità che continuano a utilizzarne ed evolverne varianti: Free Pascal, per esempio, è un progetto attivo con supporto per Pascal e Object Pascal. Sito ufficiale Free Pascal.

Il criterio utile non è soltanto l'età del nome. Bisogna valutare manutenzione, compatibilità, competenze disponibili e adeguatezza al compito.

Ripartire da zero non elimina la complessità

Una riscrittura offre libertà progettuale, ma può far perdere comportamenti poco documentati che il sistema precedente aveva accumulato nel tempo.

Migrare gradualmente o ricostruire una parte del prodotto sono scelte da confrontare. Non esiste una regola secondo cui ripartire sia sempre più semplice o mantenere la logica precedente sia sempre necessario.

Prima di decidere, serve capire che cosa deve restare equivalente e che cosa si vuole cambiare. Altrimenti si rischia di confrontare progetti con obiettivi diversi.

Le persone devono poter svolgere ancora il loro lavoro

La domanda “perché cambiare qualcosa che funziona?” non esprime sempre chiusura mentale. Può segnalare un costo concreto: nuove procedure, scorciatoie da reimparare o funzioni spostate.

Formazione, documentazione e una transizione comprensibile possono ridurre questi ostacoli. Il fattore umano non è semplicemente un limite inevitabile: è una parte del progetto che si può affrontare.

Una tecnologia adottata senza preparazione può risultare meno utile di quanto prometta sulla carta.

Il mio esempio: il passaggio a Windows 11

Racconto la curiosità iniziale verso Windows 11 e la scelta di aspettare prima di usarlo. Al momento del video, alcuni aspetti mi convincevano meno rispetto a Windows 10.

È una testimonianza riferita a quella fase, non una valutazione aggiornata di ogni versione. Anche la mia fiducia in futuri miglioramenti era un'aspettativa, non la garanzia che ogni preferenza personale sarebbe stata accolta.

Il feedback può contribuire allo sviluppo, ma chi mantiene un prodotto deve scegliere priorità e compromessi. Raccogliere dati d'uso non prova, da solo, che una modifica sarà utile a tutti.

Quando una novità merita il passaggio

Per valutare un cambiamento, partirei da tre domande: quale problema risolve, quanto costa adottarlo e come verifichiamo che il risultato sia migliore per il nostro uso?

Non tutte le novità diventeranno standard. Alcune rimarranno specialistiche, altre saranno sostituite e altre ancora troveranno spazio gradualmente.

Il tempo di adozione racconta quindi più della semplice velocità di sviluppo: racconta quanto lavoro serve per inserire una tecnologia in processi, prodotti e abitudini reali.