
Dopo la pubblicazione dell’intervista realizzata dal settimanale FF i (pochi) commenti che ho ricevuto avevano tutti un comune denominatore :
Sinceramente non capisco: ci vuole coraggio per raccontare dei semplici fatti ? O per commentare qualcosa ? A me non sembra proprio anche perché di sicuro io non sono una persona particolarmente coraggiosa, anzi …
Personalmente trovo anomalo (o meglio patologico) il contrario.
Ne approfitto poi per spiegare meglio alcuni punti che dall’intervista non si capiscono bene o possono sembrare ambigui :
- Non si tratta di una questione personale fra me e Herzum: ovviamente da un amico non mi sarei mai aspettato un brutto gioco simile ma come ho sempre affermato, se il progetto avesse avuto successo non avrei avuto nulla da ridire anche perché avrebbe sicuramente aperto un indotto importante per tutti gli operatori del settore. Ho comunque voluto raccontare l’antefatto per rendere palese lo “spessore” delle persone coinvolte.
- GeoLafis: dall’articolo non si capisce bene ma quello che ho trovato shockante nella vicenda è il fatto che GeoLafis venga attribuito a Herzum. Per ben due volte nelle risposte date alle interrogazioni dei Verdi GeoLafis è citato fra i (pochi) risultati del progetto Lafis. GeoLafis non solo è stato realizzato totalmente da Territorium Online ma quello che è più importante è che l’intera piattaforma utilizzata (mapAccel ed Apollo/dbSnap) è di Territorium Online. Non un solo bit della nuova mirabolante architettura eGov è stato utilizzato. Il contributo Herzum è stato di tipo pre-analitico: è stato fornito un foglio excel (detto feature catalog, che mi conservo gelosamente) contenente l’elenco dei requisiti dell’applicazione (non l’analisi che abbiamo realizzato di fatto noi assieme agli ottimi Dunja e Klaus della provincia). Attribuire il risultato a Herzum è come se si attribuisse la realizzazione di una ricetta ad una persona che ha stilato la lista della spesa.
- Il valore degli eventuali risultati : Il problema è l’eccessiva complessità (in informatica si parla di sovraingegnerizzazione – Overengineering) che si traduce in tempi di realizzazione insostenibili, oltre che naturalmente a maggiori costi. Quattro anni informaticamente è un tempo enorme, in cui si doveva progettare e implementare non solo il sistema e/o i progetti pilota ma essere totalmente a regime se non addirittura in fase di evoluzione. Un sistema che impiega così tanto tempo per nascere oltre a rischiare di essere subito obsoleto è probabilmente privo della flessibilità necessaria. Fra l’altro questa enfasi sulla difficoltà di implementare un sistema così ampio e complesso serve da scudo dietro cui nascondersi per giustificare i ritardi, i costi e la carenza di risultati.Un esempio concreto: i frameworks che abbiamo progettato e realizzato per la provincia e su cui sono basati decine di progetti funzionanti (fra cui geoLafis) sono stati realizzati in alcuni mesi da un gruppo molto ristretto (in media 3 persone). Sono subito passati in produzione e hanno saputo evolversi efficacemente senza impattare sui progetti già attivi. Qui lavorano decine di persona da ormai quattro anni e le realizzazioni concrete basate su questa architettura sono poche, sperimentali e parziali. Anche se si raggiungessero dei risultati (es. il progetto pilota artigianato) che valore avrebbero ? In 4 anni e con decine di persone impiegate ci mancherebbe solo che non si raggiungesse alcun risultato. Caso mai proprio il fatto di aver portato a termine solo quella parte (e con grandi difficoltà) dimostra inequivocabilmente l’inefficacia della soluzione.
- Le giustificazioni addotte per il ritardo: oltre alla complessità elevata, l’altra giustificazione addotta per giustificare il ritardo dei progetti (in particolare quello per l’artigianato) è quella delle continue variazioni della normativa sottostante. Anche questa giustificazione più che giustificare non fa che confermare l’inefficacia del sistema e anche l’approccio sbagliato nell’affrontare la problematica. Una delle sfide più grandi (e più vecchie) nello sviluppo del software è quella di saper gestire la continua variazione dei requisiti. Proprio per questo motivo lo sviluppo del software tende ad adottare metodologie sempre più flessibili (in contrasto con quelle meno recenti definite “monolitiche”) che rendano la gestione di questi cambiamenti molto meno traumatica. Si capisce quindi come cercare di giustificare ritardi consistenti con tali motivazioni sia di fatto un vero e proprio autogol che dimostra quanto meno l’estrema immaturità della soluzione scelta. Un esempio illuminante: il programma che calcola gli stipendi per i dipendenti provinciali è un vecchio programma sviluppato con un altrettanto (non me ne vogliano i realizzatori) vecchio linguaggio di programmazione. Per giunta è sviluppato quasi totalmente da personale interno senza l’assistenza di costosissimi consulenti e complesse infrastrutture. La normativa delle paghe è quanto di più intricato e mutevole si possa immaginare; cosa avrebbero dovuto fare questi sviluppatori, non realizzare il programma aspettando che la normativa si stabilizzasse ? Fra l’altro si manda un messaggio devastante: le vecchie metodologie si dimostrano più efficaci proprio laddove le nuove dovrebbero apportare vantaggi. Si aggiunge quindi danno al danno.
Un ringraziamento va infine a tutti quei supposti amici e/o estimatori che avevo in provincia: in quasi cinque mesi nessuno si è più fatto vivo.
Vedi anche :
http://ssette-bloggando.blogspot.com/2007/10/senso-civico-e-giochi-di-potere.html
http://ssette-bloggando.blogspot.com/2007/09/la-dignit-della-prestazione.html






