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

My Political Views
I am a centrist social moderate
Left: 0.14, Libertarian: 0.95

Maggior conoscenza acquisiamo sui nostri utenti, maggiori saranno le probabilità che la prossima funzionalità pensata/implementata sarà apprezzata (aumentando il valore dell’applicazione). Minore sarà il tempo/costo d’implementazione di una nuova funzionalità, maggiori saranno le funzionalità che potremmo utilizzare per acquisire conoscenza sui nostri utenti

Cosa possiamo fare per minimizzare i tempi/costi d’implementazione? Chiaramente possiamo intervenire da un punto di vista tecnico migliorando la nostra capacità di produrre software, mantenendo sempre pulita la nostra base di codice, migliorando costantemente gli aspetti di project automation e di autonomation, ecc… insomma avete capito

L’altra cosa che possiamo fare è splittare in maniera creativa ed aggressiva le user story esistenti del prodotto. Prima possiamo iniziare a selezionere un minimo set di user story in grado di dare dignità di prodotto al nostro progetto, poi possiamo iniziare a considerarle singolarmente e a capire cosa possiamo togliere da ogni user story conservando la possibilità di poter utilizzare il risultato come MVP

Un esempio? Avevo 10 giorni (nessuna domanda please sul perchè di questo numero magico…) di tempo per realizzare un’applicativo piuttosto complesso, ovviamente c’era di mezzo uno storage, ovviamente il cliente aveva richiesto un’interfaccia di amministrazione/gestione di questo storage e ovviamente non aveva tralasciato nessun “goodies”: utenti, gruppi, ruoli, permessi, editing, viste configurabili sui dati, ecc… praticamente mi sarebbero serviti molti più giorni di quelli a disposizione solo per questa parte accessoria del sistema. Volevo iniziare dal vero prodotto, ma volevo anche che il cliente lo potesse utilizzare da subito, così ho installato phpMyAdmin e ho fatto vedere al cliente come utilizzarlo: ho creato utenti, viste, maschere, ecc… alla fine il cliente mi ha detto che è esattamente quello che voleva :-D Ok, sono stato fortunato, ma è stata una vera epifania

Un’altro esempio un po’ più creativo? Kent Beck qualche hanno fa ha tenuto un workshop sullo split delle user story usando un esempio alquanto “ardito”: il gioco del tetris… qual’è secondo voi la prima user story per Beck? Una colonna, un quadratino 1×1 che scende a velocià costante, quando un quadratino tocca il fondo parte un altro quadratino, il nuovo fondo è il quadratino precedente, quando il fondo arriva in cima alla colonna “game over” :-D

Ancora una volta una conferma del fatto che il business (il problem team come lo chiama Ries) e la tecnologia (solution team) non si possono/devono ignorare a vicenda

• Pianificazione: identificare le User Story tenendole ad una granularità/indipendenza sufficiente da poter realizzare prima quelle con il più alto valore di business. Inutile dire che la valutazione del valore di business di ogni singola user story è fondamentale
• Esecuzione: migliorare costantemente la velocità di realizzazione delle suddette User Story

L’obiettivo supremo è sempre quello di massimizzare la quantità di valore consegnato nell’unità di tempo e in subordine la capacità di produrne in futuro, il resto sono chiacchere

E’ un concetto estremamente semplice, ma estremamente efficace se dovete introdurre a qualcuno le pratiche proprie delle metodologie Agili. Detto questo però se avete poco tempo a disposizione per catturare l’attenzione di qualcuno, se dovete fare un elevator pitch, vi serve qualcosa di molto immediato, vi servono delle metafore

Negli ultimi due anni ne ho raffinata una per spiegare come funziona la pianificazione e visto che è risultata essere particolarmente efficace la condivido con tutti, la scrivo come la racconto di solito

Supponiamo che dall’altro lato di quella porta (nda. di solito c’è una porta nelle vicinanze :-)) ci sia un team di programmatori che deve iniziare un progetto per il quale sono necessarie determinate conoscenze, queste conoscenze possono essere acquisite attraverso lo studio di alcuni libri, il vostro compito è quello di fornirglieli

Il materiale che vi viene dato consiste in 15m^3 di libri e di uno scatolone di 10m^3, se vi state chiedendo “esiste una metodologia in grado di far entrare 15m^3 di libri in uno scatolone di 10m^3?” la risposta è no! Anche le metodologie Agili non fanno eccezione :-)

Quindi cosa facciamo? Se seguissimo alla lettera i vincoli che ci sono stati dati e se non fossimo abbastanza svegli da misurare i volumi che abbiamo a disposizione, probabilmente spenderemo la maggior parte del nostro tempo a tentare di organizzare i libri per riuscire a farceli stare tutti nello scatolone. Una volta arrivati in prossimità della scadenza ficcheremo il maggior numero possibile di libri all’interno dello scatolone per poi spingerlo finalmente al di là della porta dove ci sono i programmatori che lo aspettano

Evidentemente non è una strategia molto furba… come possiamo migliorarla? Ci chiediamo: “qual’è il reale obiettivo di questo lavoro?” Massimizzare al quantità di conoscenza da passare al team di programmatori che sta al di là della porta, “la quantità di conoscenza erogata è indipendente dal libro?” Ovviamente no, quindi una cosa che possiamo fare è scegliere i 10m^3 di libri in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che la scelta delle user story da implementare è il primo passo verso la massimizzazione del flusso di valore)

Bene, possiamo migliorare? Ci chiediamo “ogni capitolo all’interno di un libro eroga la stessa quantità di conoscenza?” Nella maggior parte dei casi no, sicuramente non erogano conoscenza le copertine cartonate, le prefazioni, i ringraziamenti, ecc… Quindi possiamo procedere con un approcio creativo e stracciare ogni libro tenendo solo i capitoli migliori e quindi scegliere i 10m^3 di materiale in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che splittando le user story possiamo prendere la maggior parte del valore minimizzando il costo)

Ottimo! Possiamo ancora migliorare? Ci chiediamo “chi è che decide la quantità di conoscenza erogata da un testo?” Fino a questo momento siamo stati noi ma effettivamente è un assunto grave, cosa succederebbe se avessimo torto? La nostra strategia sarebbe ancora valida, ma le nostre misurazioni sarebbero pura speculazione, non possiamo essere sicuri di aver realmente erogato la maggior quantità di conoscenza possibile. “chi potrebbe valutare con maggiore accuratezza?” Sicuramente il team di programmatori che sta dietro alla porta

Quindi possiamo essere ancora più creativi e possiamo chiedere di barattare lo scatolone da 10m^3 con 10 scatoloni da 1m^3, nel primo scatolone ci mettiamo quello che noi riteniamo essere il miglior metro cubo di materiale possibile e lo spingiamo fuori dalla porta chiedendo ai programmatori di chiamarci una volta letto tutto. Quando i programmatori ci chiameranno chiederemo il loro feedback sul materiale, sulla base di queste informazioni sceglieremo cosa mettere nel prossimo scatolone. In questo modo non solo avremo una corretta valutazione del valore consegnato, ma abbiamo anche la possibilità di adattarci al contesto del progetto (nda. in questo caso stiamo dicendo che le funzionalità individuate all’inizio del progetto e la stima di valore che ne viene fatta è nella maggior parte dei casi errata e che quindi serve un reale strumento di feedback)

Secondo me funziona bene perchè

• All’inizio non ti aspetti di poter migliorare molto, quando capisci che puoi farlo è una bella sensazione :-)
• I 15m^3 in 10m^3 danno quella sensazione di claustrofobia che tutti hanno provato nei progetti “fixed *” (leggi: dove tutto è prefissato)
• Si capisce chiaramente che il modo per migliorare dipende poco dalla capacità di fare stime “corrette” quando dall’organizzazione del flusso di lavoro e di feedback

Cosa ne pensate? Possiamo ancora migliorare? :-)

• The customer is the most important thing in your business
• The best business plan is to sell people the things they want
• Your business is successfull if your earnings are higher than your spendings

Troppo spesso le startup vengono fondate su una vision di progetto che esiste solo nelle menti degli stessi fondatori, Eric Ries dice sempre nelle sue presentazioni “vision not delusion”, che potrebbe anche essere “vision not illusion”. Il compito principale di una startup è quello di validare/raffinare nel più breve tempo possibile la propria vision di progetto confrontandosi con l’unica fonte di verità: gli utenti

VC: “Interessante la vostra idea, potete mostrarci il vostro business plan?”
Startup: “Inizialmente avevamo questo set di funzionalità, poi abbiamo eliminato queste funzionalità ed abbiamo aggiunto queste altre e siamo passati da X utenti a 3X utenti, a partire da questa informazione abbiamo modificato il nostro posizionamento nel mercato, abbiamo validato queste informazioni passando da 3X utenti a 10X utenti aggiungendo queste altre funzionalità in accordo con quanto avevamo scoperto. Ora ci aspettiamo di raggiungere i 100X utenti, quindi una revenue di Y, togliendo queste funzionalità e aggiungedo queste altre nei prossimi 2 mesi”

Questo è un business plan nel quale metterei dei soldi…

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