Aggiornare i sistemi informatici è uno dei consigli più frequenti e sensati: se i sistemi evolvono, una buona ragione ci sarà, e il fatto che molti aggiornamenti riguardano questioni di sicurezza rende i sistemi obsoleti di per sé anche più vulnerabili. Insomma, continuare a usare un sistema vecchio è spesso la ricetta sicura per il disastro. Ma è sempre così? Oppure i pro e i contro coinvolti in queste circostanze gettano una luce importante sulla stessa natura dell’informatica?
Qualche tempo fa, mentre come di solito giungevo a Roma sulla linea Roma-Nettuno, ho notato che uno degli schermi presenti nelle carrozze per mostrare le informazioni di viaggio era invece fermo sulla schermata iniziale del sistema operativo: occasione propizia per gettare uno sguardo altrimenti impossibile su ciò che sta dietro le quinte di quel piccolo sistema informatico. La schermata era quella di Windows CE.net: dopo una breve ricerca, ho appurato che si trattava della versione 4 di quel sistema operativo, rilasciata nel 2002. Il supporto ufficiale è terminato nel caso migliore nel 2013, nel caso peggiore nel 2008. Un comportamento irresponsabile e deplorevole?
Software e sistemi della PA sono vecchi, vulnerabili: il problema
Innovare o non innovare, questo è il dilemma
La questione è in realtà più complessa, in questo come in tantissimi altri casi. L’esempio più noto è quello delle applicazioni bancarie, che in moltissimi casi usano ancora il linguaggio COBOL, che definire obsoleto è poco (e i programmatori COBOL sono ancora ricercati, seppure ovviamente in numero limitato, proprio per questa finalità). Il motto che gli americani ripetono in questi casi è: if it ain’t broke, don’t fix it! Se non è rotto, non aggiustarlo! Quando una cosa funziona, non è sensato metterci le mani per modificarla, o tanto più per partire da zero con una nuova. In questo modo infatti si ottengono solo più risultati negativi contemporaneamente: anzitutto, una cosa funzionante e abbondantemente testata è sostituita con un’altra che avrà i frequenti difetti di gioventù e necessiterà di un altro ciclo di prove e correzioni; l’esperienza accumulata, magari con anni di piccoli aggiustamenti, viene abbandonata e diventa praticamente inutile; gli utenti o i gestori che erano abituati al sistema precedente si ritrovano a dover imparare di nuovo qualcosa, combattendo contro la forza dell’abitudine che li spinge a seguire le vecchie procedure; last but not least, le forze che potrebbero essere impiegate in cose nuove e innovative vengono sprecate per riprogrammare per l’ennesima volta un sistema che fa la stessa identica cosa di prima.
Queste osservazioni sono estremamente sensate e fanno parte dell’esperienza comune di tutti gli utenti dell’informatica. Sono frequentissime le recensioni di nuove versioni in cui il giudizio finale è «un sistema perfettamente adeguato e funzionante è stato rovinato senza motivo». Spesso il giudizio negativo è appesantito dal fondato sospetto che dietro la presunta innovazione vi sia solo un adolescenziale desiderio di cose nuove o la voglia di essere gli autori di qualcosa di diverso (ciò che sovente pare vedersi nel mondo del software libero, per esempio), oppure una deliberata strategia commerciale di obsolescenza programmata: il sistema nuovo fa vedere il precedente come vecchio e induce (o addirittura costringe) a sostituirlo, pur quando i vantaggi sono in realtà nulli. Nessuna meraviglia che dinosauri viventi si trovino spesso dietro le quinte, dove l’interesse maggiore è che qualcosa funzioni bene, e dove non vi sono ragionevoli spinte a modificarlo. Oppure negli strumenti di base che, malgrado le pur reali innovazioni, continuano largamente ad essere reputati insostituibili (un esempio fra tutti: il linguaggio C, che tra poco festeggerà i 50 anni di vita ed è ancora presentissimo in ogni computer e ancora continuamente usato per scrivere cose nuove).
Oltre a questi motivi umani e pratici esistono tuttavia almeno altri due motivi più teorici (e forse più importanti) che dovrebbero sconsigliare dalla ricerca di una pseudo-innovazione.
Il carattere “sociale” di ogni progetto informatico
Il primo è il carattere inevitabilmente sociale di ogni progetto informatico. La complessità raggiunta dal sistema anche apparentemente più semplice è ottenuta solo tramite una delicata composizione e stratificazione di elementi che provengono da mani diverse. Cambiare in blocco un intero sistema è un conto: ma quando viene alterato un anello di una catena più ampia, sono tutti quelli collegati a soffrirne (per esempio, plugin che smettono di funzionare, oppure ottimi programmi che diventano inutilizzabili in una nuova versione del sistema operativo). Ogni impresa comune si basa sul rispetto di norme concordate e sull’aspettativa che gli altri attori continueranno ad agire nella maniera conosciuta e prevedibile.
L’aggiornamento dei programmi
Il secondo è l’importanza di rivendicare il carattere eminentemente astratto, logico, delle procedure informatiche. Quando venne introdotta l’espressione «ingegneria informatica» (per la cronaca: ad opera di Margaret Hamilton, la programmatrice che mandò l’Apollo 11 sulla Luna), essa venne accolta da molti come un’assurdità: i programmi non sono macchine bisognose di manutenzione, da aggiustare e tenere sotto controllo, anche se ovviamente funzionano su macchine siffatte. L’espressione «ingegneria informatica» si è poi conquistata un suo significato perfettamente accettabile (nel sistema accademico italiano è anche un «settore scientifico-disciplinare», una delle grandi suddivisioni in cui sono raggruppati docenti e insegnamenti), ma le proteste contro il suo uso mantengono il loro senso: i programmi informatici sono la codificazione di procedure astratte. L’aggiornamento o manutenzione di un programma ben definito e perfettamente funzionante dovrebbe suonare assurdo come l’aggiornamento o manutenzione del teorema di Pitagora.
Netscape e la guerra dei browser: quale lezione?
Fine del discorso? In realtà no, come in tutte le faccende umane vi sono pro e contro. Nel 2000 Joel Spolsky (uno dei protagonisti dell’informatica degli ultimi decenni) scrisse un celebre articolo per ridicolizzare la scelta di Netscape (per i più giovani: l’antenato di Mozilla/Firefox) di riscrivere da zero il proprio browser: «il peggior errore strategico che una compagnia di software possa mai fare». I motivi? Esattamente quelli che abbiamo detto, solo espressi in maniera più colorata: «Il vecchio codice mica arrugginisce: il vecchio codice diventa migliore perché via via vengono eliminati i bug». Joel Spolsky certamente aveva ragione nel notare il carattere suicidario di questa decisione per esempio dal punto di vista commerciale: l’uso di Netscape, ora infestato da bug (e anche da altri decisivi difetti) crollò a favore di Internet Explorer, che vinse in quegli anni a man bassa la celebre «guerra dei browser».
Ma la storia successiva non dimostra tuttavia che questa strana decisione permise anche un nuovo inizio, che in pochi anni condusse ad un nuovo browser perfettamente funzionante e per molti aspetti innovativo? È verissimo che il codice non arrugginisce, ma è anche vero che ripartire da zero significa vedere le cose con occhi nuovi e liberarsi dal peso del pregresso (la tanto celebrata ma spesso paralizzante backwards compatibility). Significa cercare non solo ciò che «funziona», ma ciò che esprime una procedura con chiarezza, concisione e perfino bellezza. Significa cercare strade nuove. Uno dei grandi avversari dell’idea dell’informatica come ingegneria, l’informatico olandese Edsger Dijkstra, fu anche colui che con un celebre articoletto pubblicato nel 1968 (Goto Statement Considered Harmful) indusse innumerevoli programmatori a gettare al secchio centinaia di migliaia di righe di codice per reiniziare daccapo in maniera più pulita, logica, controllabile. Se il codice non arrugginisce, tuttavia le cose possono essere pensate sempre meglio. Questa è una delle sfide intellettuali più belle dell’informatica.
E allora forse il celebre detto americano andrebbe completato: se non è rotto, non aggiustarlo – ma cerca sempre strade migliori.
