È un anno che mi sono laureato ma questo vuol dire poco perché quando uno si laurea in cose tipo medicina o ingegneria il puro esercizio teorico non esiste, e quindi nella realtà dei fatti sono a contatto con la cosiddetta industria da un po’ più di un anno, abbastanza da essermene fatto un’idea sufficientemente precisa. E tragica.

Nell’industria, in generale, esiste una serie di regole che, anche se non sono codificate esplicitamente, tutti conoscono e cercano di applicare meglio che possono, condendole con copiose dosi di buon senso quando serve, perché proprio di questo si tratta: le “buone pratiche“. Ora, ci sono buone pratiche note dall’alba dei tempi, tipo che è più saggio costruire un aratro solido invece di continuare a rompere badili come in Minecraft. O tipo che è una cosa stupida reinventare la ruota ogni volta che dobbiamo spostare del materiale: sappiamo già com’è fatta, e probabilmente c’è qualcuno che ha imparato a costruirla di gran lunga meglio di noi. Penso che fino a qui siamo tutti d’accordo [1], le buone pratiche ci risparmiano fatica e in più beneficiamo della conoscenza accumulatasi col tempo a riguardo.

La reinvenzione della ruota

Il mio primo contatto con l’industria informatica del mondo reale è avvenuto facendo siti e applicazioni web. Prima l’avevo soltanto sfiorata e, da quel che ero riuscito a vedere, mi ero abbastanza convinto che ne esistesse una porzione virtuosa che sa quello che fa e agisce in modo ragionevole seguendo, oltre alle regole codificate proprie della disciplina, anche le buone pratiche. Piombatomi a capofitto nelle applicazioni web, il primo indizio che qualcosa non andava l’ho avuto informandomi sulle buone pratiche del campo e su quali strumenti esistono per facilitarsi il lavoro e concentrarsi più sugli obiettivi che sulla manovalanza. Tragicamente ho scoperto che di buone pratiche ce ne sono a montagne, e almeno altrettanti sono gli strumenti tipo application framework, software già pronti, eccetera. Tragicamente perché ciascuno di questi strumenti nasce da un’osservazione fondamentale: “nessuno di questi strumenti fa proprio tutto quello che mi serve, o lo fa in un modo che non mi piace, quindi tanto vale che mi arrangi” e giù a scrivere l’ennesimo rimpiazzo che, se mai verrà pubblicato, a sua volta non farà qualcos’altro o lo farà in modo che a qualcun altro non piace. Ma se questa fosse la parte peggiore…

Dopo aver ricostruito alcuni siti già esistenti, siti appartenenti spesso a piccole e medie aziende e realizzati da professionisti o studi specializzati, mi sono reso conto fino in fondo dell’abisso in cui mi ero cacciato. Ognuno di questi siti era stato costruito secondo la sola regola che “piuttosto che sprecare tempo e fatica a cercare uno strumento che mi aiuti a sprecare meno tempo e fatica, tanto vale che faccia tutto da me”. La giustificazione che di norma veniva usata coi clienti era che “a noi piace avere il pieno controllo su quello che facciamo, così siamo sicuri di consegnare un prodotto senza fronzoli, artigianale, ritagliato su misura attorno al cliente” e giù zeri in fattura. Tralasciando la surreale pretesa di artigianalità quando si suppone di lavorare in quella che invece si configura esattamente come un’industria, concentriamoci sulla lista di alcuni degli orrori che questa mentalità produce.

• Sicurezza: non esiste. In un solo caso ho visto la bonifica di URL, parametri, e codice HTML per evitare spiacevoli conseguenze. Non dovrei aggiungere che, approfondendo, le funzioni che dovevano mettere in sicurezza queste porzioni critiche erano in realtà degli stub che restituivano liscio il parametro di ingresso.
• URL significativi: a meno che “front.jsp?p=100&sez=3&a=prodot1” abbia un significato per vostra nonna… per la mia, no.
• HTML valido: e sì che basterebbe così poco per evitare problemi quando l’inesperto che aggiorna il sito sminchia l’editor di testo e lascia inavvertitamente un tag aperto.
• Requisiti sovrumani per la gestione: mi correggo, l’inesperto di cui sopra non esiste. Il sito è aggiornabile solo da non meno di un laureato in informatica. O da chi l’ha fatto, con l’indubbio vantaggio che il cliente è costretto a tornare da voi e pagarvi altri soldi. O che chiunque sia da esso contattato, perché voi nel frattempo avete “rifocalizzato le vostre priorità di business” [2], alzi le mani in tempo zero e proponga di rifare tutto “perché quegli incompetenti non sanno neanche di stare al mondo” e poi, tanto per non farci mancare niente, è tutto rotto come prima (aka è fatto allo stesso artigianale modo, quando non peggio) e il cliente ha perso un’altra fraccata di soldi.
• Separazione tra logica e contenuti: eh?
• Usabilità: “ah, sì, ne ho sentito parlare una volta da un tipo che però non sapeva neanche accendere il computer”.

Tondelli di acciaio

Se tutto il problema stesse al livello delle piccole aziende e delle applicazioni web, la cosa sarebbe ugualmente tragica, ma uno potrebbe pensare che magari salendo di livello le cose migliorino. Sbagliato.

Ho fatto numerosi colloqui con aziende di varie dimensioni. La costante, quando il colloquio si sposta sul lato tecnico, è questa: “abbiamo sviluppato un nostro application framework [o qualsiasi altro software] innovativo ed efficientissimo […]”. Questo è il momento in cui in genere comincio a notare che alle pareti non ci sono quadri, sulla scrivania ci sono due penne e un orologio, e fuori dalla finestra si stende un desolato panorama che varia da “parcheggio aziendale” a “future opportunità d’impresa”, e il torrente in piena di buzzword che escono dalla bocca del mio intervistatore diventa un irritante brusio di fondo.

Una volta mi è stato chiesto se avevo domande e, dato che l’intervistatore mi aveva dato l’idea di essere uno sveglio, ne ho approfittato per chiedere come mai c’è questa ossessione delle grandi software house verso la generazione automatizzata di codice usando strumenti nati per fare tutt’altro: in due parole, UML scaffolding [3]. La risposta è stata, a suo modo, illuminante. Essenzialmente il loro magnifico application framework [4] è tutto un brulicare di funzioni che svolgono più o meno tutte operazioni analoghe. Ora, se produci tondelli di acciaio non è che ti metti a batterli a mano dentro lo stampo di ghisa, compri una macchina che ne fa centinaia al minuto, e su questo penso non ci piova. Il ragionamento sembrerebbe calzare: se devi scrivere decine, centinaia di funzioni tutte praticamente uguali, tanto vale che ne scrivi una e poi la fai replicare al computer, d’altro canto abbiamo inventato le macchine proprio per questo. Il meraviglioso castello dorato però si incrina quando escono le cifre: queste funzioni contano per circa il 5% delle righe di codice. Tutto il resto va comunque scritto a mano.

Per carità, non voglio suggerire che a quel punto tanto vale scrivere a mano anche quel 5% di codice, sarebbe folle e incrementerebbe di migliaia di volte la probabilità di introdurre bug invisibili. Eccetto il fatto che, stando al signore di cui sopra, almeno un 10-20% di quelle funzioni generate automaticamente hanno comunque bisogno di un intervento manuale per casi particolari. Proseguendo nella sua spiegazione–che ad onor del vero mi è sembrata molto più lucida e convincente di tante altre a cui ho assistito da parte dei sostenitori di UML–mi racconta poi che hanno sviluppato un loro linguaggio visuale di documentazione di più alto livello in cui integrano i componenti da loro già sviluppati modularmente in modo da poter essere scaffoldati dentro l’applicazione [5] per cui infine generano il 90% del codice in modo automatico, e così compongono le applicazioni che venderanno ai clienti abbattendo notevolmente i costi di sviluppo. Ok, fin qua mi sembra tutto plausibile, addirittura miracoloso, un po’. Ma tornando ai numeri: 5% di codice generato automaticamente di cui 10-20% dovrà comunque essere modificato. Componenti prefabbricati copiaincollati dentro un’applicazione personalizzata. L’unica cosa che mi viene in mente è: duplication galore! Supponendo che due clienti abbiano bisogno del modulo per accedere al database dei dipententi, avremmo due applicazioni separate con una gran parte di codice duplicato. Se trovi un bug in una poi devi riprodurre le modifiche nell’altra ripetendo tutto il processo che parte da quel linguaggio miracoloso sviluppato per abbattere i tempi di sviluppo. Considerando che di clienti, un’azienda un po’ grossa, non ne ha due, ne ha duecento, penso che cominciate a vedere anche voi le falle in questo piano. A quel punto non era meglio sviluppare un vero framework condiviso riutilizzabile senza rigenerare l’intera applicazione ma solo, eventualmente, le parti sviluppate per quel particolare cliente? Tipo le librerie condivise che si usano più o meno dagli anni ’80? A quel punto si tratterebbe di mettere mano al restante 5% del codice, se mai ce ne fosse bisogno, comunque, perché se l’API è stabile, lo strato esterno non se ne deve proprio accorgere. Non so perché ma sento puzza di artigianato.

I maggiordomi in tutta questa storia

A questo punto un lettore distratto potrebbe vedere questo post come uno dei miei soliti sbrocchi contro i colletti bianchi, ma il punto è che non è così. Non solo. Certo una parte della colpa sta in chi lavora male, per pigrizia, per imperizia (e lo so io quanti incompetenti lavorano in un’industria senza garanzie formali di Qualità come quella informatica) o per mala fede. Ma una parte della colpa sta anche nei clienti.

Nessuno, guardando un tornio o una betoniera, ha dubbio alcuno su come funzionino queste due macchine. La cosa è sotto gli occhi di tutti: nel tornio c’è un pezzo di qualcosa che gira e una lama lo modella, nella betoniera c’è una grande cosa che gira e mescola la malta. È tutto un gran girare di cose, e le cose che girano sono palesi–disse Galileo.

Nei computer non c’è niente che si vede girare, nessun organo in movimento, sono artefatti di pura magia nera, ed è a quel punto che diventa più facile credere al fluido magnetico e smettere di preoccuparsene. Risultato: i clienti non sono in grado di controllare l’operato di chi lavora per loro, e chi lavora per loro si sente quindi autorizzato a lavorare nel modo che ritiene più opportuno, cioè quello che gli fa sprecare meno fatica nel breve periodo. Tanto si sa che l’informatica è un mondo in rapidissima evoluzione, oggi ci sei, domani non lo sai, e tantomeno sai chi sarà il poveraccio che si troverà a dover fare assistenza sul tuo software perché il tuo cliente ti ha mollato dopo l’ennesima fattura troppo salata in relazione al numero di volte che ti ha dovuto chiamare perché qualcosa non andava. Mi pare ovvio: se chiami l’idraulico dieci volte in tre mesi e alla fine c’è sempre qualche guasto nuovo, qualche domanda te la fai.

Il punto in tutto ciò è quindi duplice: clienti che non sanno cosa possono chiedere e cosa no, e che quindi spesso chiedono cose improbabili a un’industria terrorizzata di perdere commesse che si costringe a produrre accrocchi sempre più improponibili pur di accontentare ogni capriccio, pure il più insensato, in nome del “tanto il computer batte l’uomo a scacchi, vuoi che non sappia prevedermi come saranno le vendite di calcestruzzo nel prossimo quinquennio fornendogli i dati delle vendite di mojito nel bar sotto casa di mia suocera negli ultimi sei mesi?”.

La parte più scocciante in tutto questo è quando io cerco, nel mio piccolo, di lavorare secondo coscienza e buone pratiche e mi sento dire “bravo, ottimo lavoro, hai fatto come a scuola”. Cioè ho fatto il compitino? A me pare il minimo sindacale. “Eh–risponde rassegnato–purtroppo non funziona così”.

Allora, vogliamo alzare anche noi un po’ il culo e l’asticella? Qualcuno dovrà pure cominciare, e se aspetti i clienti, specie quelli che si occupano di calcestruzzi…

1. Lo so, mi illudo, ma l’illusione aiuta a farsi largo nel letame, quindi portate pazienza.[↑]
2. Che poi vuol dire che siete falliti e avete dovuto iniziare a vendere gnocco fritto sulle spiagge per pagare i debiti.[↑]
3. Su UML avrei tutto un discorsone da fare ma me lo tengo per un’altra volta.[↑]
4. In Java, altro argomento su cui ho molto da dire.[↑]
5. Aspe, fammi rivedere cos’è UML… oh, wait.[↑]