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.

Tom negli ultimi due post ha affrontato un argomento molto interessante, e cioè l'evoluzione dei linguaggi di programmazione soprattutto in ambito Web dal punto di vista della produttività e della reale utilità. Con questo mio post vorrei continuare questa stimolante discussione.

In questo video il grande Ward Cunningham (per chi non lo conoscesse, l'inventore del Wiki, nonchè una delle menti dell'eXtreme Programming, e inventore di FIT), parla del rapporto tra computer e uomo, dei linguaggi di programmazione, e di molte altre cose interessanti. Di seguito un breve riassunto dell'intervista e un mio breve commento.

Innanzitutto Cunningham esordisce dicendo che ha imparato nella sua vita più di duecento linguaggi di programmazione. Molti li considera pessimi, perché chi li ha disegnati aveva come obiettivo quello di implementare funzioni matematiche, senza concentrarsi sui costrutti del linguaggio in sè. Da questa affermazione Cunningham entra nel cuore dell'intervista, affermanso che la cosa fondamentale di un linguaggio di programmazione è la sua capacità di definire e di avere al suo interno concetti, e che questi concetti abbiano un confine che li delimiti, che gli si possa inviare messaggi per poterli interrogare. E' importante che io programmatore possa stabilire, indicare, qual è l'idea più importante tra quelle che sto modellando, e che possa dire che gli altri sono concetti secondari. A questo riguardo Cunningham afferma che da quando ha conosciuto Smalltalk, ha smesso di imparare altri linguaggi. Infatti nella programmazione ad oggetti, ogni oggetto diventa un linguaggio, ed io programmatore divento un language designer definendo questi concetti. Il computer in questo modo mi insegna quali sono i concetti principali che devo conoscere di un certo argomento, costruendo un linguaggio che lo descriva. Il computer quindi ci fa conoscere cose del nostro mondo che prima non conoscevamo. Un linguaggio di programmazione diventa così un ponte, uno strumento verso la conoscenza del mondo che stiamo modellando, nonché uno strumento per l'interazione tra essere umani.

Quest'ultimo aspetto secondo me è la cosa fondamentale di un tool o di un linguaggio di programmazione, o comunque di qualsiasi cosa riguardi un computer: la sua capacità di sapere rappresentare concetti, conoscenza, in maniera chiara, precisa, "delimitata da confini", contestualizzata, e la capacità di poterci ragionare sopra permettendoci di concentrarci sulle idee stesse, senza tecnicismi che offuscano i concetti. Strumenti che permettano di reagire con il minimo sforzo possibile al dinamismo della conoscenza, al naturale evolvere della stessa, che permettano di imparare e conoscere più di quanto sappia o di quanto possa conoscere se non li informatizzassi. Tutto ciò ovviamente coinvolge la comunicazione tra essere umani ed è qui che un tool o un linguaggio si differenziano nella loro bontà, a livello di conoscenza e espressività: quanto migliorano la comunicazione tra le persone? Ad esempio l'assembler molto poco! C molto poco ma già meglio! Altri linguaggi ad alto livello forse meglio ancora. A questo aspetto se ne aggiunge un altro, e cioè che ogni linguaggio deve essere in grado di supportare il naturale dinamismo del processo di comprensione e di knowledge crunching in modo iterativo e graduale. E' qui che diventa importante la capacità di un linguaggio o di un tool di garantire flessiblità, testabilità, robustezza e chiarezza.