Per quanto a chiunque piaccia avere a che fare con cose nuove ed originali, generalmente usiamo e continuiamo ad usare anche cose “vecchie”, di cui vorremmo disfarci prima o poi, ma che per qualche motivo non possiamo.
Naturalmente questo tipo di situazione si verifica anche nel mondo informatico e, nelle vesti delle “cose vecchie”, ritroviamo i sistemi legacy. Da Wikipedia:
Il sistema legacy (tradotto letteralmente “sistema eredità”) è un sistema informatico esistente o un’applicazione che continua ad essere usata poiché l’utente (tipicamente un’organizzazione) non vuole o non può rimpiazzarla.
Le ragioni che inducono a mantenere sistemi legacy sono soprattutto dovute ai costi sostenuti per la loro implementazione e ai costi da sostenere per la migrazione a nuovi sistemi. Molte persone usano questo termine per riferirsi a sistemi “antiquati” (ma spesso di gran lunga migliori di quelli di nuova concezione).
Con questo termine si indicano quindi i sistemi IT che utilizzano tecnologie meno recenti e per questo motivo sono molto difficili da interfacciare con i sistemi più recenti. Per tale interfacciamento si può ricorrere a sistemi middleware ma il costoso utilizzo di questi ultimi spesso decreta la sostituzione del legacy con tecnologie odierne.
Generalmente dei sistemi legacy si dicono peste e corna, spesso più per la foga di voler cambiare a tutti i costi qualcosa di ritenuto vecchio (e voler vendere un rimpiazzo) che non per una reale necessità.
Sistemi legacy e sviluppo
Da sviluppatore non sono immune al fascino dello speriementare costantemente cose nuove. Da sviluppatore con qualche anno di esperienza ho imparato a non disprezzare quel software che, seppur vecchio, ha contribuito a pagarmi lo stipendio.
Sviluppo è continuare a supportare i sistemi legacy, manutenerli (es: bugfix) ed eventualmente anche estenderli. Quando si inizia a lavorare presso qualcuno è normale doversi impratichire col codice già esistente ed è normale imbattersi in qualcosa che già presenta i segni del tipico sistema legacy oppure lo è già diventato. Non è solo una questione di questa o quella piattaforma, di questo o quel linguaggio di programmazione: prima o poi i componenti dei sistemi legacy, a loro volta legacy, escono di produzione, rendendo tutto più complicato.
C’è anche da dire che se una cosa funziona, non è necessario sostituirla. In altri casi è necessario farlo e sarebbe utile non aspettare l’ultimo momento, pena figur… situazioni spiacevoli come quella che accadde qualche anno fa in California (da Slashdot):
“Last week, California Governor Arnold Schwarzenegger ordered a pay cut, to minimum wage of $6.55/hr, for 200,000 state workers — because a state budget hadn’t been approved yet.
The state controller, who has opposed the pay cut on principle and legal grounds, now says the pay cut isn’t even feasible because the state’s payroll systems are so antiquated. He says it would take six months to go to minimum wage, and nine months more to restore salaries once a budget is passed.
The system is based on COBOL, according to the Sacramento Bee, and the state hasn’t yet found the funds or resources, in ten years of trying, to upgrade it.”
The article quotes a consultant on how hard it is to find COBOL programmers; he says you usually have to draw them out of retirement. Problem is, if there were any such folks on the employment rolls in California, Gov. Schwarzenegger fired them all last week, too.
Questo è un esempio di sistema legacy che, come spesso accade, probabilmente ha vissuto ben oltre quanto originariamente previsto (tutto ha una scadenza, anche se non è dichiarata esplicitamente), esattamente come per quei satelliti e sonde spaziali la cui durata di vita viene estesa arbitrariamente per ragioni di costi: finchè vanno, perchè non usarle?
Il problema è quando questo tipo di estensioni di vita arbitrarie toccano la vita delle persone.
Curioso che nel “fattaccio californiano” sopra-citato ritorni il solito problema-COBOL, un linguaggio di programmazione dato ingenuamente per morto troppe volte e troppe volte riemerso dal nulla. Una citazione tratta da Coding Horror dà un’idea di come i sistemi scritti in questo linguaggio tuttora siano importanti e rilevanti:
“The statistics that surround COBOL attest to its huge influence upon the business world.
There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world’s actively used code. There are estimated to be over a million COBOL programmers in the world today.
Most impressive perhaps, is that 200 times as many COBOL transactions take place each day than Google searches – a figure which puts the influence of Web 2.0 into stark perspective.“
Curioso anche che esso e molti sistemi costruiti con esso siano sopravvissuti ai loro programmatori originari, ormai in pensione da tempo e, in mancanza di nuove leve, riesumati a caro prezzo quando serve. Sempre dallo stesso articolo:
“Y2k was like a second gold rush for Cobol programmers who were seeing dwindling need for their skills. But six-and-a-half years later, there’s no savior in sight for this fading language.
At the same time, while there’s little curriculum coverage anymore at universities teaching computer science, “when you talk to practitioners, they’ll say there are applications in thousands of organizations that have to be maintained,” says Heikki Topi, chair of computer information services at Bentley College in Waltham, Mass., and a member of the education board for the Association for Computing Machinery.”
Sottostimare l’impatto di questi sistemi, anche come prospettiva di impiego è negare l’evidenza ed illudersi: non si tratta di qualcosa che morirà tanto presto. Si tratta di mercato di nicchia dal punto di vista professionale, ma non dal punto di vista della rilevanza industriale per cui saper trafficare con questi sistemi legacy, in certi casi, può risultare ben più redditizio di lavorare su cose nuove, moderne e che conoscono tutti.
Perfino per i neofiti della programmazione.
Esempio dall’esperienza
Durante la mia personale carriera professionale mi sono ritrovato a dover sviluppare e mantenere codice scritto in Visual Basic 5/6. Ho anche dovuto supportare ed estendere altro codice in quel linguaggio quando era già chiaro che Microsoft stava dedicandosi totalmente alla piattaforma .Net.
Nel mentre cercavamo un modo per “portare” il codice verso i più recenti VB.Net o C#, il codice legacy doveva continuare a funzionare: ossia dovevamo fornire supporto ed integrare tutte quelle funzionalità che non richiedessero qualcosa di troppo recente.
In alcuni casi aggiornare il programma equivaleva ad ammodernare la veste estetica: bastava cercare qualche libreria che fornisse un look moderno a certi widget (bottoni, listview, …) per togliere qualche anno all’applicazione di turno. Esattamente come fanno (o sostengono di fare) certe creme per la pelle.
Era chiaro tuttavia che, nonostante i trucchi estetici (doppio senso voluto), in poco tempo ci saremmo ritrovati nell’impossibilità pratica di continuare ad estendere quei programmi dal punto di vista delle feature mentre sviluppavamo i loro rimpiazzi. Tuttavia potevamo contare su un fatto, che spesso viene trascurato da molti programmatori: fornire software nuovo significa, nella maggior parte dei casi, imporre nuovi requisiti a livello di piattaforma per i clienti. Questo, a meno di dover presentare qualcosa in fretta e furia, permette di guadagnare tempo con i clienti, che normalmente si riservano un periodo sufficientemente lungo per decidere il da farsi.
Se la nuova versione di un software richiede un PC più potente per funzionare, visto che sfrutta questa o quella recente tecnologia, il cliente può tranquillamente non accettare questa imposizione. Non basta dire ad un cliente “funziona meglio!” per giustificare nuovi investimenti hardware e software: il cliente deve essere più che convinto della necessità non ulteriormente rimandabile di aggiornare qualcosa, altrimenti semplicemente non lo farà. Soprattutto se le presunte novità software servono a sostituirne dell’altro che, nonostante gli anni, continua a funzionare adeguatamente, per quello che serve al cliente.
 |
Perchè abbia successo il software nuovo deve fare almeno tutto quello che faceva quello vecchio, possibilmente nello stesso modo esatto, ed anche di più. Di certo è ben difficile che un cliente cambi qualcosa senza vantaggi tangibili e senza una qualche garanzia di retrocompatibilità col passato.
Quando dico “allo stesso modo”, intendo anche i bug! Ad esempio, parlando di Excel e di retrocompatibilità:
|
|
Se le cose andranno male, sentirete spesso il cliente lamentarsi con frasi come:
O anche:
Più questo genere di frase verrà ripetuta e più si farà strada nel cliente la volontà di ripristinare il vecchio sistema o programma. Finchè, stanco di ripetersi, lo farà davvero (o ci tenterà) e per giunta senza dirvi nulla! A buon intenditor… |
Ricordo discussioni con amici che, in piena epoca Windows XP SP2+, si trovavano ancora alle prese con programmi per Windows 95, perchè il cliente di turno non ne voleva sapere di aggiornamenti. Fra l’altro aggiornare può significare fermare qualcosa fino alla fine dell’intervento. E se quel qualcosa è un impianto che sforna prodotti 24 ore su 24, ininterrottamente? Quanto costa aggiornare per aggiornare?
Io stesso mi sono trovato a dover fornire consulenza per come far funzionare programmi vecchi, progettati addirittura per il DOS e funzionanti in Windows95 (la sopra-citata retrocompatibilità), su sistemi più moderni, basati su Windows2000/XP.
In quel caso il problema non era il vetusto codice a 16bit con cui quei programmi erano stati scritti, quanto le nuove restrizioni di accesso e di uso per le periferiche (seriali e parallele) che non consentivano più ai programmi di fare i propri comodi, incontrollati. Dal sito di uno dei produttori di driver che fornivano una soluzione al problema:
“A problem that plagues Windows NT/2000 and Windows XP, is it’s strict control over I/O ports. Unlike Windows 95 & 98, Windows NT/2000/XP will cause an exception (Privileged Instruction) if an attempt is made to access a port that you are not privileged to talk too.
Actually it’s not Windows NT that does this, but any 386 or higher processor running in protected mode.”
Il mondo legacy come ambito professionale
Il software ed i sistemi possono essere anche legacy, ma i programmatori di certo non lo sono. Trovo normale, ma anche assolutamente controproducente sul lungo periodo, che il mondo dello sviluppo software si concentri solamente sul software nuovo. O dia questa impressione.
Non vedrei male corsi, anche universitari, dedicati a questo mondo. A dire il vero non mancano libri sull argomento (come questo, che prima o poi recensirò), ma sono infinitamente pochi rispetto alla massa che propugna solamente il nuovo.
 |
Probabilmente scrivere nel proprio CV di essere degli “esperti nel trattare software legacy” non vi renderà più “trendy”. Però, per quanto mi riguarda, non lo considererei affatto come un demerito, semmai l’opposto: non tutti accettano di buon grado o sono portati ad aggiustare cose sviluppate da altri, magari anni or sono. |
|
Con rispetto a quanto detto nel mio post precedente e in quello originario di Nando Pappalardo, mi verrebbe di suggerire ai web designer/developer la possibilità di ritagliarsi una fetta di mercato nella manutenzione (o anche refactoring/redesign se serve) di siti “legacy”, creati da altri.
Non è facile da fare, anche per una questione di codice sorgente non sempre disponibile (anche legalmente), ma non sempre è davvero necessario rifare da zero un sito, perfino nel caso di progetti apparentemente disastrosi. Cioè, un professionista web, oltre a soluzioni “tutto-nuovo-di-zecca”, potrebbe proporne al cliente anche di meno radicali e costose, che magari riprendono il vecchio ma con come una serie di ritocchi qui e là per ammodernarlo. O perfino soluzioni di assistenza/manutenzione su qualcosa sviluppato da altri. Non è detto che sia sempre fattibile come cosa, ma è un’altra strategia su cui può valere la pena riflettere. Se è il caso e si può farci qualche soldo senza impazzire, perchè no? |
Che ne pensate?
Bravo, ottimo articolo.
Aggiungerei solo che, come per altre forme di manutenzione su cose vecchie, il problema che emerge sempre e’ la possibilita’ di fare preventivi anche minimamente approssimati.
E questo e’ sempre un grosso problema per il cliente , che non sa mai quanto andra’ a spendere, e per il programmatore che rischia di splafonare anche le sue piu’ nere previsioni e ritrovarsi a lavorare gratis e rimbrottato.
@Enzo: lieto che ti sia piaciuto.
Ciò che dici è vero, anche perchè, quando anche si può sparare al cliente una cifra alta a caso per il proprio lavoro, come si fa a stimare la spesa reale, inclusiva dell’aggiornamento degli eventuali componenti che nel frattempo – con tutta probabilità – sono usciti dal mercato?
Era quello a cui mi riferivo, indirettamente, con:
Ciao & grazie di essere passato! ^^
Concordo anche io, non si può ignorare l’esistenza dei sistemi legacy. Quando mi proposero di studiare Cobol e lavorare sui mainframe, io all’inizio non ero proprio contenta. Però studiandolo mi è piaciuto e ho ricevuto molte soddisfazioni lavorative e personali.
Poi per esigenze aziendali ho accettato di imparare altri linguaggi, e mi sono ritrovata a lavorare anche con altri ambienti legacy, ma anche acquisendo competenze nuove e “alla moda”.
Devo però dire che ad un colloquio di lavoro, il selezionatore guardò i “vecchi” linguaggi” come una macchia. Ad un certo punto si alzò e andò nella stanza accanto, dove lo sentii parlare con dei programmatori, ragazzi giovani, max 26 enni. Non si accorse che sentii tutto. I ragazzi gli chiesero che stava facendo, lui rispose “Un colloquio con una ragazza”. E che competenze ha? Nonostante sul mio cv ci fossero anche linguaggi considerati più “chic”, come java, o c sharp o l’allora esordiente visual basic .dot, notai che lui non tenne conto AFFATTO di questo. Rispose soltanto “Visual Basic 6 e Cobol”. I ragazzi risero a crepapelle “Cobol e Visual basic 6?. ahahahahaha”
Decisi in quel momento che, anche se mi avessero offerto un lavoro, mai e poi mai avrei accettato di avere colleghi così deficienti.
Per fortuna non se ne fece niente. Quando casualmente, gli stessi selezionatori mi richiesero il cv, trovandomi su un newsgroup dove c’erano offerte di lavoro e candidature, io mi meravigliai. Avevo pure specificato che conoscevo lo “scandaloso” cobol.
Gli risposi: non vedo perché mi ricontattate, visto che ho già fatto un colloquio da voi tempo fa e ho sentito alcuni ridere di queste competenze dalla stanza accanto, quindi non capisco perché ora vi andrebbero bene.
Si scusarono e non si sono più visti.
@Recenso: il bello è che sul lungo periodo poi anche quelli che ti hanno preso in giro poi probabilmente si ritroveranno a sapere qualcosa di “vecchio” e a passare per “matusa” che sanno linguaggi antichi. Lasciali ridere: ride bene chi ride ultimo…
Rimane la tua soddisfazione nel ricordare loro chi eri…
Ciao & grazie di essere passata! ^^
*** “Visual Basic 6 e Cobol”. I ragazzi risero a crepapelle “Cobol e Visual basic 6?.
e da quando in qua’ avere conoscenze in piu’ e’ un deficit ?
la chiusura mentale semmai e’ un grosso deficit, ed in quel caso non era certo un problema tuo.