Uso il termine “cravattato” in tono dispregiativo per identificare quella classe di “colletti bianchi” che si piazza fra chi produce valore, chi lo vende e chi lo finanzia. Questi sono i giocatori principali della partita, in un mercato libero, colto, virtuoso e meritocratico anche il venditore potrebbe essere eliminato (cosa che si sta verificando sempre più spesso nel nostro ambiente), gli altri fanno da supporto.

Il “cravattato” è un ruolo che è stato sapientemente ingegnerizzato nel tempo. Di seguito alcune sue caratteristiche peculiari

• E’ in una posizione di potere ma spesso non ha competenze specifiche, vedi il principio di Peter
• Comanda, ma trova sempre chi è responsabile al posto suo
• E’ ammaestratore della burocrazia aziendale
• E’ maestro delle cerimonie delle metriche
• E’ un anello forte della catena del nulla

Certo, persone di questo genere se ne trovano ovunque, qual’è il problema? Il mio problema è che nel mondo del software (quello conosco, di quello parlo e quello m’interessa migliorare) sono veramente numerosi

La presenza di cravattati nel mondo del software dipende sicuramente dall’impalpabilità del prodotto e dalla difficoltà nel misurarne il valore nel breve periodo. Il cravattato quindi è nato come un indispensabile tramite fra l’investitore e il programmatore, nel seguito è degenerato inglobando e nascondendo all’investitore i meccanismi di produzione del valore. Devo ammettere che le ragioni storiche della loro proliferazione probabilmente devono essere ricercate in una inadeguatezza e immaturità nella figura dello sviluppatore, ma oggi è la loro presenza uno dei freni nello sviluppo di questa professione, perchè?

Perchè i numeri sono molto più facili da gestire rispetto alle competenze individuali, assemblare un team di professionisti sarebbe, al confronto, assurdamente complesso e probabilmente al di fuori della sua portata. La proprietà fondamentale che deve avere lo sviluppatore è la gestibilità, perchè quello è il lavoro del “cravattato” e quindi lo sviluppatore deve essere:

• Moderatamente competente, possibilmente con competenze mirate in modo che non possa vedere l’inadeguatezza del tutto
• Moderatamente costoso, così da poterne comprare di più diminuendo contemporaneamente il budget (vedi sopra alla voce “maestro delle metriche”)
• Giovane e manipolabile, sopratutto non deve essere conscio del proprio valore, ovvero non deve sapere quello che ho scritto nel post precedente
• Facilmente intercambiabile, così che non possa sfruttare nessuna leva, ne nei confronti del cravattato, ne nei confronti dell’azienda

Ovvero, affinchè il cravattato possa fare bene il suo lavoro il programmatore deve essere mantenuto mediocre. L’eccellenza, qual’ora crescesse spontanea della passione dei pochi, non verrebbe ripagata, strati e strati di cravattati filtrerebbero il flusso di valore prodotto in modo che chi di dovere non sappia mai chi ne è l’artefice.

Tutto questo mi fa incazzare, non solo perchè sono un programmatore, ma anche perchè sono conscio del fatto che buona parte dei soldi che spendo tutti i giorni vengono consumati dai cravattati, ovvero dai parassiti dei flussi di valore.

Tutto questo mi fa incazzare ancora di più perchè da che mondo e mondo l’intermediario dovrebbe prendere una piccola parte della transazione, non il 70-90% (mia valutazione assolutamente spannometrica derivata da esperienze professionali)

Tutto questo mi fa incazzare ancora di più perchè da che mondo e mondo l’intermediario è al servizio degli intermediati, secondo quale logica l’intermediario dovrebbe essere il “capo” di una delle due parti? Secondo quale logica la capacità produttiva dovrebbe essere limitata per favorire l’intermediario?

Concludendo: ben venga la figura dell’intermediario, ben vengano le figure di supporto, ben venga tutto l’aiuto possibile, purchè non ci si dimentichi una cosa: nel mondo della produzione del software l’elemento principale è il programmatore, tutto il resto è eliminabile, che vi piaccia o no :-)

Prendiamo in considerazione l’esempio di una casa automobilistica che chiameremo X e dell’azienda Z fornitrice di tappetini per la automobili prodotte da X. Z è felice di avere un cliente così importante che gli procura tanto lavoro, ma Z è anche preoccupata perchè qual’ora X dovesse decidere di cambiare fornitore si ritroverebbe con una montagna di tappetini che sul mercato non valgono niente

X è molto felice perchè tiene per le palle Z

X: Quanto ti costa produrre un tappetino?
Z: 4,5
X: Bene, te ne do 5 e ringraziami
Z: …ok (pensando: come faccio a piazzare 500.000 tappetini per quel modello d’automobile?)

X sa il fatto suo, tiene in casa solo l’assemblamento delle parti più importanti in modo che i singoli fornitori non possano avere un mercato, ovvero non possano avere acquirenti se non loro o le case automobilistiche che comunque applicherebbero a Z lo stesso tipo di politica e quindi non costituirebbero una valida alternativa

Cosa succederebbe se X avesse un fornitore W in grado di produrre un’intera automobile da zero? Rivediamo la conversazione di cui sopra

X: Quanto ti costa produrre un’automobile?
W: 4.500
X: Bene, te ne do 5.000 e ringraziami
W: AHAHAHAHAHAHAHAHAHAHAHAHAHA (pensando: sul mercato tu le vendi a 65.000, a questo punto mi conviene vendermele da solo le MIE macchine)

Eh si, X si è trasformato in un mero venditore, in questo caso W tiene per le palle X, infatti nessun imprenditore sano di mente farebbe mai una cosa del genere… aspetta un momento però… è esattamente quello che succede nel mondo del software (C.R.A.V.A.T.T.A.T.O? Lo senti vero? Lo senti che il tuo momento si avvicina? Stiamo arrivando baby, stiamo arrivandooo…)

Dopo vent’anni di fallimenti il cravattato si deve arrendere, la produzione industriale del software non funziona, il software lo produce chi lo scrive, non ci sono cazzi, ad oggi lo capirebbe anche una scimmia lobotomizzata, ma perchè c’è voluto così tanto? Semplice, perchè sarebbe come ammettere che i programmatori non sono come Z ma sono come W, una cosa semplicemente inaccettabile

Chiaro, i tempi non sono ancora maturi, per due ragioni:

• Il cravattato venderà cara la sua pelle
• Ad oggi di programmatori che hanno una professionalità tale da creare in autonomia un prodotto completo ce ne sono ancora troppo pochi, non abbiamo l’identità e l’orgoglio professionale che la nostra professione si merita, di strada da fare ne abbiamo ancora molta purtroppo

Ma la realtà delle cose è questa, quindi vi faccio una domanda: volete essere tenuti per i coglioni o volete tenere per i coglioni? Il vostro potenziale è infinito, nel ventunesimo secolo l’uomo che sussurra alle macchine è Re

Prima si è iniziato a parlare di Lean, poi qualcuno ha iniziato ad usare e a parlare di Kanban Board, infine adesso Kanban è diventato quasi il nome di una metodologia. Adesso quando uno parla di Kanban non so a cosa pensare:

• Starà parlando di Kanban come sinonimo di Lean? Si ma Lean come sinonimo di Lean Thinking, ovvero la filosofia Lean o Lean Development, ovvero l’applicazione della filosofia Lean allo sviluppo del software?
• Starà parlando di Kanban come sinonimo delle board che adesso vanno tanto di moda negli Agile shop?
• Starà parlando di Kanban come di una non meglio precisata metodologia? Come lo ScrumBan, ovvero uno Scrum che fa uso di Kanban Board o come Kanban, ovvero l’uso delle Kanban Board misto a qualche pratica presa da XP?

Insomma un delirio, la salvezza come al solito sta nella conoscenza: bisogna tornare alle origini della parola, studiarne l’evoluzione per capirne le implicazioni ed un eventuale contesto d’uso

Kanban si traduce in cartellino: I giardini imperiali giapponesi sono curati all’ossessione e sono considerati un patrimonio del giappone, per questo solo poche (supponiamo 100) persone alla volta sono autorizzate ad entrare, per garantirlo vengono usate delle tessere di plastica bianche, ne esistono solo 100, una persona può entrare solo se possiede una di queste tessere che possono essere prelevate da un contenitore all’ingresso, quando il contenitore è vuoto nessuno può entrare, quando una persona esce deposita la sua tessera che verrà automaticamente trasferita nel contenitore all’ingresso consentendo a qualcuno di prelevarla ed entrare. Le tessere di plastica sono Kanban

Quindi i Kanban sono la rappresentazione sistemica del vincolo sulla capacità produttiva dell’impianto. Cosa significa quesa frase e come può tornare utile allo sviluppo del software lo spiego subito

L’applicazione del pensiero Lean porta ad eliminare una classe di problemi e/o di sprechi nell’attività produttiva attraverso un approccio sistemico ovvero creando un ambiente di lavoro che rende difficile commettere errori. Un esempio tipico sono i connettori la cui forma impedisce fisicamente di sbagliare verso. Un altro bell’esempio ce lo forniscono gli ospedali in cui si applica il pensiero Lean, nei quali tutte le attrezzature hanno un posto dedicato che solitamente viene marcato con un’immagine stilizzata del tipo di attrezzo che dovrebbe occupare quello spazio, in questo modo

• E’ molto semplice accorgersi se uno strumento è fuori posto perchè ci sarebbe l’immagine dello strumento senza lo strumento stesso
• Nei momenti d’emergenza non devi metterti a pensare dove si trova uno strumento perchè sta sempre nello stesso posto
• L’ordine non è più una questione di gusto personale :-)
• Essendo la distribuzione degli strumenti così rigorosa è possibile fare esperimenti per capire se un’eventuale riorganizzazione (che è quasi sempre microscopica seguendo il principio del Kayzen) produce un miglioramento o meno

Quando si ha a che fare con dei sistemi complessi è molto più efficiente ed efficace applicare un controllo indiretto invece che tentare di forzare le singole parti al proprio volere, basta pensare all’acqua, le singole particelle costituiscono un sistema complesso con proprietà emergenti, come fai a trasportare l’acqua? tenti di convincere le singole particelle? La sposti fisicamente? O crei un canale e lasci che felicemente scorra seguendo le proprie leggi ma finendo esattamente dove vogliamo Quest’ultimo può essere definito un approccio sistemico

Ahhhh se solo la maggior parte dei manager sapesse… il mondo girerebbe diversamente, ma la resa dei conti arriverà presto caro cravattato dall’ignoranza bovina… ma sto divagando

Le Kanban Board creano un ambiente di lavoro dove è difficile commettere una serie di errori classici della produzione: avere molte user stories in lavorazione (semilavorati) che non portano valore al sistema, evitare il sovraccarico di lavoro del team, individuare molto velocemente eventuali parti critiche dello sviluppo di una user story, ecc… Bene, ma dove sono i Kanban nelle Kanban Board che si usano nella produzione di software? Non sono le carte delle user stories (come banalmente si potrebbe pensare), i kanban rappresentano i limiti della produttività del sistema, in questo caso il limite è sul numero delle user stories che possono essere in lavorazione ovvero i kanban sono i singoli “posti” che possono essere occupati dalle carte delle user stories.

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Concludo dicendo una cosa ovvia: più si studia uno strumento/pratica/tecnica e più è facile utilizzarlo saggiamente nel contesto in cui ci si trova per raggiungere i nostri obiettivi, il pericolo è quello di abusarne o peggio essrne abusati :-)

Una brevissima introduzione: CouchDB è un database documentale, ogni documento (il record di una tabella in un database relazionale) è insieme di coppie chiave/valore, non esiste uno schema dei dati, ogni documento può contenere qualsiasi insieme di coppie chiave/valore, ad ogni database possono essere associati una o più view (query in un database relazione), ogni view è composta da due funzioni javascript, una funzione map che consente di trasformare ogni documento contenuto nel database in un altro insieme di coppie chiave/valore e di associarle ad una chiave, e una funzione reduce (opzionale) che prende in pasto l’output della funzione map precedente raggruppata per chiave (una sorta di group by dei database relazionali) e che può essere utilizzata per computare valori aggregati

Un piccolissimo esempio che è molto vicino al test che ho fatto. Supponiamo di avere un database (ovvero un insieme di documenti) di questo tipo

[
{
"url": "http://salute.corriere.it/news/some-news.html",
"visits": 3
},
{
"url": "http://lavoro.corriere.it/index.html",
"visits": 10
}
]

Ovvero associamo ad ogni url il numero di volte che è stata visitata. Noi vogliamo sapere il numero di visite per ogni “sezione” delle url presenti nel nostro database. Definiamo intuitivamente il significato di “sezione” dicendo che l’url “http://salute.corriere.it/news/some-news.html” appartiene a tre sezioni “corriere.it”, “salute.corriere.it” e “salute.corriere.it/news”. Supponiamo di avere a disposizione una funzione “forEachSectionOf(url,doSomething)” che prede in pasto una url e richiama la funzione doSomething per ogni sezione dell’url passandogli la sezione stessa come parametro. La nostra funzione map sarebbe una cosa del tipo

function(doc) {
forEachSectionOf(doc['url'], function(section) {
emit(section, doc['visits'])
});
}

La funzione emit viene chiamata tutte le volte che vi vuole produrre un output, il primo parametro è la chiave del risultato e il secondo è il valore (sia la chiave che il valore possono essere strutture dati complesse, non devono essere per forza valori come in questo caso, ma questa è un’altra storia). L’output prodotto dalla map applicata al database di cui sopra sarà

[
{ "corriere.it": 3 },
{ "salute.corriere.it": 3 },
{ "salute.corriere.it/news": 3 },
{ "corriere.it": 10 },
{ "lavoro.corriere.it": 10 }
]

Abbiamo detto che l’imput alla reduce è l’output della map raggruppato per chiave, quindi

[
{ "corriere.it": [ 3, 10 ] },
{ “salute.corriere.it”: [ 3 ] },
{ “salute.corriere.it/news”: [ 3 ] },
{ “lavoro.corriere.it”: [ 10 ] }
]

Ricordandoci che vogliamo calcolare il numero di visite per ogni sezione, la reduce è molto semplice

function(keys, values, rereduce) {
return sum(values)
}

Che produce il risultato atteso

[
{ "corriere.it": 13 },
{ "salute.corriere.it": 3 },
{ "salute.corriere.it/news": 3 },
{ "lavoro.corriere.it": 10 }
]

Il grosso vantaggio di CouchDB in termini di perfomance è che le view vengono calcolate in maniera incrementale, ovvero tutte le volte che interroghi una view CouchDB ricalcola solo i valori relativi ai documenti che sono cambiati o che sono stati aggiunti dall’ultima volta che la stessa view era stata calcolata (la cosa più vicina a questa nel mondo dei database relazionali sono le materialized view di Oracle). Inoltre il costo del calcolo dell’incremento dovrebbe aumentare in maniera logaritmica rispetto all’aumentare della dimensione del database.

Ho voluto toccare con mano e quindi ho fatto il seguente esperimento:

• Fetch di 10000 record da una tabella di mysql contenente 15 milioni di record
• Store di ogni record come documento in CouchDB (i documenti non sono stati salvati singolarmente, ma in modalità batch che è molto più performante)
• Query della view di CouchDB che equivale al ricalcolo della view stessa

Ho misurato ognuna delle tre fasi e l’ho ripetuto fino a consumare tutti e 15 i milioni di record, di seguito i risultati

• Pro: la complessità del ricalcolo della view è effettivamente logaritmico
• Pro: il costo d’inserimento dei documenti in CouchDB è costante (la struttura dati utilizzata è append-only, quindi c’era da aspettarselo, ma fa comunque piacere verificarlo)
• Pro: una volta calcolata la view, i tempi di risposta sono stupefacenti, praticamente istantanei
• Pro: il tempo totale d’inserimento di 15 milioni di documenti è stato di 26 minuti
• Pro: l’occupazione di memoria durante tutto il processo non ha mai superato i 50MB
• Contro: il tempo totale di calcolo della view è stato di circa 17 ore. Bisogna tener conto che le view vengono calcolate da funzioni javascript in un processo separato e che la comunicazione fra CouchDB e l’interprete javascript è stdin/stdout, quindi a parte la velocità dell’interprete javascript (di default spidermonkey) c’è anche un costo notevole di serializzazione/deserializzazione. Scommetto che scrivendo le map/reduce direttamente in Erlang questo numero cambierebbe sensibilmente
• Contro: lo spazio occupato dal database è di 21GB contro i 7.5GB di mysql (anche se ci metterei un bel chissene visto il costo degli storage)
• Contro: lo spazio occupato dalla view è di 32GB (again chissene)
• Contro: per ogni database CouchDB usa uno ed un solo processore, quindi anche se avete 16 processori come nel mio caso, non ve ne fate niente a meno di non avere database multipli. Il modello map/reduce implementato da CouchDB potrebbe tranquillamente consentire il partizionamento dei dati su più database, ma attualmente gli sviluppatori si stanno concentrando solamente sulla replicazione, se volete dovete implementare voi il meccanismo di reduce finale

Conclusione: se vi trovate in una situazione per cui avete una grande quantità di dati e le query che fate non cambiano spesso, un database come CouchDB potrebbe essere un bel passo in avanti rispetto ad un database tradizionale

Joel ha elogiato Jamie Zawinski (uno dei programmatori intervistati da Seibel nel suo libro) per la sua capacità di scrivere velocemente codice funzionante e fruibile da un utente finale. Joel ha chiamato questo tipo di programmatore “Duct Tape Programmer”, un’etichetta che ha suscitato un bel polverone.

Insomma si parla del solito tradeoff “time, quality, money – pick two”, che poi ufficialmente si traduce sempre in “scegliamo tempo e denaro, per la qualità speriamo di farla franca”.

Cosa centra tutto questo con i kata? Quando qualcuno si lamenta del fatto che le tecniche che propongo non sono praticabili nella loro realtà perchè non c’è il tempo (la solita storia del “bello, ma da noi non si può fare”), mi ricordo quando anch’io mi lamentavo della stessa cosa, vedevo la carenza di tempo come la prima ragione di tutti i miei fallimenti, poi però ho iniziato a chiedermi: “se fino ad oggi non ho mai avuto tempo per fare le cose bene, come faccio ad essere sicuro di saperle fare? Come faccio ad essere sicuro di riuscire a scrivere codice pulito se non ho mai avuto il tempo di scriverlo?”… Interessante quesito che ci porta ai kata e alla nozione generale di esercizio

Gli esercizi di programmazione hanno due obiettivi

• Darci la possibilità di lavorare in un ambiente controllato e privo di vincoli. Il fallimento è visto in maniera positiva, venire a conoscenza dei nostri limiti è l’unico modo per poterli superare
• Visto che non avrete mai il tempo che volete, l’unica cosa che potete fare è diventare più veloci nello scrivere codice di qualità

Il secondo punto ci riporta al tema iniziale: dove sta scritto che per scrivere del buon codice serve tanto tempo? Io sono fermamente convinto che l’unica ragione per la quale intuitivamente lo pensiamo è perchè quando ci proviamo facciamo fatica, e l’unica ragione per la quale facciamo fatica è perchè non siamo abituati/allenati.

Ultimamente ho dedicato un po’ di tempo a pensare ai kata e ad esercitarmi, venerdì della settimana scorsa ho partecipato al primo javascript camp italiano organizzato da Ideato e ho presentato il kata “the game of life” in javascript, è stato molto divertente ed istruttivo

Gli ingredienti per un buon kata/esercizio sono

• Un problema sfidante per le vostre capacità e per la vostra preparazione
• Una o più persone pronte a darvi il loro feedback, fondamentale per capire come e dove migliorarsi
• Ripetere l’esercizio più e più volte finchè sentite che ormai il problema non ha più niente da insegnarvi

Il mio consiglio è di provare e di mettervi in gioco, per quanto mi riguarda le prossime mosse saranno: pubblicare gli screencast dei miei kata ed organizzare dei gruppi di esercizio/studio, se siete interessati contattatemi o iscrivetevi milano-codingdojo (non preoccupatevi se non siete di Milano, stiamo organizzandoci per fare qualcosa di distribuito ;-))

L’argomentazione utilizzata per minimizzare l’utilità dei test è la semplicità dell’esercizio, al che ho pensato a come l’avrei risolto in Erlang, mi sono detto che “effettivamente la soluzione è semplice”, ho iniziato a scriverla provandola nella shell del linguaggio e subito ho provato un senso di fastidio

Continuavo a scrivere e riscrivere (va bhe, la shell ti da la possibilità di richiamare i comandi passati, ma il discorso non cambia) le stesse invocazioni verificando ad occhio il risultato, al che ho capito il senso di fastidio: che differenza c’è fra quello che stavo facendo e scrivere dei test unitari? Nessuna, tranne che i primi sono effimeri e non ti possono venire in aiuto quando sarai chiamato a fare refactoring. Quindi, amici dei linguaggi funzionali, perchè non vedete i test unitari come delle sessioni di interazione con la shell permanenti e automatiche?

Vi dirò di più, la soluzione che avevo inizialmente pensato era sbagliata :-) Dopo aver passato tutti i test che Martin aveva fatto nella presentazione di cui sopra, mi sono chiesto se potevo rompere il codice in qualche modo, ho visto che non erano coperti dei corner case, per esempio c’è la partita peggiore (tutti 0), ma non c’è la partita migliore (tutti strike), scrivo un test… e non passa :-)

Come vedete qui sotto, utilizzo una variabile per tenere il conto dei frame elaborati, inizialmente non lo facevo e nel caso di uno strike nell’ultimo frame, i due tiri di bonus successivi metchavano con la terza clausola e venivano considerati dei frame normali, quindi il “perfect game” che dovrebbe avere uno score di 300 aveva score 320

Alla fine ho guardato il codice e quella variabile arbitraria per contare il numero dei frame proprio non mi andava giù e senza cambiare i test sono arrivato a questa seconda soluzione

Che non mi piace perchè anche se rende più esplicito (forse anche più imperativo?) il conto dei frame, secondo me si capisce di meno, sopratutto non mi piace score_frame perchè si occupa sia di calcolare lo score di un frame (e fin qui), sia di selezionare i tiri rimanenti eliminando quelli del frame corrente

Cosa ne dite? Quale vi piace di più?

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. [...] Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. [...] Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Estratto da l’ultimo articolo di Tom DeMarco. Consideriamo anche che DeMarco non è proprio uno di quei “giovani rivoluzionari delle metodologie Agili che non hanno ancora capito niente e che vogliono reinventare la ruota”, è uno dei padri fondatori che si è sparato un po’ tutte le ere geologiche dell’informatica. Il problema è che di solito passa qualche lustro prima che il pensiero degli illuminati diventi di comune dominio… speriamo di esserci quando avverrà :-)

Durante la giornata ho incontrato dei ragazzi di Trieste che mi hanno chiesto qualche consiglio su come iniziare ad introdurre le metodologie Agili nella propria azienda, per le due chiacchiere che abbiamo fatto posso dire che sono sulla strada buona, il fatto stesso che economicamente se la stanno passando bene, che non soffrono più di tanto (la sofferenza è uno dei motori principali del cambiamento) e che nonostante questo abbiano tanta voglia di migliorare, gli fa veramente onore, in bocca al lupo ragazzi!

Nota mentale: Milano capitale dell’IT in Italia… io direi più Milano capitale della consulenza in Italia, incontro sempre più persone che sviluppano prodotti, anche leader di mercato (come i ragazzi di Trieste), che non hanno niente a che fare con Milano

Il giudizio generale sulla conferenza è molto buono sopratutto se consideriamo che: è al suo primo anno e che è stata organizzata gratuitamente dalle community locali in collaborazione con l’università. Nonostante il classico antipattern delle conferenze gratuite (generalmente si presentano molte meno persone rispetto a quelle che si iscrivono), il numerico presente era buono (un centinaio?), gli interventi erano tutti di ottimo livello, unica nota negativa della giornata è stata l’assenza di studenti in una conferenza universitaria… no comment…

Racconto brevemente la storia della presentazione qui sotto: un paio di mesi fa Marco Abis mi chiama e mi chiede se voglio parlare ad una coferenza rappresentando l’Italian Agile Movement, io: “certo perchè no”, vado a vedere di cosa tratta la conferenza… RIA (Ritch Internet Applications), bene, io e Federico stiamo sviluppando proprio quello, chiedo a Federico di scrivere la descrizione (scrive meglio di me), la pubblichiamo, al che però Marco sottolinea il fatto che, come rappresentanza delle metodologie Agili dobbiamo trattare quei temi… ooops, la descrizione era già stata scritta…

Pensandoci sopra poi ho capito che in realtà le tecnologie che abbiamo scelto io e Federico (tecnologie che erano l’oggetto della presentazione che volevamo fare) servivano per sostenere il processo produttivo che avevamo in mente, un processo produttivo fortemente iterativo, incrementale ed adattivo, capace di sopravvivere in un contesto di estrema incertezza come quello di una startup. La conclusione è che non è vero che le tecnologie che scegliamo prescindono dalla metodologia di sviluppo, e non vero che la metodologia che scegliamo prescinde dall’ambiente dal progetto e dal suo ambiente. L’unico modo per ottenere il Total Flow, ovvero l’eliminazione di tutti gli sprechi, è necessario considerare tutti questi aspetti nella loro globalità

I talk m’interessano relativamente, è raro assistere ad un talk che parla di un’argomento di mio interesse all’interno del quale si dicano cose che non ho già letto e/o sentito, chiaramente questo non dipende dalla preparazione dell’oratore ma dal fatto che non può dar per scontato che tutti i presenti conoscano già determinati argomenti. Alcuni tipi di talk però fanno eccezione, per esempio gli experience report mi piacciono molto

Giovedì 07/05/2009, la giornata inizia subito bene, parto con il treno delle 6:30 da Milano con l’iphone pieno di conferenze (quale cosa migliore di andare ad una conferenza guardandosi altre conferenze), direzione: Firenze, scopo: partecipare a bettersoftware. Arrivati a Firenze sto per scendere dal treno e becco Simone Genini, grazie al suo aiuto riesco a raggiungere appena in tempo l’albergo della conferenza (io ho una capacità di perdermi incredibile, talmente incredibile che neanche iphone + google maps mi salvano)

Primo talk (mannaggia a chi ha deciso di far iniziare la conferenza così presto) è stato quello di Antonio Cangiano sul mondo delle startup, lui stesso ne sta facendo partire una e ha condiviso con la platea i suoi pensieri. Sabato (durante pycon3) ho avuto modo di parlare con Antonio, è una persona molto simpatica e socievole, mi ha spiegato le idee che stanno alla base di thinkcode (la sua startup) e devo dire che sarò sicuramente uno dei loro primi clienti (se siete appassionati di programmazione vi consiglio di iscrivervi alla loro ml, se non siete appassionati di programmazione avete sbagliato blog :-))

La giornata è proseguita con i talk di Matteo Vaccari, Francesco Cirillo e Simone Casciaroli (Simone perchè non hai un blog?), tre experience report degni di nota.

Scena madre della giornata: Francesco Cirillo sale sul palco e attacca con la campagna anti-if, dice che ha delle magliette da regalare, ma le regalerà solo a chi dirà qualcosa in grado di colpirlo, al che Jacopo Romei che era seduto di fianco a me si alza e urla “Sei Bellissimoooo!!!”, scoppiano tutti a ridere e lui si becca la maglietta, grande Jacopo, uno ottimo esempio di pensiero creativo :-)

Mi piacerebbe raccontare di più su questo fantastico linguaggio/ambiente, è che mi manca proprio il tempo…