Chi mi segue da questa piccola finestra (la puntata precedente è comunque qui) sa che da circa un mese non mi è più “permesso” di scrivere codice in PP: il mio attuale e unico collega infatti è allergico alle coppie. Non solo, purtroppo io ed il mio collega abbiamo anche principi prospettive di visione del codice molto differenti, direi addirittura opposte. Ma non è del mio collega (per altro simpatico e di vecchia data) che vi voglio parlare, quanto invece delle mie reazioni e dei miei peccati in questo mese.

Nell’ultimo mese e fino a qualche giorno fa ho prodotto software di bassa qualità, voglio cercare di capire il perché con voi. Sicuramente e per onestà nei miei confronti il motivo principale è la scarsissima conoscenza dei tool utilizzati. Ma questo lo sapete già. Più interessante è invece come il rapporto tra me ed il mio collega, i miei timori e il disallineamento di valori hanno influenzato la mia capacità di creare qualità.

Read the rest of this entry »

Ieri a Milano si è tenuto il primo giorno della Java Conference 2006.

E’ stata per me innanzi tutto un’occasione preziosa per conoscere di persona gli agilisti dello user group di Milano, nonché per scambiare due parole con Francesco Cirillo e seguire il suo seminario e quello di Bruno Bossola del JUG Torino.

La JC in sè, sinceramente mi ha un po’ deluso. Soprattutto per gli interventi più “ufficiali” nella sessione plenaria del mattino, dove ha parlato tra gli altri anche Gosling (inventore di Java). Il titolo della Conference era “Web 2.0: Il futuro di Internet, Il futuro del Software“, ma se vi aspettavate interventi su Ajax, o su come Java pensa di “reagire” all’avanzata dei linguaggi di scripting, sareste rimasti delusi. Solo un intervento infatti ha affrontato il tema delle comunità ed il tema del social.

Detto questo il pomeriggio con le sessioni parallele è stato più interessante.

Read the rest of this entry »

Dopo aver preparato un ambiente sulla mia macchina per programmare in Ruby, finalmente ho cominciato a scrivere le mie prime righe di codice per puro diletto.

Ho pensato di cominciare verificando come se la cava Ruby con un task che in Java è sempre stato eccessivamente pedante: la navigazione di un xml. Riporto qui sotto l’xml di test utilizzato: Read the rest of this entry »

XP consiglia, per il valore della semplicità e rispettando il principio dei piccoli passi e del mutuo beneficio, di costruire i framework lasciando che emergano come pattern applicativi e non a-priori. Così è nato Spring, e così è emerso RubyOnRails.

Ma se ci fosse la necessità di costruire parti del framework senza avere ancora un'applicazione che le utilizzi? MichaelFeathers suggerisce di procedere anche in questo caso con un approccio ("double") Test Driven: farsi guidare dai test a livello di framework e contemporaneamente costruire Test Driven anche applicazioni di esempio che permettano di stressare la testabilità di un'applicazione che si appoggi al framework stesso:

It's not enough to write tests for an API you develop, you have to write unit tests for code that uses your API.

When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently.

So… develop the API and, at the same time, develop example applications and demos that use the API test-first, and then feed that learning back into the API as you go.

In sostanza, un client(e) è sempre indispensabile: quando non ne avete uno…inventatevelo!

Questo post doveva essere una risposta al commento di Tom al post precedente, ma vista la sua lunghezza ho preferito renderlo indipendente.

Hei, non tirarti indietro !

Non far parlare il profeta al posto tuo.:)

…ops mi hai beccato.

Il discorso è tutt'altro che banale. Personalmente credo che le metodologie agili migliorino la produttività, intesa soprattutto come ritorno economico del committente e come accorciamento dei tempi con i quali il fornitore è in grado di andare in produzione con qualcosa di valore. Pensiamo ad esempio alle iterazioni brevi per dirne una soltanto. Inoltre uno dei punti cardine delle metodologie agili è proprio il voler eliminare tutto ciò che è utile a solo una delle parti in gioco (ad esempio a chi giova scrivere una montagna di documentazione interna, o quali vantaggi porta al committente pagare ed aspettare due mesi un documento di analisi super-dettagliato che copre un anno intero di sviluppo stimato?).

Ritengo però allo stesso modo pericoloso mettere al centro del processo di sviluppo il valore della velocità. Questo valore infatti porta a molte malattie, tra le quali ad esempio la bassa qualità (=bassa velocità a medio-lungo termine), una relazione tra committente e fornitore non schietta ma volta a nascondere la realtà, il voler sviluppare senza cercare il feedback dall'utente, a diminuire la comunicazione all'interno del team ecc. ecc. Tutto questo paradossalmente abbassa la velocità.

L'agilità pone al centro del processo i test, e questo ovviamente non è casuale: si sa da tempo che la fase più costosa dell'intero processo di sviluppo è la fase di manutenzione, che spesso fa rima anche con estensione. Porre al centro del processo i test, e farsi guidare da essi, riduce fortemente il costo di quella fase. Non solo: abbiamo tutti avuto esperienza di quanto sia difficile far evolvere un'applicazione mal scritta già dopo un mese o due dalla sua nascita se si sottovaluta l'importanza della qualità del design.

Entra qui in gioco dalla finestra la scelta del tool / linguaggio da utilizzare. Credo che tutti i programmatori Java si guardino ormai intorno per trovare qualcosa che sia più produttivo, e permetta di costruire cose ormai ritenute semplici, in un tempo ragionevole. I javisti più convinti guardano a Trails, altri ad APEX, altri a Ruby on Rails. Credo comunque (soprattutto dopo l'ultimo progetto che sto sviluppando ) che una delle caratteristiche più importanti di un tool/linguaggio sia la sua intriseca testabilità. Se per avere questa testabilità devo rinunciare ad un po' di produttività per le cose semplici, pazienza. Al contrario non avrebbe senso se la rinuncia alla produttivà avesse un peso molto grande, per il tipo di applicazione da sviluppare.
E' questo il motivo per il quale personalmente sono ben impressionato da RoR: grande testabilità e alta produttività.

Personalmente tengo gli occhi ben aperti sulle scelte che faccio (siano di tool o siano di natura meno tecnica), chiedendomi sempre se in fondo non mi stia guidando il falso valore della "comodità", cioè il voler evitare quella "due dilligence" (dovuta cura) di cui parla Martin, cioè quel duro lavoro quotidiano, e quell'attenzione che pratiche come TDD richiedono. E' facile confondere (forse perché il confine è sottile) la ricerca della produttività con la ricerca di una soluzione di comodo che renda il lavoro meno brain intensive. Meglio dare l'impressione di essere un po' più lenti, ma sapendo cosa si sta rilasciando: "rilasciare una feature che non funziona è molto peggio di una che non c'è". Non solo: una feature in produzione che non funziona diventa una palla al piede di tutto il processo di sviluppo, rallentandolo inevitabilmente.

L'importante è avere principi e valori efficaci che ci guidano nelle scelte, è chiaro poi che lo stesso paradigma "sperimenta ed adatta" ed il principio del mutuo beneficio, prevedano scelte che spesso devono vedersela con dei trade-off.

Vorrei riportare in modo più chiaro e visibile quanto già scritto da un commento di Tom, e dalla mia risposta, riguardo una recente critica agli agilisti ed all'agilità mossa da Cedric, nonché della risposta data da Robert Martin quest'oggi a tale critica.

Ritengo entrambi i post degni di una lettura.

Venerdì sera dopo aver postato i miei ultimi mini-articoli sul mio blog, li ho segnalati alla lista di discussione xp-it.

Sabato mattina con molto piacere ho trovato nella posta da leggere una mail di Gabriele Lana, coordinatore dell'XP User Group Milano, fondato da Francesco Cirillo. Gabriele oltre a fare i complimenti a me e a tutta la community, ha proposto una collaborazione tra la nostra piccola comunità e la loro (più ampia), sostanzialmente in tre possibili modalità:

• Il vostro gruppo potrebbe partecipare ai nostri incotri (sarebbe meraviglioso) [due mercoledì al mese]
• Il vostro gruppo potrebbe "saltuariamente" venire a trovarci, e in quelle occasioni potremmo metterci d'accordo per organizzare qualcosa di particolare
• Potremmo collaborare a distanza, potreste partecipare alla nostra lista, potresti creare un feed aggregato dei vostri blog (solo titolo/link) da forwardare in lista, ecc…

Ovviamente ciò non poteva che farmi piacere, fermo restando che personalmente non mi è facile andare a Milano così spesso. Per questo motivo ho proposto una collaborazione assidua a distanza (ad esempio tramite la loro mailing list ed i nostri blog), cercando di cogliere allo stesso tempo le occasioni "particolari" delle quali si potrebbe approfittare per incontrarsi tutti insieme.

La prima di queste sarà la Java Conference 2006 che si terrà il 27 ed il 28 Giugno a Milano, alla quale mi sono già iscritto per il 27 Giugno (il mio CEO ancora non lo sa ), e alla quale spero non sarò l'unico nostro rappresentante. Interverranno tra gli altri anche James Gosling e Francesco Cirillo, quindi anche per questo motivo penso sarà molto interessante.

Spero e credo fortemente possa essere l'inizio di una collaborazione proficua per entrambi i gruppi, soprattutto per le persone davvero molto valide che compongono l'xpug milanese.

Complimenti a tutta la community!

Ho sentito parlare più volte dell’importanza delle condivisione dei valori all’interno di un team. Fino a qualche giorno fa non ne avevo avuto esperienza diretta all’interno del team di sviluppo, e soprattutto non l’avevo vissuta sulla mia pelle. Negli ultimi due giorni ho invece avuto la fortuna di sperimentarlo, grazie ad una pratica che mi ha permesso di confrontarmi in modo molto stretto con il mio collega sviluppatore: il pair programming. Read the rest of this entry »

E' ormai un mese scarso da quando ho cominciato a lavorare ad un nuovo progetto. Si tratta sostanzialmente di un progetto di integrazione, che coinvolge tre sistemi: SAP, Microsoft Access e un applicativo legacy in Visual Basic che legge dai database Access.

Ciò che dobbiamo fare io ed il mio collega è di portare dei dati da SAP (struttura IDOC) ad un database Access, così da rendere automatica l'allineamento dei dati da SAP all'applicativo che li visualizza e che viene utilizzato per produrre della reportistica.

Lo strumento che utilizziamo per fare integrazione dei dati è BIS di Seeburgher. Il progetto si è da subito rivelato "interessante" per vari motivi:

• non so nulla nè ho mai avuto esperienza di BIS
• conosco molto poco o nulla di SAP
• non ho mai utilizzato Microsoft Access
• non conosco nulla del dominio

Forse mi sono trovato per la prima volta nella situazione tipica in cui si trovano (molti) manager quando devono presentare un'offerta (ovviamente time/material) al committente.

Ovviamente i propositi di inizio progetto sono per me i soliti, che ormai conoscete:

• coinvolgere in ogni fase dello sviluppo il committente/l'esperto di dominio
• pianificare ogni settimana
• iterazioni brevi con funzionalità pronte per il deploy
• grande attenzione ai test

Immediatamente mi sono reso conto che in questo progetto, questi propositi erano tutt'altro che facili da raggiungere. Ad esempio le pianificazioni: come stimare qualcosa che non si conosce nè nel cosa nè nel come?

Le prime due settimane sono trascorse cominciando a prendere confidenza con gli strumenti, effettuando piccole prove su dati comunque "reali". La collaborazione è stata molto sul piano tecnico con chi conosce gli strumenti e poco/nulla sul piano del dominio. Il committente reale non è stato coinvolto nelle pianificazioni: quale credibilità avremmo avuto nei confronti del cliente se avessimo fatto e comunicato delle stime praticamente casuali?

Ad oggi invece siamo riusciti ad introdurre una approccio iterativo con il cliente, reintroducendo le tanto care carte, e la nostra lavagna (anche se un po' anomala). La cosa interessante che ho notato è stata che ho ripreso a sentire l'esigenza delle carte solo dal momento in cui ero in grado di effettuare delle stime e quindi di pianificare. Le carte hanno cercato me quando mi hanno visto pronto, non viceversa: non ho dovuto forzare nulla. Allo stesso modo per il planning game e l'introduzione dei business test (non ancora automatici) definiti dall'esperto di dominio per guidarci nell'iterazione corrente.
Questo mi fa pensare a tre cose:

• è importante tenere sempre le orecchie aperte per sentire quando una pratica può rivelarsi utile e praticabile
• è importante avere interiorizzato valori e principi per farsi trovare pronti quando le pratiche chiamano
• in alcuni progetti, soprattutto quando vi sono le condizioni su elencate, può essere necessaria una specie di iterazione zero, nella quale si affrontano più problemi tecnici che problemi di dominio

Per quanto il progetto in sè sia tutt'altro che stimolante, tuttavia come sempre nell'informatica (e non solo) la quantità di cose che si imparano non dipende solo dalle situazioni nelle quali ci si viene a trovare, ma anche e soprattutto dalle capacità di riflessione e di osservazione di chi le vive, oltre che da come le si interpretano e da come si decide di re-agire ad esse.

Da qualche tempo - come avrete notato dalla mia sezione del.icio.us - sto studiando a tempo perso una argomento molto interessante: i domain specific languages. Nei prossimi post vorrei parlarne con voi. Inizio con un brevissimo post giusto per rompere il ghiaccio.

Per farla breve, i dsl sono linguaggi di programmazione creati specificamente per descrivere un particolare dominio, e che possono anche non essere Turing-completi. Per fare un esempio banale, il seguente file di configurazione è un dsl (detto esterno):

TransazioneAttivita.View = Attivita TransazioneAttivita.IdAttivita.UI.Update = False TransazioneAttivita.TipoAttivita.UI.Update = True TransazioneAttivita.Indirizzo.UI.Update = True

Questo semplice linguaggio è costruito appositamente per descrivere le caratteristiche di transazione applicativa, in particolare sono mostrati quali sono i campi su cui è possibile fare l'update per l'oggetto di dominio Attivita. E' chiaro che con questo specifico linguaggio non sarà possibile descrivere nient'altro che non riguardi alcune proprietà di una transazione.

Fin qui solo limiti. Ciò che però rende questo linguaggio di "valore" è il fatto che chiunque non sia un programmatore, ma che sappia che cosa è un'attività programmata, può modificare a suo piacimento la transazione di modifica delle attività programmate. Sottovalutare questo aspetto vorrebbe dire non avere compreso quanto sia importante la comunicazione tra esperti di dominio e sviluppatori.

La cosa interessante è che se avessimo dovuto descrivere le stesse proprietà della transazione di attività programmate in Java, tale descrizione sarebbe stata fruibile solo da uno sviluppatore che conosce Java.

La domanda quindi è: più un linguaggio di programmazione è espressivo e più ristretta è la comprensione dai non addetti ai lavori? O la relazione è tra astrazione del linguaggio e comunicazione?

Ai prossimi post la risposta.