Spesso le aziende che utilizzando applicazioni legacy, sviluppate ormai una quindicina di anni fa, hanno sempre più problemi a trovare sviluppatori che consentano loro di rilasciare aggiornamenti al passo coi tempi. Sempre più spesso mi ritrovo di fronte al problema di aggiungere ad un'applicazione il supporto per l'accesso a servizi sul web, dove si ravvede la necessità di implementare qualche meccanismo di comunicazione. Le scelte spesso ricadono su protocolli di consuetudine, come HTTP, FTP, WebDav o SOAP.

Inoltre quasi tutti gli ambienti di sviluppo datati non offrono una serie di automazioni e di strumenti di produttività, per garantire uno sviluppo ed un mantenimento del proprio codice a costi accettabili. I framework dell'epoca sono molto limitati come quantità e qualità delle funzionalità offerte e ci ritrova a "reinventare la ruota".

', '

I motivi principali di ostacolo possono essere individuati nei seguenti punti:

1. il compilatore non consente di passare da 32 a 64 bit: i sistemi operativi ancora non pongono limiti così stringenti, tali da non far girare più processi a 64 bit nel sistema operativo nativo, anziché in una black box a 32 bit, come in macchina virtuale o ambiente di emulazione;
2. la gestione della memoria di linguaggi non è efficiente: la gestione della memoria in ambienti obsoleti come Visual Basic (VB4 a 16 bit, VB5 o VB6 a 32 bit) non è efficace come con i garbage collector presenti in Java, .NET Framework o Objective-C;
3. non scalabilità di tecnologie come COM: la tecnologia COM ha rivelato tutti i suoi limiti quando il numero di oggetti instanziati in memoria supera certe soglie, tali da rendere non scalabili i problemi oltre certe dimensioni. Per poter gestire problemi più grandi, è necessario ricorrere alla revisione progettuale abbandonando totalmente o parzialmente l'implementazione COM;
4. supporto nativo di multithreading inesistente: spesso l'implementazione del multithreading è possibile solo ricorrendo alle API del sistema operativo, poiché non sono disponibili nel framework di sviluppo, con conseguente impennata della curva di apprendimento, che si ripercuote sui tempi di sviluppo;
5. limitata disponibilità di framework per servizi distribuiti: la possibilità di sviluppare servizi basati su componenti distribuiti è molto limitata per l'obsolescenza dei componenti, pertanto è difficoltoso servizio di invio mail, di servizi SOAP, di librerie FTP/HTTP su cui costruire implementazioni ad alto livello per comunicazioni;
6. i controlli delle interfacce grafiche segnano il passo: le interfacce grafiche delle nuove applicazioni abbandonano sempre più il look-and-feel di questo o quel sistema operativo, facendo invece posto ad una grafica che è invariante nelle distribuzioni per i diversi dispositivi;
7. l'apparenza grafica ricorre ad effetti accattivanti: sempre più si vedono nelle applicazioni mobili e non l'uso massiccio di effetti di transizione, rotazioni, animazioni tridimensionali, che hanno il solo scopo di aumentare la fruibilità dell'applicazione, ma in realtà giustificano tempi di attesa per elaborazioni o latenze imposte da comunicazioni sulla rete, tradendo così l'utilizzatore finale.

Per tutte queste problematiche è necessario rivolgersi sempre ad un team di sviluppo, che abbia le capacità tecniche di prendere in mano un progetto più o meno grande e che gli sappia intraprendere un cammino di evoluzione, senza per questo stravolgere il regolare funzionamento o mettere sottosopra il lavoro degli sviluppatori della parte legacy, che invece non necessitano di aggiornamenti particolari.