No, é vero, non c’é bisogno di un post, ma penso che il problema sia profondo e debba essere analizzato meglio. Come tutti i sabati sono andato a prendere del sushi d’asporto, come tutti i sabati mentre aspettavo mi sono letto gli ultimi tweet, fra le mille cose questo post di Massimo Sgrelli ha catturato la mia attenzione, l’ho letto accuratamente e mi é partito il rant

Premesso che non conosco Massimo (male, mi piacerebbe conoscerlo), premesso che gli faccio comunque i complimenti per l’iniziativa (parlare é facile, fare lo é decisamente meno), premesso che la digestione del sushi non aiuterà le mie capacità cerebrali, devo dire che non concordo per niente con quello che ha scritto, ma proprio per niente

[...] mi accorgo che anche da noi alcuni paladini visionari del mondo che sta arrivando sono impegnati anima e corpo nella creazione di strutture in grado di coltivare e diffondere la cultura delle startup: Riccardo Donadon, Luigi Capello, Francesco Inguscio, Emil Abirascid e tanti altri ancora. Ognuno di loro sta sperimentando modi diversi per far maturare il nostro tessuto imprenditoriale giovanile nella convinzione che il prossimo Skype possa nascere e diffondersi a partire anche dall’Italia

Stiamo scherzando? Ma quale Skype? Ma quale Facebook? Ma quale Twitter? Qui non ci sono le risorse per fare bene neanche il sito del mio salumiere!?!?! Faccio notare che tutti questi signori hanno un modello di business a perdere, nel senso che per anni bruciano quantità inimmaginabili di denaro sia per acquisire che per mantenere un numero sempre maggiore di utenti per il semplice fatto che milioni di utenti hanno un valore a se stante, un valore che prescinde dal servizio erogato.

Questi dovrebbero essere proprio gli esempi da evitare, per tre ragioni:

• In Italia quel tipo di soldi per queste cose non ci sono e non ci saranno (sicuramente non nei prossimi anni), e anche se ci fossero prego tutti gli Dei degli uomini che non vengano utilizzati per questo. In Italia abbiamo bisogno di successi, tanti successi, abbiamo bisogno di dimostrare che investire in questo settore può essere una concreta forma di guadagno. Dirò di più, anche un grande successo isolato non sarebbe utile, per dare fiducia serve continuità e metodo, di SuperEnalotto ne abbiamo già uno e ci basta
• Se di soldi da investire ce ne sono pochi, e penso che su questo siamo tutti d’accordo, logicamente scegliereste tanti piccoli investimenti in business concreti portati avanti da persone che hanno alle spalle anni di successi professionali, o in pochi e grossi investimenti in idee “geniali” dove se ti va bene fai il botto? Ripeto, già ce l’abbiamo il SuperEnalotto
• Questi business sono parassitari, lo scopo é quello di accumulare utenti per poi venderli (sto parlando dei loro dati ovviamente) al miglior offerente. Insomma fuffa che verrà usata per vendere altra fuffa, ecc…, come ho già detto più volte non sono un economista, ma il mondo non può campare di social network, il mondo non può vivere di veline, ci vuole quello che zappa la terra e tira fuori le patate (ops… velina… patata, giuro che non era intenzionale), questa é l’economia del nulla, é l’economia del cravattato duepuntozero. Possiamo andare oltre ed investire in business che creano valore per chi li usa?

Io mio rendo conto che la differenza maggiore tra noi e gli USA sta nel fatto che il processo di maturazione del talento imprenditoriale e l’ingresso nel mondo del lavoro dall’altra parte dell’oceano inizia molto prima che da noi. A 22 anni le persone sono già da qualche tempo in campo, il riscaldamento è ormai fatto ed i muscoli sono già ben visibili. Le persone a quell’età hanno già il fiato e la determinazione sufficiente a reggere l’intera partita e forse anche i supplementari. Allora mi chiedo se non ci sia un modo per affiancare al lavoro che i vari incubatori stanno facendo un modello diverso di “training” dei talenti, una palestra sul mondo del lavoro che li prepari a cambiare il sistema con la forza e determinazione dei big. Prendere i giovani 24 o 25-enni non è forse sufficiente, perché la loro vena creativa e forse anche di incoscienza è in fase troppo avanzata e si è quasi tutta consumata nelle aule dell’università

Ho i brividi ovunque e giuro che il sushi non c’entra. Penso che in Italia le risorse siano poche, non c’é spazio per il prossimo social network, ne per i mash-up dei social network già esistenti :-). Penso che in Italia ci sia bisogno di successi rapidi e concreti, di progetti con modelli di business win/win == l’utente paga X perché tu gli fai guadagnare/risparmiare Y dove Y >> X. Penso che in Italia i 19-enni buttati allo sbaraglio nel mondo dell’informatica abbiano fatto sufficienti danni (mi ci metto dentro anch’io), non abbiamo bisogno di altri 19-enni, abbiamo bisogno che quei pochi 30/40-enni che sono restati si mettano insieme e dimostrino che l’eccellenza fa la differenza, abbiamo bisogno che quei pochi 30/40-enni che sono restati passino la loro conoscenza a quei 19-enni la cui unica colpa é quella di non sapere di non sapere. Penso che in Italia non ci sia assolutamente bisogno di creatività, non c’è bisogno d’inventarsi cose nuove, basterebbe fare bene le migliaia di servizi che ad oggi sono implementati in maniera oscena, quelle stessi servizi che invece di creare valore sono dei debiti senza fine.

Insomma, l’Italia non é la Silicon Valley e fin qui ci siamo, quello che volevo dire é che sarebbe un errore gravissimo tentare di diventarlo, non ci sono neanche lontanamente i presupposti minimi, possiamo fare cose meravigliose ma dobbiamo partire da quello che abbiamo e dobbiamo sfruttarlo al massimo, vedetela così, costruireste un palazzo di 40 piani su delle fondamenta di legno marcio?

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

Parto quotanto la parte incriminata

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?)

Premettendo che ognuno può fare quello che vuole (ammesso che ne paghi direttamente le conseguenze), sarebbe meglio che lo facesse sapendo quello che sta facendo e perchè lo fa. Quello che ho notato è che chi ha adottato le Kanban Board lo ha fatto senza porsi delle domande fondamentali: qual’è l’oggetto della limitazione? Qual’è la misura del miglioramento? Come misuro la capacità produttiva del mio sistema? Ecc…

Ok lo ammetto, è una mia supposizione il fatto che la maggior parte non si ponga queste domande. Questa supposizione derivata dal fatto che mi sembra applicata troppo “by the book”, dove il “book” non riguarda affatto la produzione del software ma una catena produttiva manifatturiera.

Le Kanban Board nel mondo del software generalmente sono divise per fasi e la limitazione è applicata appunto su queste fasi, perchè? Partendo dal presupposto che lo scopo è quello di stabilizzare e velocizzare il flusso delle user story nelle varie fasi, stiamo dicendo che è possibile “dimensionare” ogni fase a piacere? Quindi, per esempio, chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente, altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1

Sempre a proposito delle fasi, negli impianti manifatturieri il fatto che ogni fase sia limitata è una coseguenza banale del fatto che le linee produttive sono per loro natura limitate, ma vale la stessa cosa nel software? Nel nostro team siamo in 5, non possiamo essere nella fase di test tutti e 5? O non possiamo fare deploy tutti e 5? Perchè? A meno che non ci siano 3 analisti che si occupano della fase di analisi, 5 sviluppatori che si occupano della fase di sviluppo, 2 persone che si occupano dei test, ecc… Allora sarebbe un’altra storia, ma trattare il team a dipartimenti specializzati e ridimensionabili a piacere è quello che vogliamo? Personalmente mi fa venire la nausea, ma basta esserne consapevoli

Domanda ancora più importante: il total flow in questo caso come lo si immagina? O meglio, qualcuno misura il Lead Time? Domanda lecita visto che non ne sento molto parlare, almeno non tanto quanto sento parlare di Kanban Board, e visto che la riduzione del Lead Time dovrebbe essere l’obiettivo finale…

Insomma, non vorrei che il seguire una moda possa fare più male che bene, sopratutto quando non ci si prende la briga di studiarla, di comprenderne il funzionamento e sopratutto senza domandarsi come misurare il miglioramento secondo i propri obiettivi. In particolare l’applicazione classica per fasi mi sembra pericolosa da questo punto di vista e suggerivo un’alternativa che mi sembrava meno rischiosa. Dato che l’approccio è di tipo sistemico, una volta messa in campo una Kanban Board “storta” si corre il rischio di stortare tutto :-)

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 :-)

Vorrei costruire una casa fatta esattamente in questo modo. Quanto ci metti a costruirmela? Quanto mi costerebbe?

Il costruttore stoicamente risponde

Tre mesi e 100.000 euro

L’uomo, guarda il costruttore con uno sguardo diretto… semplice… come se stesse parlando delle condizioni metereologiche

Ti do una settimana e 5.000 euro

Il costruttore rimane sbigottito… non sa se lo stanno prendendo per il culo o se fanno sul serio: se lo stanno prendendo per il culo è il momento d’incazzarsi, se fanno sul serio è il momento di mettersi a piangere; decide in buona fede di cercare di capire meglio

Scusami, ammesso e non concesso che umanamente sia possibile farlo in una settimana, significherebbe utilizzare molte più risorse di quelle spese per farcela in tre mesi… quindi al limite ti costerà di più di 100.000 euro, perchè dovrebbero bastarne 5.000???

L’uomo, sempre con la stessa faccia risponde

Accidenti, ma quanto vorresti guadagnare in una settimana?!?!?!

… Ve lo dico io, non c’è dubbio, ci stanno prendendo per il culo

A questo proposito faccio un appello a chiunque può essere interessato, secondo me c’è (e crescerà sempre di più) un oceano blu, ovvero un mercato di opportunità non ancora esplorato, che è quello del “Procuratore per sviluppatori”

Il procuratore dovrebbe trovare il cliente (anche se non è necessario, potrebbe trovarlo direttamente lo sviluppatore) e trattare gli aspetti economici e burocratici del progetto per conto dello sviluppatore, in cambio il procuratore si becca il 20% del fatturato, gli aspetti tecnici vengono gestiti direttamente dallo sviluppatore, esattamente come succede per i calciatori/sportivi (anche se ammetto di non saperne molto ;-P)

Ci sono molti dettagli che devono essere definiti, ma potrebbe funzionare, da gennaio/febbraio sto lavorando in questo modo e sono abbastanza soddisfatto, se qualcuno è interessato, mi contatti direttamente :-)

Il desiderio di controllo nasce dalla paura di non averlo

Da cui una metrica molto semplice da misurare per colui che si definisce professionista

Tutte le volte che un cliente ti chiede a che punto sei in merito ad un lavoro che stai facendo per lui, hai perso 10 punti. Se non rispondi in tempo reale, hai perso 1000 punti

Inutile dire che perdere punti è molto più semplice che guadagnarli… Quello che penso è che il “command & control” non lo voglia spontaneamente nessuno, neanche il cliente, ci si arriva quando costretti, sopratutto per la mentalità italiana dove il 90% della popolazione vorrebbe fare “l’intermediario” nullafacente

Analizziamo il processo mentale del cliente

• Gli ho chiesto di fare questa “piccola” cosa due giorni fa e non ho più saputo niente, cosa starà facendo? Starà lavorando? E’ una cosa importante, deve essere pronta per questa sera… Forse è meglio lasciarlo lavorare, fra poco si farà sentire…
• Sono le 16:00 e non si è ancora sentito nessuno… eh no, adesso basta, gli faccio il culo, non è possibile, aveva detto che avrebbe consegnato prima di sera e sono due giorni che non si fa sentire, gli mando una e-mail
• Non risponde neanche alle e-mail!!! Lo sapevo, non ha fatto niente!!! Per questa sera non sarà pronto niente e sarò nella merda!!! La prossima volta non ci casco più!!!

Ora, poco importa se il nostro “professionista” era in meditazione per riuscire a finire in tempo, poco importa se effettivamente la consegna è avvenuta in tempo, l’ansia e il dubbio sono comunque entrati nella mente del cliente che vorrà avere sempre più “controllo”, anche se la sua forma di “controllo” sarà letale per il progetto :-)

Ogni volta che un vostro cliente vi chiede informazioni su qualcosa, lo fa perchè si sente obbligato a farlo, se potesse eviterebbe, confrontatevi immediatamente con lui per capire come fornigli in anticipo le risposte ai suoi dubbi, siate veri professionisti, non ve ne pentirete

L’atmosfera e il clima sono stati perfetti per un barcamp: bel posto (tra l’altro ero in poltrona in prima fila, l’unica cosa difficile è stata mantenere la lucidità dopo pranzo), bella gente, Luca è stato un ottimo padrone di casa e sopratutto le competenze dei presenti erano molto eterogenee (programmatori, designer e product manager/owner)

Personalmente mi sono giocato la presentazione sui kata della programmazione

La stessa che ho portato al javaday

Se siete interessati al tema vi consiglio di iscrivervi alla ml del milano-xpug e/o a quella del milano-codingdojo, stiamo organizzando alcune attività anche non strettamente legate all’area di Milano :-)

P.S. Alla fine del talk dico di aver seguito la scuola di Martin Fowler del Clean Code, imperdonabile errore, ovviamente stavo parlando di Robert C. Martin :-)

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 ;-))