Mobilità degli insegnanti ovvero l’informatica senza morale

Una notiziola circolata in questi giorni, ancorché parziale e provvisoria, offre l’opportunità di fare qualche importante riflessione sull’evoluzione informatica dell’amministrazione pubblica da una parte, sulla computer ethics dall’altra.

Anzitutto i fatti. La legge 107/2015 dà disposizioni sulla mobilità degli insegnanti, i relativi criteri vengono stabiliti dal Contratto Collettivo Nazionale Integrativo dell’8 aprile 2016. Il MIUR commissiona il programma informatico che deve gestire l’intera operazione, tramite il quale vengono decisi i trasferimenti per l’anno scolastico 2015-16. Al momento della pubblicazione dei provvedimenti di mobilità, si sollevano moltissime proteste: circa 7000 ricorsi, di cui 2000 terminati con una conciliazione. La Gilda degli insegnanti chiede al Ministero di poter visionare il software, che viene trasmesso a quattro periti, i quali firmano il 4 giugno una «Perizia tecnica preliminare». È così chiaro il motivo della cautela che abbiamo espresso fin dalle prime parole: ciò che in questo momento possiamo commentare è solo una perizia di parte, per di più provvisoria. Un audiatur et altera pars è quindi d’obbligo.

Tenendo presenti questi limiti, che cosa ci racconta questa perizia? I dati fondamentali sono, ci sembra, due. Il primo è che i periti si sono trovati di fronte a quella che, dalle loro parole, appare una galleria degli orrori. Il programma assembla due parti diverse. Una, fluviale (quasi 30mila righe), è scritta in COBOL, un linguaggio di programmazione caduto in disuso (per ottimi motivi) almeno da una trentina d’anni, eccettuati usi speciali per i quali devono essere riutilizzate librerie di codice preesistente; la riga che documenta per quale computer è generato il codice indica l’IBM/370 (un sistema annunciato nel 1970!). Lo stile di scrittura è comunque caotico e incomprensibile (i periti hanno addirittura il dubbio che sia intenzionalmente «offuscato»). L’altra parte è in C: un linguaggio invece ancor oggi usatissimo ma, come velatamente viene suggerito, poco adatto anch’esso, avendo tra i suoi meriti un’efficienza in questo caso inutile e tra i suoi demeriti una pericolosa attitudine a nascondere errori difficili da scovare: l’ultima cosa che si può rischiare in un codice dalla cui correttezza dipende il destino lavorativo di migliaia di persone. Nell’una e nell’altra parte la documentazione è pressoché inesistente. Il secondo dato è che il codice è stato fornito in un modo che ne impedisce qualsiasi verifica: forse incompleto, sicuramente mancante delle specifiche delle basi di dati sulle quali opera, infine (se ben capiamo) disponibile solo sotto forma di listati in formato PDF protetto. C’è infine un dato che non è citato dalla perizia ma risulta dai pezzi giornalistici che hanno riferito la vicenda: il programma in questione sarebbe costato al MIUR circa 440mila euro: grosso modo quanto sarebbero pagati al netto 80 anni di lavoro a tempo pieno di un bravo programmatore (non consideriamo neppure i costi del software e delle macchine necessari allo sviluppo, perché trascurabili o addirittura nulli).

In attesa di controdeduzioni del MIUR, ipotizziamo che tutto ciò sia vero. Viene voglia di classificare la vicenda come uno degli innumeri esempi di sperpero del denaro pubblico per opere mal realizzate. Eppure, anche se se ne avrebbe ben donde, bisogna resistere alla tentazione, perché la vicenda solleva alcuni problemi nuovi e difficili, in cui la politica si incrocia con la computer ethics. Cerchiamo di discuterli brevemente.

Partiamo dalla fine. Per chi non conosce un po’ da vicino gli strumenti informatici attuali è facile pensare che alcune cose siano «difficili» o richiedano strumenti eccezionali, e i programmi che li gestiscono una specie di miracolo che merita di essere pagato cifre enormi. Ovviamente questo non è vero. La perizia ripete per ben quattro volte che le operazioni richieste nel caso in questione sono assolutamente «semplici» (come conferma la lettura delle norme che il programma doveva seguire), qui aggiungiamo che la quantità di dati da gestire è risibile per un qualsiasi sistema moderno. Per fare un esempio, SQLite, il piccolo motore di database relazionale aperto e gratuito utilizzato da innumerevoli programmi ogni volta che c’è la necessità di gestire una certa quantità di dati (per esempio i segnalibri), è tranquillamente in grado di operare su milioni di record, e la capacità di un odierno smartphone è di diversi ordini di grandezza superiore a quella dell’IBM/370 che risulta essere il target di compilazione della prima parte del software utilizzato dal Ministero. Conclusione? Una conoscenza minimamente circostanziata degli strumenti informatici attuali non è oggi un optional nei gestori della cosa pubblica, ma una necessità. Non possiamo permetterci il lusso di subire errori paragonabili a quelli di un «padre di famiglia» (come si usa dire in diritto) che pagasse tranquillamente 100mila euro un rifacimento in moquette del bagno di servizio di casa.

Ma la vicenda mostra anche che non è più accettabile che gli strumenti informatici che gestiscono aspetti della vita e della professione delle persone non siano immediatamente pubblici e controllabili tanto quanto la normativa che essi debbono rendere operativa. Il problema che i periti con malcelata irritazione hanno evidenziato, e cioè il fatto che ciò che è stato fornito loro impedisce qualsiasi test, è insomma solo una parte di una questione più fondamentale. Nella storia della civiltà la scrittura delle leggi e la loro pubblicità hanno svolto un ruolo centrale nell’affermazione del diritto. Una parte paragonabile deve oggi essere svolta dalla completa pubblicità delle procedure informatiche seguite. Credo che possa essere anche sostenuto che esse, analogamente al testo delle leggi, non possano venire coperte da nessun copyright.

Il problema tuttavia non finisce qui. Una lettura rapida della perizia potrebbe far pensare che, una volta che il MIUR fornisse i programmi completi e le specifiche delle basi di dati, sarebbe finalmente possibile «controllare» se il programma è privo di errori. Purtroppo le cose non stanno così: anche in tal caso sarebbe impossibile. Secondo una massima spesso ripetuta, qualsiasi prova può sì mostrare la presenza di errori in un programma, ma non la sua assenza! Il motivo: anche il più semplice codice informatico è scritto per risolvere una classe generale di calcoli, per la quale è praticamente impossibile provare tutti i possibili casi.

Non c’è nulla che esclude a priori quindi che in qualche caso limite, o con una combinazione imprevista di dati, il risultato fornito sia errato. (Si noterà quanto questo ragionamento sia analogo al principio di falsificazione di Popper, una delle pietre miliari della filosofia della scienza contemporanea.) Che cosa significa questo? Significa che di un programma si può affermare la correttezza non «provandolo», ma solo dimostrando che esso realizza il calcolo desiderato. Ma questa operazione è fattibile solo se il programma è scritto nella maniera più semplice possibile e in maniera strutturata. Era questo il principio che, a metà strada tra la computer ethics e la riflessione matematica teorica, Edsger Dijkstra esprimeva sotto il titolo the humble programmer: la testa umana è sempre piccola in confronto a grandi programmi, che possono quindi essere ritenuti affidabili solo se ricondotti alla dimensione della prima. Una brutta notizia quindi per i docenti coinvolti nella mobilità (o forse per il MIUR): non si potrà mai dimostrare che quelle 30mila righe di COBOL e quelle 3500 righe di C siano corrette (tanto più che soprattutto il COBOL ha una forte propensione ad accogliere uno spaghetti code impossibile da districare). Morale? Uno stile di programmazione semplicissimo e strutturato è un’esigenza non solo tecnica, ma anche etica e politica. In una vita pubblica sempre più complessa e controllata da sistemi informatici non possiamo permetterci di sospettare che sepolti in decine di migliaia di righe incomprensibili vi siano non solo errori, ma addirittura truffe o sabotaggi.

In tutto questo c’è però anche un’opportunità positiva. Che una norma sia accompagnata dallo strumento informatico che la mette in opera significa anche che essa abbandona i tratti di ambiguità che spesso invece la circondano. La perizia nota con sconcerto che in alcuni punti il codice fornito dal MIUR contiene commenti con cui il programmatore ammette di non essere affatto certo di che cosa debba essere fatto. In effetti, questo è tutt’altro che raro: quante volte di un testo oscuro di una norma vengono chiesti chiarimenti? e quante volte le ambiguità non erano affatto presenti alla mente di chi ha formulato la normativa, tanto che cercare di immaginare che cosa egli intendesse è un esercizio inutile? Ebbene, la traduzione in un algoritmo chiaro e documentato non risolve certo in generale questo problema (e ne crea altri: esiste anche il feticismo delle formule!): però elimina almeno una classe di possibili ambiguità e incoraggia una disciplina mentale che non è mai mal impiegata nella gestione della cosa pubblica. Se l’informatizzazione dell’amministrazione non sarà solo un aumento di strumenti ma anche un progresso di consapevolezza e di cultura, i vantaggi saranno molti e per tutti. Altrimenti, prepariamoci al peggio.