Edizioni Infomedia

Scrivo questo post a malincuore per condividere la mia esperienza. Quest’anno sono riuscito ad ottenre un budget per riviste libri e ho deciso di sottoscrivere una abbonamento cartaceo a diverse riviste delle edizioni Infomedia. Ho spedito il fax con la copia del bollettino postale il 1 febbraio. Ad Aprile o Maggio (non ricordo bene), non avendo ancora ricevuto nulla, ho scritto una mail in cui chiedevo spiegazioni. Mi e’ stato risposto che le riviste erano in ristampa e che sarebbero cominciate ad arrivare. In effetti ne ho ricevuta una. Poi silenzio di tomba fino a Settembre quando ho scritto una mail in cui chiedevo delle date certe per le consegne delle riviste.

Nessuna risposta.

Sono ancora abbonato a Java Journal, che ha seguito una sorte analoga. Devo ancora ricevere il numero 5 cartaceo (ho rifiutato la proposta della edizione pdf) che reca la data di febbrario 2008.

Mi chiedo se qualcuno ha avuto esperienze simili alla mia. Se lo fa e lascia un commento nel blog almeno cerchiamo di “fare massa” e di diffondere le nostre esperienze in modo che altri evitino i nostri errori.

E’ un vero peccato, una volta Computer Programming era una rivista veramente pregevole, ora invece il servizio clienti e’ scarso e non si riesce ad ottenere una copia cartacea. Spero almeno di riuscire ad ottenere un rimborso di quanto pagato.

ho cambiato il nome al blog

Oggi ho deciso di cambiare nome al blog in quanto, purtroppo per me, devo ammettere che non sono più un tecnico in senso stretto. Da diversi mesi devo coordinare il lavoro di altri e mi rimane veramente poco tempo per programmare e progettare software. Sono convinto che le cose cambieranno (a favore delle attività di programmazione), ma ci vorrà del tempo; inoltre sono visto come responsabile e non come operativo per cui non posso più parlare di vita da tecnici. Sono (e credo rimarrò) una persona che sa cosa vuole dire programmare e progettare software per cui da oggi il mio punto di vista sarà quello di chi, sapendo come si fanno le cose ed essendo responsabile di un gruppo di persone che lo devono realizzare, cerca la quadratura del cerchio (ovvero mettere d’accordo capi progetto e tecnici).

I tipi di tecnico IT e la qualità del software

Esistono diverse categorie di tecnici IT, ma vorrei soffermarmi su due categorie.

La prima è quella che quando chiedi una stima ti fornisce un numero di giornate sempre piuttosto basso (sono la fortuna dei commerciali e dei PM) e che alla fine entro la data stabilita qualcosa riesce a darti. il problema è quasi sempre il cosa. Spesso il software realizzato mostra una serie di bug evidenti che rivela che il grosso del lavoro è stato fatto, ma manca ancora la fase di rifinitura (ovvero quella di test serio). Cosa significa la maggior parte del lavoro? Significa che il codice all’80% circa c’è già tutto, non sono gestite le finezze ed i casi “estremi” (ovvero tutte quelle condizioni di input normali per l’utente, ma ignote allo sviluppatore).

Peccato che per l’utilizzatore questo significhi che il prodotto è al 40/50% non all’80, con le conseguenti lamentele del PM, del commerciale, del cliente.

Questo tipo di persona, se ha passione per il suo lavoro e non è uno che tira via (basta guardare come è scritto il codice per riconoscere il tipo), è di quelli a cui piace cambiare progetto e imparare sempre, a volte a ritmi decisamente elevati. Il motivo per cui non esegue i test è che ha già assorbito le basi della tecnologia e quindi ha già la testa che pensa al prossimo progetto, i test non aggiungono nulla o quasi al suo percorso tecnico.

Il secondo tipo di tecnico IT è quello che si potrebbe definire “Camillo Precisini” (il nome è preso da una favola per bambini che parla di un cane estramente meticoloso e preciso, fino all’esagerazione). Per lui il software non è mai finito e dopo la prima fase di realizzazione ne segue una, tendenzialmente infinita, di test, test, test. Difficilmente queste persone ti danno una data di fine (se te la danno) compatibile con le scadenze del progetto. La fine di solito la mette il PM che intima di rilasciare il prodotto, pena la crocifissione nella mensa aziendale. Il prodotto finito è decisamente più stabile e l’utente è più soddisfatto.

Quela dei due profili dovrebbe essere privilegiato(a parità di eleganza del codice e dell’architettura software)?

La risposta sembrerebbe essere il secondo.

Vorrei riflettere più a fondo.

Il tecnico smanettone consegna generalmente in tempo ed il suo semilavorato necessita di qualche giorno (ovviamente dipende dalla dimensione del sofware) per essere definito accettabile da cliente. E’ il classico caso in cui il PM che conosce i suoi polli aggiunge un tot di giorni di margine e raggiunge l’obiettivo. Il tecnico preciso consegna quasi sempre in ritardo e comunque vorrebbe avere più tempo, vorrebbe avere più specifiche, etc,etc. Il software che consegna anche se più stabile, va comunque rivisto, in quanto la produzione software segue un percorso ciclico in cui ad ogni consegna si rivedono alcuni presupposti precedenti.

La cosa che va capita è che il software è buono solo se chi lo usa lo ritiene tale; inoltre essendo un prodotto umano è per definizione soggetto ad errori. Che senso ha consegnare un software tre mesi dopo e avere lo stesso gli utenti che lamentano (anche se meno rispetto a quello che sarebbe avvenuto tre mesi prima)?

In questo caso l’utente ti dice: me lo hai consegnato tardi e ci sono pure degli errori (per lui evidenti).

Gli errori ci saranno sempre, tanto vale consegnare in tempo e poi correggere gli errori.

I programmatori migliori di solito vorrebbero produrre un software che loro giudicano decente; la cosa che va capita è che:

1. Spesso il grado di qualità del software è percepito molto diversamente dall’utente
2. Non è detto che si debba arrivare alla qualità ottenuta al primo rilascio

La qualità del software, intesa sia dal punto di vista del codice che delle funzionalità utente, si ottiene solo dopo una fase di rodaggio in produzione quando si capisce cosa questo deve fare anche dal punto di vista dei dettagli operativi. Questo significa che è ottenibile sono dopo n iterazioni sviluppatore-utente.

In questo scenario il primo profilo spende meno tempo ed energia e nel lungo periodo, a parità di qualità, riesce ad essere più produttivo. Senza contare che nel mondo reale è tutto urgente ed il tempo non basta mai, per cui avere delle persone che investono tempo in cose che si potrebbero rivelare inutili o che potrebbero essere essere fatte fra n mesi può essere un elemento di freno oggettivo. Questo non vuol dire che non ci sia posto per i precisini, ma che questi dovrebbero cercare di bilanciare gli smanettoni (direi che un precisino e due smanettoni è una buona proporzione) per ottenere un compromesso accettabile.

Indovina chi

Voglio condividere un caso da manuale a cui ho assistito in prima persona in questi giorni. (uso nomi di fantasia per evitare riferimenti espliciti)

L’azienda Fantasia vuole collaborare (oggi dire vendere sembra una brutta cosa) con l’azienda Sogno e dopo uno scambio di email/telefonate ecco l’incontro per fissare i punti cardine del rapporto. L’azienda Fantasia invia Pippo e Paperino che illustrano i prodotti.

I manager di Sogno sono molto contenti, Pippo e Pluto rispondono alle varie domande e alla fine Biancane afferma: “Ok, mi avete convinto, allora siamo tutti d’accordo, andiamo in produzione il 10 luglio”.

Paperino rimane decisamente perplesso, ammutolito per quel secondo che basta per far capire che casca dalle nuvole (e non atterra dolcemente). Biancaneve reagisce “Questo era un requisito emerso e comunicato fin dai primi contatti”. Pluto rimane in silenzio per il tempone cessario a far comparire un sorriso diabolico e dice “Confido nelle capacità della nostra azienda”.

Domanda: chi è il tecnico fra Paperino e Pluto?

I tecnici e i Project Manager

Il rapporto fra tecnici e PM (ovvero i project manager) è quello che solitamente crea più grattacapi. Le cause sono molteplici, ma due sono quelle più frequenti

1. I soldi
2. il tempo

Se queste due si è discusso a lungo per cui oggi voglio affrontare un altra causa, più rara, ma ben più insidiosa: il PM ex o finto tecnico. E’ un mix quasi micidiale che richiede molta calma e fermezza per essere gestito.

Lo scenario è di solito è il seguente:

Arriva il PM con il progetto completo di importo, giornate uomo e scadenze (le stime le ha fatte lui, ha imparato a farle quando era tecnico). Ecco il “pacco regalo”, tutto già fissato, c’è solo da lavorare. Con una sola piccola clausola, che il PM guarda, analizza e critica. E arrivano domande di questo tipo:

Ma questa funzione vuoi proprio farla così?
Ma sei sicuro di scegliere questa architettura?

Per poi passare in un crescendo quasi inarrestabile alle frasi del tipo

L’ho già fatto 10 anni fa nella metà dei giorni e dei soldi.

A questo punto la risposta è scontata: allora perchè non hai proposto la tua soluzione?

L’approccio da seguire, se si vuole evitare di arrivare ad una frizione inutile a tutti è quella di stabilire dei confini basati sulle responsabilità: se il progetto è in difficoltà per ragioni tecniche chi è il responsabile?

Lo si scriva nero su biano ed in cc a chi di dovere e la partita è chiusa. Si concorda un piano di scadenze e si lavora su quello.

Le cause di questi attriti non sono tecniche, sono caratteriali. I tecnici solitamente sono tali perchè amano avere il controllo delle cose che fanno, ovvero avere la sensazione (ed in vb6 si andavo veramente poco più in là) che quello che si produce sia assolutamente deterministico. Che cosa controlla un PM?

L’operato di altre persone (oltre ai soldi s’intende).

Non c’è niente di meno deterministico (e se poi si usa ancora vb6…..)

Come reagisce il PM? Cercando di imporre la sua autorità, con la speranza di un maggiore controllo.

Peccato che le persone riconoscono l’autorità (in senso lato, ovvero si creino dei riferimenti di cui fidarsi) e quelle imposte senza fondamenta creano un sentimento completamente diverso.

Che fare (se il PM non ci arriva da solo)?

L’unica speranza di lavorare sereni è quello di concordare costi e scadenze sensati e cercare di proporre soluzioni alle situazioni critiche, ovvero di cominciare a dare delle certezze.  Se il PM capisce di avere un  maggiore controllo e capisce anche che comportandosi in un certo modo può continuare ad averlo probabilmente cambierà atteggiamento.

Basterebbe capire che in progetto in cui ci sono n tecnici ed un pm che farà per forza di cose la maggior parte del lavoro? Per raggiungere lo scopo chi è che deve essere produttivo al 100%?

I tecnici, per cui o li si motiva o non si raggiunge l’obbiettivo.

Se non lo capisce (o non lo si vuole capire)….pazienza, peggio per lui; probabilmente rinuncerà ad una parte del suo premio di produzione (che di solito è più alto di quello di un tecnico).

Un libro da non perdere

Oggi ho cominciato la lettura di un nuovo libro e (finalmente) ho avuto la conferma che non sono un pazzo visionario, almeno per quanto riguarda il modo di gestire i tecnici di una azienda IT. Essa afferma che molti manager SBAGLIANDO trattano i tecnici come pezzi di una catena di montaggio, quando un pezzo si rompe basta ordinarne uno uguale. Finalmente dopo 10 anni di lavoro leggo un libro che mette nero su bianco quello che ho sempre pensato, ovvero che il motto

“nessuno è insostituibile”

sia solo una mezza verità; in quanto è vero che l’azienda di una certa dimensione va avanti anche se una persona meritevole se ne va, ma è anche vero (e in questo moento non sto pensando a me stesso) che la “botta” spesso si sente (e nel 1999-2000 di botte ne ho sentite parecchie).

Il libro continua mostrando come i manager spesso agiscano in maniera semplicemente illogica perchè

“Le non soluzioni facili hanno molto più appeal delle soluzioni impegnative”

Molto bello anche il capitolo che spiega come sia sbagliato dare scadenze impossibili o mettere continuamente sotto pressione i tecnici.

Il tutto fa il paio con un paio di situazioni reali (una vissuta in pirma persona ed una no) che confermano ancora di più che non sono io il matto, ma chi crede che lo sviluppo software sia uguale al mondo della produzione industriale (e gestisce le persone come tali).

Mi chiedo come mai ci ho messo tanto a scovare questo libro.

Per chi fosse interessato sto parlando di “Peopleware” di Tom DeMarco – Timothy Lister

La carriera del tecnico

Questo post riprende uno precedente in cui parlavo della parabola del tecnico ed in cui emergeva come, almeno in Italia, non ci sia spazio reale per i tecnici di lunga e comprovata esperienza (o almeno i posti ci sono, ma sono l’eccezione e non la regola). Durante questi mesi ho avuto l’occasione di selezionare diverse persone che si candidavano per posizioni tecniche. Con mia grande sorpresa, la netta maggioranza indicava la posizione di tecnico come temporanea, ovvero come balzello da pagare per diventare cosa?

Capo progetto o analista (per fortuna nessuno ha detto manager o dirigente )

Quando ho chiesto perchè ho ottenuto risposte simili che in sostanza convergevano su un aspetto: il desiderio di coordinare (che tradotto nella mia testa significa parlare molto, scrivere poco e sapere ancora meno).

Tali aspettative si sposano con l’opinione di un dirigente che conosco che ha più volte affermato (cito quasi testualmente):

“Se una persona ad una certa età è ancora un tecnico allora è un coglione”

La certa età è stimata intorno ai 40.

Quello che mi verrebbe da dire a queste persone e che dico pubblicamente è :

Se vole fare i project manager o gli analisti fatelo, ma senza “inquinare” le posizioni tecniche dove probabilmente farete solo dei danni in quanto farete un lavoro che non vi appassiona e non adatto a voi. Non sto escludendo una carriera di coordinamento per i tecnici; quando si accumula un buon bagaglio di esperienze è giusto condividerle e far evitare alle persone con meno esperienza i propri errori ed è anche corretto non spendere il proprio tempo in attività senza valore aggiunto.

Se volete fare i manager o dirigenti studiate come tali, pagate un bel MBA, conoscente gente conta e poi trovatevi un lavoro ben pagato, non c’è bisogno di fare la gavetta da tecnico, anzi è controproducente.

Java vs. PHP atto II

Dopo aver finito la mia prima applicazione in PHP ed averla messa on-line voglio tornare sull’argomento del confronto fra le due piattaforme.

Lo scopo del post è rispondere alla famosa domanda: per scrivere la mia applicazione web devo usare java o php?

Caso n.1: se l’applicazione andrà installata sotto forma di hosting la scelta è praticamente obbligata php

Caso n.2: se chi scrive l’applicazione non ha fatto studi informatici o non ha anni di esperienza nella programmazione la scelta  consigliata è php

Caso n.3 se si sta cercando di fare del content managament (ovvero pubblicazione di contenuti tipo pagine web) la scelta consigliata è quella di guardare se esiste un programma php (e ce ne sono veramente TANTI) che fa al caso vostro.

Caso n.4 se dovete scrivere una applicazione che è al 50% HTML e 50% web service la scelta consigliata è Java

Caso n.5 se dovete fare progetti di cooperazione applicativa (secondo lo standard CNIPA) la scelta obbligata è java

Caso n.6 se dovete produrre applicazioni “corpose” Oracle based la scelta caldamente consigliata è Java

Solo i casi n.1 e 5 sono “obbligatori”, gli altri sono suggerimenti. Al termine della mia esperienza posso confermare che se si vuole scrivere una applicazione senza usare prodotti già fatti, ma solo librerie(es Spring framework piuttosto che Zend framework) Java è la scelta a mio avviso più produttiva (a patto di ipotizzare che le persone che ci lavorano abbiano la stessa produttività in entrambi gli ambienti) e matura, in quanto a livello di librerie web (e NON di prodotti tipo portali,CMS, etc) Java offre delle soluzioni più complete e più sofisticate (per esempio la gestione delle transazioni via AOP in Spring o i custom tag Spring MVC o Struts).

lo sviluppo software e le metafore sbagliate: l’architettura (episodio 2)

Dopo aver spiegato perchè, secondo me, architettura e sviluppo software non si possono paragonare per quanto riguarda il processo di creazione del prodotto continuo le riflessioni estendole alla fase successiva: il post vendita.

Se nel caso della produzione la metafora poteva sotto qualche aspetto reggere, una volta che si parla di manutenzione la metafora è inapplicabile.

Provo ad elencare le differenze con una serie di domande.

Vi immaginate di dover chiamare per forza l’artigiano che vi ha fatto il lavoro (elettricista, muratore, idraulico, etc) per qualsiasi modifica?

Vi immaginate di dover pagare un contratto di assistenza annuale per i problemi con l’uso della casa?

Vi immaginate di sentirvi dire dopo tre/cinque anni che la vostra casa è obsoleta e che ne vuole una nuova?

Mi pare che sia sufficiente.

lo sviluppo software e le metafore sbagliate: l’architettura (episodio 1)

E’ già da diverso tempo che ho in testa questo argomento. Spesso la progettazione e lo sviluppo vengono paragonate all’architettura, da cui vengono presi a prestito vari modelli. Un esempio su tutti è la qualifica software architect.

A mio parere assimilare il processo di realizzazione di un software al processo di realizzazione di un edificio è decisamente fuorviante e ci sono più divergenze che similitudini.

Consideriamo come viene fatto un edificio: si parte dal progetto che viene approvato (a volte accompagnato della presentazione di un plastico) e da lì si comincia a costruire. Una volta che si comincia alcune cose diventano immutabili, per esempio non è più possibile (se non con costi ed oneri esagerati) spostare la costruzione o cambiare forma alle fondamenta. E’ possibile cambiare i particolari, le collocazioni di alcuni muri, ma la natura dello stabile rimane quella del progetto. La costruzione viene fatta da una serie di figure completamente diverse e spesso molto specializzate, chi tira su i muri difficilmente monta gli infissi o fa l’impianto elettrico o quello idraulico o posa i pavimenti. L’architetto o l’ingegnere o il geometra vanno in cantiere per assicurarsi che il direttore lavori segua fedelmente il progetto, ma sicuramente “non vanno alla betoniera”. Un altro fattore importante è l’interscambiabilità, un muratore un giorno fa un pezzo di muro che il giorno dopo può essere finito da un collega, senza particolari passaggi di consegna.

In sostanza tutto procede secondo logiche preordinate e basate su standard accettati. (Se qualcuno pensa che nei cantieri edili ci sia il caos legga quello che segue).

Nell’informatica invece non accade nulla o quasi di tutto questo. Il committente spesso aprrova un progetto non conoscendo i dettagli di cosa verrà fuori e capisce cosa vuole solo quando vede funzionare un pezzo di software. Ne risulta che spesso è necessario un ciclo di prototipi e rilasci per tarare il tiro. Chi di noi andrebbe ogni giorno in un cantiere cantiere che ha commissionato dicendo “mi sposti la finestra più in qua” o “le piastrelle che ho scelto e che avete montato non mi piacciono più” o ancora “mi sposta la casa altri di 30cm dalla strada”? aggiungendo “tanto quanto vuoi che costi”?

Chi costruisce una casa sa benissimo che dopo che un pezzo è stato fatto c’è un costo ben preciso per buttare giù e rifare. Chi commissiona un software evidentemente no.

Un altro aspetto è la specializzazione che nell’informatica è molto meno sviluppata, proviamo a lasciare una classe o anche una funzione a metà ed assegnare ad un altro programmatore il compito di finirla; quanto tempo ci vuole per la presa in carico di quanto già fatto? Inoltre spesso unprogrammatore svolge diversi compiti (design dell’interfaccia grafica, modellazione/definizione di parti della base dati, etc)

Un altro indicatore che indica quanto la produzione del software sia diversa e più arretrata rispetto alle costruzioni edili è la presenza dei building block ovvero dei componenti riusabili. Nell’edilizia si usano, mattoni porte e finestre già fatte, nell’informatica molto meno. Cosa succederebbe se un giorno entraste nel cantiene dove stanno costruendo casa vostra e vedeste un muratore che con un camino acceso fabbrica dei mattoni? Immaginiamo il dialogo:

Noi: Buongiorno, cosa sta facendo?

Muratore: Buongiorno, sto facendo i mattoni per costruire la casa

Noi: Perchè?

Muratore: Sa, quelli che sono in commercio non mipiacciono tanto, poi hanno quegli spigoli così ruvidi, me li faccio io così faccio prima e sono come mi servono.

Il risultato sarebbe: fuori dal cantiere a calci nel sedere.

Nell’informatica molto pochi si scandalizzano se qualcuno nel 2008 si fa un package di logging in java o in .net eppure la fine dovrebbe essere quella del mutatore sopra citato.

Un’altra differenza sostanziale è che chi comincia a programmare fa una carriera in cui pian piano diventa coordinatore e poi project manager o commerciale; quanti muratori-architetetti o elettricisti-ingegneri conosciamo?

Si conclude qui questa riflessione sul processo di costruzione software e sulle sue differenze rispetto al processo di costruzione edile. Tutti i fattori elencati fanno parte della fase costruzione, manca ancora la fase “manutenzione e post vendita”, ma credo che già si intuisca come parlare di software architect sia una cosa che non ha fondamento reale. Nei prossimi articoli proverò ad illustrare altre differenze e delle metafore più appropriate.