domenica 20 febbraio 2011

Competenza e governo

Per motivi di lavoro, ho preso in carico il codice di un portale realizzato da *grande azienda nazionale* per *grande progetto nazionale*.

Il codice è, diciamo, imbarazzante.

Manca una qualsiasi documentazione significativa. Il documento di progettazione è chiaramente stato scritto per soddisfare una milestone, e non ha nessuna attinenza con quanto è stato fatto effettivamente. L'unica documentazione realistica è un elenco di moduli su due paginette, che effettivamente è significativo. Manca la descrizione del database relazionale e dei flussi fra i vari moduli. Ovviamente manca un minimo di documentazione del codice a livello di classi.

Manca un qualsiasi processo di build e deploy documentato. Ci sono istruzioni per lo start/stop di alcuni processi, ma non è descritto come ricreare il sistema ex novo.

Il codice di per se è il trionfo del copia e incolla. Per esempio, ci sono circa 300 (trecento) punti nel codice dove si legge dai file di configurazione quale lingua è selezionata per il portale. Ovviamente abbonda codice commentato o semplicemente morto. I warning sono dell'ordine di alcune migliaia. I metodi sono scritti in maiuscolo e minuscolo, in italiano e inglese, con e senza l'underscore in mezzo.

Manca infine un qualsiasi test di unità.

Si tratta dl mio incubo per i prossimi sei/dodici mesi, visto che dovrò in pratica sputare sangue per rimettere in piedi questo portale, renderlo utilizzabile e far fare bella figura al cliente - che attualmente è piuttosto nelle pesti.

Ne parlo un po' perchè agli informatici piace raccontare quanto è grosso l'orso che stanno cercando di catturare, e un po' perchè è il rappresentante tipico del problema della separazione della competenza dal controllo. E' un vecchio mito che la sinistra ha addirittura cristallizato in una legge - la Bassanini - dove ai politici si da come funzione l'indirizzo e il controllo, e all'amministrazione l'esecuzione.

Parlando con il cliente, ho domandato come mai avessero accettato un prodotto così scadente: mi ha risposto che il fornitore aveva fatto un'offerta scritta benissimo e che comuqnue lui mancava di una persona capace di andare a guardare il codice e capire se è fatto bene oppure no.

In pratica, il cliente ha esaminato la descrizione del processo fatta dal fornitore, lo ha ritenuto formalmente corretto ed ha deciso che era sufficiente, anche perchè non era in grado di andare oltre quella descrizione. Il cliente ha detto "io do l'indirizzo e controllo il risultato, ma i dettagli li sa chi fornisce la soluzione".

Il che, in teoria va benissimo. Voglio dire, va benissimo se dovete scrivere una legge; va un po' meno bene se dovete applicarla.

Allora, voi "controllate il risultato". La domanda corretta è: "COME controllate il risultato?"

Prendiamo il caso del mio progetto. Se siete un burocrate, l'unica cosa che potete fare è fare un controllo formale su cosa viene consegnato: vi danno un cd alla tal data, un documento alla talaltra, vi fanno una demo il giorno x, entrano in produzione il giorno y.Ok, ci sono difetti, ma c'è la garanzia per correggerli, no?

Poi il portale va davvero in linea e crolla dopo due secondi. O sta in piedi con lo sputo. O cose così. Solo che è collaudato, si è andati avanti coi SAL...

Dove sta il problema? Che il controllo sta guardando le cose sbagliate; se un fornitore vi descrive il suo processo di sviluppo, io voglio VEDERLO. Vengo da voi e voi mi mostrate COME state lavorando, e mi fate parlare coi vostri sviluppatori, e mi dimostrate che state seguendo quello che avete descritto.

Poi definiamo i test funzionali, le ipotesi di carico e di fallimento e come intendiamo verificare le cose. Mi aspetto che il fornitore abbia già gli strumenti per costruire rapidamente test funzionali e li abbia usati, che sappia cos'è un processo di Markov e come definire un carico ipotetico.

Poi mi mostrate il vostro codice, e lo analizziamo pezzo a pezzo, voi mi spiegate l'architettura e io vi dico cosa mi torna e cosa mi sembra molto opaco. Mi spiegate i vostri standard di creazione del codice e me li fate verificare.

Poi mi fate vedere i test di unità che avete - di gente che programma a cavolo se ne avrebbe anche abbastanza.

Poi mi presentate il team che lavorerà al progetto - QUEL team per TUTTA la durata del progetto, e non "il nostro nuovo cocopro".

Ovviamente, c'è un problema: non potete essere un burocrate per fare tutto questo. Dovete essere competente. Non potete separare la competenza dal controllo - potete SOLO separare il controllo dalla realizzazione.

L'idea di mettere qualcuno a controllare qualcosa SENZA che sappia come si fa quella cosa genera tipicamente disastri - ovvio, potete far pagare penali a un fornitore incapace, ma il vostro obiettivo non è far pagare le penali, è ottenere un sistema che funzioni.

Solo chi sa fare sa cosa si guarda e perchè è importante. L'idea della gestione senza la competenza è molto americana - e come tale, molto stupida.

lunedì 14 febbraio 2011

Differenze familiari

In Italia ci sono due famiglie potentissime e ricchissime.

In una, il potere si passa esclusivamente per via maschile, secondo le migliori tradizioni regali.

In un'altra, il potere passa a chi se lo è meritato. Incidentalmente, la persona più potente nell'azienda di famiglia è la figlia, non il figlio.

Ovviamente una delle due famiglie è indicata come sessista. A voi decidere quale.