CONOSCERE TECNOLOGIE E LINGUAGGIO NON E’ SUFFICIENTE…
Pare che la Merkel (ma potrebbe essere una fake news) voglia introdurre nelle scuole elementari, a fianco dell’insegnamento della lingua e della matematica, quello della programmazione.
a cura di Graziano Guazzi
Che sia vera o no, questa ipotesi mi offre l’occasione per smitizzare la capacità di “saper programmare”. Sul piano pratico, quello che dirò aiuterà ad evitare disastrose trappole, nella scelta di un nuovo sistema informativo. Così decontestualizzata, la proposta sembra figlia del seguente ragionamento: il mondo si sta digitalizzando, dietro la digitalizzazione ci sono i computer, dietro i computer i programmatori, dunque “saper programmare” sarà sempre più importante dello saper scrivere e al far di conto.
Per come la penso, la conclusione va a braccetto con la celebre corazzata (Potëmkin) Kotiomkin del ragionier Fantozzi. Ossia è una cacata pazzesca.
Nel gennaio del 2017 è stato reso noto dal Mit Tecnology Review che il Google Brain artificial Intelligence research group è riuscito a sviluppare un software di intelligenza artificiale in grado di modificare se stesso (ossia di programmare). Basterebbe questo corto circuito per buttare nel cestino l’idea di una nuova civiltà composta da cittadini programmatori. Ci vorranno. Ma nella stessa misura e per la stessa ragione per cui ci vorranno medici, avvocati, architetti, etc.
Prima dell’avvento del computer le “macchine” venivano progettate e costruite con uno scopo ben definito. Si pensi alla calcolatrice (quella di ferro), alla macchina per scrivere (sempre di ferro), alla locomotiva, al pianoforte, al telefono, alla radio, alla televisione, etc. Nessuno di questi congeni poteva svolgere un compito diverso da quello per cui era stato concepito e messo sul mercato pronto all’uso. La rivoluzione prodotta dall’invenzione del computer consiste nel capovolgimento di fronte. Il computer è una macchina costruita per svolgere compiti non determinati a priori.
In effetti, a differenza degli altri prodotti, i computer che troviamo negli scaffali dei supermercati, non sono di alcuna utilità per chi li acquista. Oggi, tutti sappiamo che servono i programmi e ci siamo fatti un’idea abbastanza precisa (se non altro in termini pratici) di cosa sono. E’ grazie al software che la stessa scatola (PC, Tablet, Smart Phone) può essere usata per scrivere, tradurre in cinese, fare di conto, guardare un film, ascoltare la radio, contare i passi, telefonare, misurare la pressione, stampare un estratto conto, suonare il pianoforte, scoprire e correggere errori di ortografia e grammatica, inviare una fattura, fare una diagnosi medica, calcolare le orbite, giocare a scacchi, etc.
Chi progetta un computer non sa nulla, né servirebbe per aumentare la qualità della sua opera, di contabilità, di cinese, di medicina, di musica, di grammatica e ortografia, di orbite, di partite a scacchi, etc. Tuttavia, ai fini dell’usabilità del computer, questo è un sapere che in qualche modo e misura dovrà arrivare a chi scrive programmi. Un sapere, si badi bene, che in nessun modo dipende dalla conoscenza dei linguaggi/tecnologie utilizzati per programmare.
Pensando ai software “Gestionali”, chi ha commissionato (come si usava fare in passato) la scrittura di soluzioni ad hoc sa bene quanta fatica, soldi, e tentativi sono occorsi per arrivare a un risultato accettabile (per non parlare dello sviluppo e mantenimento nel tempo), a causa di incomprensioni o lacune nella descrizione dei risultati desiderati. Quante volte, in questi complicati progetti, le discussioni si sono arenate su “Non me lo avevi detto”, “E’ vero, ma tu non me lo avevi chiesto”.
Chi non ha fatto questa esperienza, come esercizio mentale, può immaginare di dover commissionare la scrittura di un’applicazione per la “raccolta ordini e incassi” nel settore del beverage/food a un gruppo di super programmatori, che conoscano poco, se non nulla, della problematica. Quante cose dovrà chiarire e spiegare il committente?
Non sarà difficile immaginare che la qualità del risultato non dipenderà unicamente dalla padronanza delle tecnologie utilizzate, ma prima ancora dalla conoscenza delle problematiche, intese come specie e caso di specie, e dalla capacità di comunicare (committente) e apprendere (gruppo di lavoro). Questione, questa, tutta da dimostrare e, in presenza di presunte inadempienze, di difficile analisi anche per i giudici. In effetti, l’atipicità di queste forniture (e contratti) ha richiesto la definizione di nuovi principi e la revisione (non ancora conclusa) degli impianti normativi e della loro interpretazione. In merito si veda GBI di Apr/Mag 2016.
Per le stesse ragioni, solitamente, le Software House sono fortemente specializzate. Chi ad esempio ha sviluppato con successo (il che significa che può vivere di quello) soluzioni software per il settore “scarpe” difficilmente è attratta da altri settori, esempio “berverage/food” (e viceversa). D’altra parte se la soluzione proposta si prestasse a entrambi i settori, non avrebbe specificità, ossia valenza strategica.
Non è difficile comprendere che il processo di presa ordini dell’agente che propone “scarpe” sia completamente diverso nei tempi e nei modi da quello che tratta “birra”. I modelli di “scarpe” cambiano con le stagioni. Farle vedere e apprezzare è di fondamentale importanza al momento della presa ordine. Gli ordini vengono presi con calma una stagione per l’altra (chi produce, lo fa sull’ordinato). Chi vende “bollicine”, rincorre ogni settimana l’esercente (che conosce molto bene i prodotti) dietro il bancone; parla (o cerca di farlo) di promozioni, di sconti merce, di grane sulla consegna precedente o sull’impianto di spillatura, di scaduto, di premi di fine stagione, etc.
Queste sostanziali differenze devono necessariamente essere incorporate in modo completo e ottimizzato in distinti software di presa ordine. La struttura logica dei dati, le videate, i passaggi dall’una all’altra, gli algoritmi di calcolo, la forma e i tempi delle risposte, la consultazione dello storico, le priorità, etc., saranno davvero molto diversi, anche se il risultato finale sarà (banalmente) un codice articolo e una quantità che deve essere consegnato al cliente. Queste argomentazioni chiariscono che la padronanza delle tecnologie e dei linguaggi di programmazione sono condizioni necessarie, ma certamente non sufficienti per programmare il computer. Aiutano a resistere al canto delle sirene, evitando tragici errori di valutazione (che ho visto commettere più di una volta).
Per un bravo programmatore è infinitamente più facile (e molto meno costoso) apprendere una nuova tecnologia che nuove classi di problemi in cui spenderla. Inevitabilmente, ne consegue che, nelle scelte delle soluzioni, la priorità non deve essere data alla padronanza tecnologica, bensì alla conoscenza delle problematiche (in ogni caso, questa non deve essere posta in secondo piano o addirittura ignorata). D’altra parte (fortunatamente), questo principio è alla base dell’orientamento dei giudici che sempre più spesso considerano dirimente l’obbligo di risultato in luogo all’obbligo di mezzi. Come a dire che il fornitore non deve garantire le sole competenze tecniche ma anche tutta la competenza e l’impegno che serve per produrre una soluzione conferme alle aspettative del committente. Infatti, qualificandosi come esperto, il fornitore è tenuto a specifici e penetranti doveri di informazione, facendosi carico di porre domande precise al fine di verificare la copertura funzionale che il cliente è fisiologicamente portato a dare scontata.
Tornando alle aule scolastiche: ben vengano i corsi di programmazione (sono un ottimo esercizio mentale, così come lo è il latino, ma entrambi sono linguaggi “morti” o sul punto di esserlo). Per sviluppare buoni programmi, a monte del “programmatore”, ci vogliono capacità critica, idee, coraggio, capacità di imparare e comunicare. Questi strumenti hanno la stessa sostanza delle montagne. Le tecnologie durano come la neve al sole.
