Extreme Enthusiasm

I attended for the third year in a row the XP Day Benelux.

Prologue

I arrived on Wednesday 19 early, so I spent the whole afternoon in my cozy hotel room, working on my presentation. I was worried that it would not be a success, and rightly so, as I will explain later.

At about 19:00 I moved downstairs to the hotel pub. Now, northern European are true masters of the art of the Drinking Tavern. The tavern in question was beautiful, comfortable, with huge old tables of solid wood. I had some great Belgian beer (Brigand). I met Olivier, an acquaintance from last year edition, a really nice guy to talk with. Later I met Pascal, Vera, Portia and some more people I didn’t know before. We had a nice dinner at the hotel.

The next day, I was still in a hurry about my slides. Had them printed at the hotel (well organized!) Then I presented my talk at the Official Half Minute Presentation (ohmp), where presenters have a half minute each to entice people to come to their session.

Responsibility-driven Design with Mocking

I attended first Marc, Willem and Rob‘s presentation on interaction-based testing. I was a bit disappointed that there was little interaction in this session; I was hoping for some hands-on training, because I always end up with some new insight then. It was basically a demo of the ideas in the excellent Mock Roles, Not Objects paper. They concluded with a list of potential problems in interaction-based testing.

One interesting opinion came from a coach I don’t know the name of, who said that he likes to use mocks heavily as a design tool, then he usually throws away the tests and write new, state-based tests, because they are more readable and less brittle. I have no idea if it’s a sensible thing. I’m still not sold on the mock everything thing (I *love* my value objects.)

Agile Metrics

Next I attended Agile Metrics, by Dave Nicolette. This also was not hands-on, except that Dave kept the audience engaged by asking us questions. It was a nice recap of the agile thinking with regards to metrics. I always hear that you should measure the outcome of actions chosen in the retrospective; only I don’t do that in practice. I guess it’s one of those things you should just start doing; there’s no secret ingredient. One nice thing about Dave’s presentation was that the use of metrics was linked to principles from the Agile manifesto. For instance, the velocity and burndown metrics are of interest because “Working software is the primary measure of progress”.

Mirror, mirror on the wall…Why me?

Next the nice session by Portia and Pascal. It was mostly about thinking about the people around you, about their strengths and weaknesses (the magic mirror), and what our perception of these strengths and weaknesses tells us about what we fear and what we value (the mirror again). And to decide one simple action that will improve our relationship with these human beings. I got some food for thought, like how different personalities contribute to teamwork. They concluded by revealing the Two Secrets of Teamwork, which, being secrets, I will not divulge :-)

The Invariant Game

And we get to my session. I’m afraid the material I tried to present was too difficult. As usual when you’re beginning to teach some material, you tend to try to cover too much ground. This was an interactive session, but the exercises were a bit too tough for the audience (except for one). If there is a single thing that I think was a success, is the suggestion that there’s a vast space of learning that most developers, agile or not, are not aware of. I don’t think I succeeded in giving the participants a useful tool to bring home.

Invariant Game Slides

Invariant Game Problembook

I still want to make progress in applying math to make programming more effective. Someday I will find out how.

Conclusion

Olivier organized a demonstration of Aikido with his master, a kindly looking man who is probably quite deadly with his hands. It was nice to relase the tension and do something with my body.

We had a fine dinner; I had a nice chat with my friend Philippe. Then I took the train to Amsterdam with my Sourcesense collegues Marijn and Amelia, and another participant. Amsterdam by night is beautiful: the clean air over the dark water in the channels; the Christmas lights decorating the arches of the bridges; the Dutch houses with large windows without curtains, so that you see nice paintings and bookshelves from the street. I’m sad I could not stay the whole two days. I’m puzzled why my session was not so useful. I’m happy I was breathing again the energetic atmosphere of the Benelux Agile community.

Un altro Agile Day è passato.

Tutto di corsa

Purtroppo quest’anno non ho assistito a molte sessioni; sono partito da Amsterdam con l’aereo delle 7, e sono riuscito ad arrivare a Bologna verso le 11:30, quindi dopo la sessione di apertura e il panel. Poi quando sono arrivato, mi ha fatto un enorme piacere rivedere tante persone che non vedevo da un po’, quindi ho passato un po’ di tempo a chiacchierare e un po’ di tempo a completare le slide della mia presentazione. Come risultato, al mattino non ho seguito alcuna sessione.

Retrospective, Standup and Journal

Al pomeriggio ho seguito la presentazione di Piero Di Bello e Jacopo Franzoi su “Retrospective, Standup e Journal”. Si parlava di queste tre pratiche meno “tecniche” ma di enorme importanza nella vita del team. Se uno vuole rendere agile un team, e dovesse scegliere di iniziare con una sola pratica, farebbe bene a iniziare con le retrospettive. Perché è nella retrospettiva che il team inizia il processo di miglioramento continuo, che è uno dei due obiettivi dell’agilità. (L’altro è “soddisfare il cliente con rilasci rapidi e continui di software che ha valore.”) Il libro di riferimento sulle retrospettive è sempre quello di Derby e Larsen, Agile Retrospectives.

Piero e Jacopo non si sono limitati a raccontare quello che c’è nel libro; hanno raccontato episodi, pattern e antipattern vissuti nella loro esperienza di mentori, di cui ho parlato nella sessione successiva io. Esempi di antipattern: quando non si parla (il “silenzio degli innocenti”), quando si parla troppo, e conviene rimandare le discussioni tecniche in altra sede; quando si parla delle stesse cose, e conviene cercare di smuovere lo status quo variando il formato della retrospettiva, oppure facendola meno spesso.

Lo stand-up meeting è un’altro momento fondamentale nella vita del team. E’ così “facile” implementarlo che si dà per scontato che tutti lo facciano bene, ma non è così. Anche qui bisogna stare attenti ad alcune cose, di cui secondo me la più importante è che l’orario deve essere fissato e si deve assolutamente iniziare all’ora stabilita, anche se manca qualcuno. Anche di questa pratica Piero e Jacopo hanno raccontato un po’ della loro esperienza vissuta.

Infine hanno parlato del journal, ovvero il diario del team. Questa è una pratica di cui non si parla molto in letteratura. Piero e Jacopo l’hanno appresa lavorando nel team XPlayers in Quinary. (Oggi lavorano con me nel team Orione in Sourcesense.) Nel nostro team il diario viene tenuto regolarmente. E’ un’ottima maniera di tenersi aggiornati su quello che succede nel team, di riflettere a fine giornata su quello che si è fatto, e dà uno spunto al mattino per lo stand-up meeting.

La nostra esperienza di mentoring

Poi ho fatto la mia sessione, in cui ho raccontato l’esperienza degli ultimi 9 mesi del team Orione. Abbiamo fatto due episodi di mentoring, in cui una parte del nostro team ha affiancato il team del cliente, allo scopo di trasmettere il metodo XP lavorando su un progetto vero del cliente. I due episodi sono stati molto diversi; nel primo avevamo un team di 4 sviluppatori rumeni, dipendenti di una banca italiana. Nel secondo avevamo un team di circa 15 sviluppatori per lo più italiani, che erano stati arruolati in “time & material” da un’importante istituzione finanziaria italo-britannica per un progetto web. Mentre nel primo caso gli orionisti erano circa metà del totale, nel secondo eravamo in netta minoranza. La profondità della trasmissione del metodo ne risente; puoi agilizzare poche persone in profondità, oppure tante in maniera più superficiale. Questa è una regola generale del mentoring: la tua capacità è limitata, se la rivolgi a più persone sarà più sottile.

Ciononostante, l’applicazione di alcune pratiche chiave del metodo agile ha portato dei grossi benefici anche per questo cliente. Abbiamo aiutato a creare un team coeso; a tracciare e pianificare in maniera realistica il progetto, fornendo numeri affidabili per poter prendere decisioni importanti in maniera tempestiva; a migliorare la qualità tecnica del software prodotto.

Sono molto d’accordo con i punti che Gabrielle Benefield ha riportato dalla sua esperienza della agilizzazione di Yahoo, che ho letto sul blog di Pascal:

• Go deep Agile with a few of the most important teams, rather than spread Agile thinly over a lot of teams.
• Technical excellence, attention to quality and good engineering practices are essential.
• Grow slowly with teams that volunteer. Don’t overstretch your coach capacity.
• Involve management. Inform, address fears and explain “what’s in it for them”.
• There will always be people who don’t like or want Agile.
• Don’t just change the process; change the structure of the company.
• Bribe people with snacks.

Processo al database relazionale

Il mitico XP User Group di Bologna ha presentato in forma di pantomima un argomento molto interessante: il Processo al database relazionale. Con carisma di attori consumati, hanno portato in scena l’imputato (sotto forma di un cilindro di polistirolo, come viene rappresentato negli schizzi), il giudice Roberto Bertazzoni, il pubblico ministero Paolo Perrotta, l’avvocato difensore Finelli, e due testimoni! I testimoni sono stati interrogati dalle due parti, e hanno raccontato tristi storie di stored procedure lunghe 30 pagine (in Monaco 10), o di stored procedure che prelevano frammenti di query da una tabella di query (!!!). L’avvocato dell’accusa sembrava avere gioco facile nel dimostrare a quali disastri architetturali possa portare l’uso dissennato del database, ma l’avvocato difensore ha giustamente puntualizzato che lo strumento non ha colpa del fatto di essere utilizzato male; e che comunque i due sistemi in questione funzionano bene, e se l’imputato Sig. Relazionale Database non ci fosse, sarebbe forse più difficile ottenere gli stessi risultati.

L’arringa dell’accusa (introdotta da una slide che rappresentava un aringa), è stata molto convincente, con un esilarante citazione dal geek padre di noi tutti, Leonardo Da Vinci, e dei suoi consigli sull’architettura delle applicazioni. Paolo, voglio stamparmi tutto lo scritto leonardesco su una maglietta!! Il succo: separate le applicazioni nei tre laièri, ovvero strati, e mantenete l’intelligenza fuori dallo strato di persistenza.

L’arringa della difesa è stata pure molto convincente. Usate lo strumento nella maniera appropriata. Non ha fatto uso però di un argomento che per me è decisivo, e cioè: se non ci fosse il Sig. Relazionale a gestire l’accesso concorrente ai dati, saremmo nella cacca. Ci toccherebbe trafficare con semafori, thread e mutex, il che secondo me, nella programmazione applicativa, è un gravissimo antipattern. Non però nella programmazione di sistema, che è poi quella che si occupa di costruire strumenti come il Sig. Relazionale.

Alla fine l’imputato è stato dichiarato colpevole dalla giuria (il pubblico) di due su tre dei capi d’accusa.

Mi tolgo il cappello di fronte a uno user group che è capace di a) discutere di argomenti tecnici con passione fino alle due di notte, e b) realizzare una simile messa in scena.

Retrospettiva italiana

Luca Minudel ha condotto la retrospettiva italiana, in cui quelli del pubblico che applicano in pratica un metodo agile sono stati invitati a raccontare una cosa buona e una cattiva che è capitata in quest’ultimo anno. Abbiamo lavato un po’ di panni sporchi in pubblico, cosa che al pubblico magari interessava poco. Abbiamo parlato anche di azioni che possiamo fare per migliorare la qualità della comunità agile italiana.

Ci sono state diverse proposte; la migliore è stata quella di Tommaso che ha proposto un check-up fra due mesi: il 31 gennaio tutti noi siamo chiamati a scrivere un messaggio sulla mailing list extremeprogramming-it, per raccontare in che cosa è migliorata la nostra attività lavorativa dal 21 novembre. Questa proposta mi piace perché: è semplice, attuabile, è un piccolo passo, ed è efficace; realizza un proseguimento della retrospettiva italiana. Risponde anche al problema percepito da Simone che diceva che la mailing list è un po’ smorta (davvero? a me pare così trafficata che fatico a seguire tutto.)

La mia proposta era di proporre in Italia un numero maggiore di workshop di formazione, del tipo di quello di Tommaso e Fabiana sul refactoring, che è andato completo in pochi secondi da quando è stato reclamizzato. E’ evidente che c’è fame di questo tipo di eventi. Io proporrei di fare una giornata dedicata ai workshop (ovvero a seminari di formazione pratici, dedicati a un numero limitato, tipo 20 persone.) Si potrebbe fare o attaccata all’Agile Day dell’anno prossimo, oppure separata di circa sei mesi. Purtroppo Marco Abis non è stato presente alla retrospettiva. Mi sarebbe piaciuto sentire il suo parere.

Conclusione…

Mi dolgo di non avere partecipato alla canonica cena organizzata dagli amici del Bologna XPUG. Peggio per me! Sono felice di avere partecipato al quinto Agile Day, di avere rivisto tutti, e di avere portato un contributo. Sono felice che il mio intervento sia stato apprezzato da tante persone. Sono orgoglioso che tanti del mio team abbiano portato presentazioni o workshop.

Grazie a Marco, e tutti quanti hanno partecipato. Cerchiamo di mantenere viva quest’energia e di migliorare sempre!

Jacopo chiede:

cos’è un test di accettazione? e uno di integrazione? usiamo i sistemi veri o quelli finti?

La mia risposta: Un test di accettazione ha lo scopo di dimostrare che abbiamo capito tutto quello che c’è da fare per una storia d’uso. Il test d’accettazione serve per

1. dimostrare al cliente che abbiamo capito quello che chiede
2. chiedere conferma al cliente se abbiamo capito quello che chiede
3. nel processo di fare le ultime due cose, avviare un dialogo costruttivo sul cliente basato su *esempi* di come deve comportarsi il sistema.

Per fare questo, non è necessario passare per l’interfaccia utente e nemmeno usare i sistemi veri; ci si può semplicemente collegare direttamente alle classi di dominio che fanno il ragionamento.

One of the most common mistakes in creating customer tests is describing what happens in the user interface rather than providing examples of business rules. … Good examples focus on the essence of your rules. Rather than imagining how these rules might work in an application, think about what your rules are. If you weren’t creating an application, how would you describe those rules to a collegue? Talk about things rather than actions. … It takes a bit of practice to learn to think this way, but the results are worth it. The tests become more compact, easier to maintain, and … faster to run.

Shore and Warden, The Art of Agile Development, p. 285.

Quindi un test di accettazione NON E’ UNA DEMO!

La demo deve essere il più possibile interattiva. Per fare una demo è utile avere una interfaccia utente con cui giocare. Se il progetto è batch, conviene creare una mini-interfaccia molto semplice, magari basata su riga di comando, per stimolare il sistema. Perché i nostri test di accettazione stimolano il sistema su un insieme di esempi fissato. Invece durante la demo, e durante il test esplorativo, è importante essere in grado di provare cose diverse che ti vengono in mente e vedere rapidamente come reagisce il sistema.

Philosophically, exploratory testing is similar to test-driven development and incremental design: rather than designing a huge suite of tests up-front, you design a single test in your head, execute it against the software, and see what happens. Ther result of each test leads you to design the next.

Shore and Warden, The Art of Agile Development, p. 345.

Un test di integrazione, invece è un test che prova che il nostro sistema interagisce correttamente con *un* sottosistema esterno. Se sviluppi secondo l’architettura esagonale, il test di accettazione verifica l’implementazione corretta di *un* lato dell’esagono.

Un test di integrazione end-to-end, invece, testa il sistema tutto, con i suoi collaboratori esterni, dall’interfaccia utente. In molti casi il test end-to-end non conviene; perché è lento, fragile e difficile da manutenere. I test di integrazione focalizzati, insieme ai test unitari e ai test di integrazione, sono di solito sufficienti a darmi una buona confidenza sulla qualità del mio sistema. Ma soprattutto, il test di integrazione end-to-end non è efficace come il test esplorativo. Magari il test end-to-end è verde, ma appena provo a usare il sistema in maniera interattiva va tutto a pezzi.

Instead of end-to-end tests, use exploratory testing to check the effectiveness of your unit and integration tests. When your exploratory tests find a problem, use that information to improve your approach to unit and integration testing, rather than introduce end-to-end tests.

Shore and Warden, The Art of Agile Development, p. 305.

There’s a place to discuss design, but a pair programming session is not it. Pair programming is about programming. Sometimes I see developers stop typing and debating endlessly on how to do things. Sometimes, when I do pair programming (yes, I still get to do some coding sometimes) I hear my pair stopping me with objections, usually about design. “You’re going to introduce an IF!”. Yes. Definitely. I know that. But I’m not going to discuss that with you right now!

When I have a good idea of how to progress, I just do it. There’s no need to stop me to discuss my style; that will only take away energy from me. Let the code speak: if my idea is right, the pieces will fall together nicely and then we’ll decide if it’s worth introducing more design to get rid of the IF. If my idea is not so good, then the code will speak by itself. Suppose the pomodoro rings, and we realize I’m going nowhere; when we start the next pomodoro we toss my code, start afresh, and try some other way.

Maybe my pair thinks I’m going nowhere. If she’s quick enough to grab the keyboard from me, she can try another way. Let the code speak!

This does not, I repeat does not mean you should treat your pair disrespectfully. It is a completely different matter when my pair does not understand what I’m doing. It’s my responsibility to explain, with clarity and patience, what I’m trying to do. But! If my pair thinks he understand but wishes I tried some other way, then there’s two possibilities: either he will be patient and wait to see if I’m getting somewhere; or he’ll grab the keyboard from me and try another way.

There’s a place for design discussions; the best place in my opinion is in front of the whiteboard (and maybe with a cup of tea in hand.) Design discussions are good to clarify longer term goals and issues; or to explain and reason about domain difficulties. But when I’m at the keyboard, then the code is my whiteboard. Let the code speak!

The idea of “grabbing the keyboard” I learned from Francesco Cirillo (good luck trying to grab the keyboard from him!) See also his post Mamma Programming.

Credo che oggi tutti i manager dell’IT, se non hanno tenuto di proposito la testa sotto la sabbia negli ultimi 9 anni, abbiano sentito parlare in abbondanza dei “Metodi Agili”. Questi metodi nel nostro Paese non sono ancora diffusi come nel mondo anglosassone; quindi i metodi agili sono conosciuti dai più per sentito dire; non tutti hanno avuto l’occasione di incontrare persone che li applicano veramente. Inoltre gli agilisti sono per lo più sviluppatori, e quando organizzano (organizziamo) un incontro, di solito è dedicato ad altri sviluppatori.

Ora, il problema è che è fin troppo facile avere una percezione inesatta, o anche distorta, di che cosa siano i metodi agili, e di perché sono importanti per tutte le persone che tengono al successo dei propri progetti software. Anche e soprattutto i manager. Per questo Sourcesense organizza un incontro dedicato ai manager IT.

Il 25 novembre si terrà a Milano una colazione di lavoro in cui Sourcesense, in partnership con Red Hat, introdurrà l’argomento Metodi Agili. In quell’occasione avrò modo di spiegare ai manager presenti che cosa intendo io per Metodi Agili, e perché sono importanti. Le mie credenziali, per parlare di questo argomento, sono il lavoro di coaching, mentoring e training che ho fatto negli ultimi 3 anni.

Per partecipare, basta visitare la pagina dedicata all’incontro e mandare la richiesta di partecipazione.

Some time ago Dave Nicolette expressed so well something that I was aware of but could not formulate clearly. That is, in traditional waterfall projects the percent-completes are a lie; all they tell you is how much time is passed since the time the project started, and that is the only metric that a traditional project manager, armed with his shining copy of Microsoft Project, is tracking.

So please jump to Dave’s blog post and read about it!

Don’t split your project into multiple separate projects unless absolutely necessary. By this I mean, don’t have a separate “model” project that produces a project-model.jar, an “infrastructure” project that contains data-access objects, a “web application” project that contains the user interface of the application, and so on. This breaking down the project in subprojects

1. increases complexity a lot,
2. makes integration longer and more difficult,
3. is an obstacle to the evolution of the design,
4. and results in a lot of work being spent on the build system.

With multiple projects it happens that you do work in one project, and the other projects don’t “see” your latest modifications. Perhaps your application works properly when tested within Eclipse, but fails to compile in the command line, because some of the jars are not up-to-date. This sort of things drives people to introduce things like Maven or Ivy in the project, and that brings a lot of additional complexity. Maven and Ivy are very complex tools. They tend to look for jars all over the world at every build, making integration slow, difficult to understand and unreliable. I’ve seen project that require from one to two hours just for integrating your changes into the repo, and that assuming that you’re skilled in working with the build process. All of this has nothing to do with producing value for the customer.

It’s just too easy to spend lots of time building complex infrastructure. Don’t do that: spend time thinking how to simplify things instead. Think about how to produce value for the customer. Think about how to obtain the desired result with less complexity.

Within the multiple-projects antipattern, there’s a second, minor antipattern, that is the trunk, tags and branches folders everywhere antipattern. By this I mean that each and every one of your sub-projects has its own triad of trunk, tags and branches directories. Even assuming that we’re going to need these three directories, they should appear only once, at the very top of the tree of subprojects. It you do it like this, the triad will not get in the way: I can checkout the trunk once, and I will have a single, complete and consistent tree to work with. If every project has its own separate triad, there’s no easy way to manipulate the whole tree of projects without including tags and branches. No easy checkout, no easy update, etc.

Now I hear you ask: “But what if I cannot keep all of my code in a single project? What if I have to produce two versions of my application? What if I have to produce more than one application sharing most of the codebase?”

Even so, dear reader, my advice does not change. I would generate multiple apps from the same single project. I would write a separate ant task to build each version of the app; my ant tasks would pick and choose the pieces that are needed for a particular app. Very simple. I know that this goes against the pattern “one artifact per project” pattern. So be it; I don’t think it’s a particularly valuable pattern, expecially since it leads the way to the introduction of complex build systems like Maven.

“But you’re going to end up with a messy, complicated, unreadable ant buildfile!” you say. I don’t think so, dear reader. There is a danger of making a mess of the ant buildfiles, but then again this is the usual danger of making a mess of your software. The same care and skill that is required to write simple, high quality source code must be applied to the buildfiles. In my experience, with some care, I can keep my ant buildfiles pretty lean.

“But I have a legacy system, full of separate projects!” In that and other cases, when it’s impossible to keep all the code in a single project, you can get by with a relatively simple buildfile. All you need to do in the buildfile is to explicitly invoke the build on all the projects it depends on. This will increase the complexity of your buildfiles, but not dramatically so. It’s made easier if you can rely on all of the subprojects being at predictable positions within your working directory. Otherwise, you can cope by defining environment variables or per-developer configuration files that help ant find the projects it depends on.

“But my situation is different! I need Maven!” Dear reader, I won’t tell you what you need in your situation. You are the only person in a position to know that. This advice worked for me. My bet is that in almost every situation Maven or Ivy could be profitably replaced by a simpler scheme, if you really care about keeping complexity down, and are willing to spend time and thought for that.