Extreme Enthusiasm

My new workshop proposal has been accepted at the XP Days Benelux conference. It’s a new experiment for me; I never attempted to teach things related to my Ph.D. work before.

What is the connection between program derivation and agile methods? Here follows my answer; it’s part of the handout I will prepare for the workshop.

One of the principles of the Agile Manifesto is “technical excellence enhances agility.” This is a crucial principle; you can’t expect to have success unless your technical skills are as high as possible. Trying to be agile without paying attention to technical issues is dangerous.

Think about it: when you work in an agile team, you give up doing extensive requirements before coding. This increases the likelihood of getting totally unexpected requirements halfway through; requirements that your architecture does not support (and here I define architecture as “that which is difficult to change later”). Then you give up an extensive design phase. This increases the risk that your codebase will turn into a ball of unmanageable spaghetti.

Agile methods use specific practices to compensate for the absence of the requirements and design phases: test-driven development, refactoring, pair programming and simple design. But these practices _are not easy to do_. Before you even attempt to be agile, you should get your fundamentals right. This means you should know your operating systems, algorithms and data structures, design patterns, object-oriented design and even UML by heart. For how are you going to do “simple design” when you don’t know what your design options are? How are you going to refactor, if you don’t know where to refactor to?

The theory I’m talking about is the work of, mainly, Sir Tony Hoare and Robert Floyd, who invented the axiomatic theory of programming, and Edsger W. Dijkstra, who pioneered the idea of developing a program and its proof of correctness concurrently, in small incremental steps.

A modern introduction to the subject is Program Construction by Roland Backhouse.

I write them here so that I’ll have a place to find them again.

Read the rest of this entry »

The Agile Mini-Project is a workshop that I presented with Vieri del Bianco at the Essap summer school.

The workshop is a miniature XP project in half a day. It starts with a brief introduction where we introduce what the exercise is about, then we split the audience in teams of no more than 6 people. Each team is then mentored by a coach.

The planning phase of the exercise is to extract user stories from the vague handout that the participants were given. The idea is to identify stories that are small enough to be coded in very little time. The coach, acting as a customer, identifies which story or stories he wants built.

After planning comes design, when we ask the participants to identify classes (in the object-oriented sense) and their responsibilities. The point is not to obtain a complete design, but to think about the problem.

After the design comes coding: we split participants in pairs. Each pair works on the same stories. This is sometimes called “swarm programming”: by having more pairs solving the same problem in parallel, we get to choose the best solution. It makes sense in the class environment, where it avoids the overhead of integration; but it makes sense in production as well, expecially when the story is difficult and will lay the foundation for much later work. It pays to choose the best design among a few, rather than sticking with the only one that a lone pair of programmer could come up with.

The last part of the exercise is a retrospective. One pair from each team shows their work to the whole class, and we discuss different solutions.

The materials for the exercise are:

• Presentation
• Handout
• Eclipse project

In retrospective, I think that half a day is too short for this project. Three-quarters of a day would be better. The purpose of the workshop is to tie together many themes, such as user stories, planning, test-driven development, design and acceptance testing. I think it works better with participants who have some knowledge of these topics.

The 3rd edition of the Essap summer school is finished. I’m finally home, feeling exhausted and happy.

It’s been a week full of learning, teaching, talking, heat, sweat and rain. For the first time the organizers of the school (myself, Federico and Vieri) decided to sleep in the same hotel as most of the participants rather than commute from home. Given that I no longer have the stamina it seems I had in 2006, it was a good choice. It was good to have a bit of respite in the evenings. Although most evenings I had some work as well.

Expecially on Wednesday night, me and Vieri still had not all of the material for Thursday morning’s event, the Agile Mini-Project. As soon as we were back from the school, at around 19 in the hotel, I showed Vieri the material I had prepared for the workshop. It was changed a lot from what we had thought before. I was not confident at all that it would work. We were tired, and there was not much we could add to it. I suppose this was for the best; it turned out we had the right amount of material (slides, exercise text, example code) that we could use for a half-day workshop.

We discussed the material for a while, then at 20:30 we set out to go to the restaurant. We had to: this was the restaurant that Vieri chose for the social dinner. We had an important appointment with the owner, to discuss the menu. A most pleasant task, I should say. :o)

Late at night, around midnight, I gave some polish to the material and went to bed.

Genesis of this mini-project

This workshop was organized by Vieri del Bianco and me.

The Agile Mini-Project workshop was tried out in two evenings at the Milano XPUG. The first evening I gave a task of “write a Basic interpreter”. I gave participants a list of user stories, carefully crafted so to be small and incremental, and no code to start with. I was not happy with the results; most participants wrote monolithic code with little design and little functionality. I expected participants to create a Parser class, and Interpreter class and maybe Expression and Statement classes. What I got instead was a bunch of monolithic code. Clearly these developers were not familiar with parsing theory, because they tried to avoid parsing as long as they could.

The participants followed the TDD rules, with poor results. I learned that TDD does not necessarily result in good code nor much functionality. As Simone Genini remarked today at Essap, Agile coding works well when the developers know a lot about analysis and design. You need to be strong in the fundamentals: in addition to analysis and design, you must know about algorithms and data structures.

So I learned that I should ask participants to do a little planning session, and a little design session before starting coding.

The second evening of Agile-miniproject tryout at the Milano XPUG Vieri was present. While I was scared to really try a true Agile miniproject, and I was trying to change it to an “advanced TDD” session, Vieri insisted that we really do a mini-project. I’m so glad that he did.

We had agreed to split the 18 participants in three six-people teams. We discussed a bit about the difficulty of introducing a Subversion server for each team. In my experience, small mishaps with these tools can result in an hour wasted. That would be a disaster for a half-day workshop. Besides, having three pairs work on the same codebase would introduce a bunch of additional problems, such as resolving conflicts, organizing work among pairs, and so on. The real risk would be that all the time were spent on the these activities, that are really not much fun compared to coding.

So we decided to avoid Subversion, and have all pairs work in parallel on the same story, starting from a copy of the same project. No integration problems. It was a good decision, because it turned out that many Essap participants had difficulty enough following the TDD rules; learning how to integrate at the same time would have been too much.

That evening we tried a different format; we didn’t give many rules to follow besides TDD. I gave them a small user story in the Basic Interpreter domain, and gave them a simple version of the interpreter, with a couple of stories’ worth of functionality in it.

It didn’t work very well that way either. My Basic Interpreter starting code was nice and clean enough, but it was a bit complex. It could interpret programs such as

10 INPUT A
20 INPUT B
30 PRINT A * B

The code was reasonably nice, with small classes each with a simple responsibilty. Some XPUG participants said that they liked reading through the code, although they added very little functionality! Still, no parsing knowledge is still no parsing knowledge. The domain would lead to complex problems, such as how to parse a recursive structure like “A * (B + C)”.

I still liked the idea of having a simple “text in, text out” user interface, that interacts with a rich domain model. I wanted to get down to the heart of this example, and I found inspiration in the example that Dave Nicolette uses in his TDD sessions; a simple “fighting game” with characters that have weapons and can receive damage.

I liked a lot that example, because there are very little algorithmic complexities, but you can reason a lot about how to assign responsibilities to classes; in this, it’s similar to most programming problems. I didn’t like the “fighting game” setting, which sounds a bit too violent. I do like fighting games and I played a lot of them, but the feeling I have when I think of Agility is not like fighting; it sounded the wrong tone. So I turned to one of my other favorite things, text adventures; I changed the domain to an extremely simplified text adventure, kind of like the games by Scott Adams or Brian Moriarty of the ’80s. i wrote a simple transcript of the interaction with this imagined game. Implementing this would have been more than enough work for a half a day. “Work for 12 days”, said Marc Evers when he read it. I’ll post the details of the exercise some other day.

I provided the very minimum skeleton code for this exercise. I’m very pleased with how the exercise turned out. In todays’ retrospective, many Essap participants said that they appreciated a lot that the mini-project tied together some threads that were discussed all along in the previous three days: user stories, planning and TDD. Although I did most of the work of writing the exercise materials, it was Vieri that made us stay on the right track of doing a true mini-project (rather than just more TDD). It wouldn’t have been nearly as good without him. Also Vieri and Fabio did a very good job of coaching their teams.

Thanks

What else to say? It’s been an incredible week, and it was the generosity of many contributors that made it possible. Elio Lanzarone, who first had faith in our ability to pull off something like Essap (Elio is a great coach. We have lots to learn from him.) The guest workshop organizers: Yves Hanoulle, Els Ryssen, Marc Evers, Willem van den Ende, Fabio Bertone, Jacopo Franzoi, Tommaso Torti, Stefano Fornari, Simone Genini, Luca Grulla. Many of them came from abroad, all of them posponed important other business to be with us. A first-edition Essap-friend who came to visit us: Alejandro Barrionuevo. My friend Carlo Bellettini, who came to help us today and is a software engineering professor who “gets” Agility. My employer SourceSense who let me steal Jacopo and Tommaso for one day, and our customer Eugenio S. for the same reason. The Ninja technical staff, so called because of their ability to have everything perfectly sorted out while you were not looking for a second: Andrea Gervasini, Domenico Marini and Massimiliano Pepe. I’m so pleased that this year the ninjas prepared workshops in addition to fixing the infrastructure. The many Milano XPUG members who helped playtest the mini-project. And the other school organizers, Vieri del Bianco and Federico Gobbo. Thank you all!

Update: and of course thanks to Simone Gentilini as well for participating to the “Agile loops” presentation and being with us in the first days of the school.

It is interesting to contrast von Neumann’s views of computer programming as an activity with Turing’s. Von Neumann called it “coding” and made it clear that he thought of it as a clerical task requiring little intellect. A revealing anecdote tells of a practice at the Institute for Advanced Study computer facility of using students to translate by hand computer instructions written using human-readable mnemonics into machine language. A young hot-shot programmer proposed to write an assembler that would do this conversion automatically. Von Neumann is said to have responded angrily that it would be wasteful to use a valuable scientific tool to do a mere clerical job. In his ACE report, Turing said that the process of computer programming “should be very fascinating. There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical can be be turned over to the machine itself.”
— The Engines of Logic, p. 192

Ho appena finito di leggere The Engines of Logic di Martin Davis, un saggio sulle vite e il lavoro dei logici che possono essere considerati i papà dell’elaboratore elettronico. E sono, secondo Davis:

• Leibniz, perché è stato il primo a concepire l’idea di meccanizzare il ragionamento
• Boole, perché ha inventato quella che oggi chiamiamo logica proposizionale o Booleana
• Frege, perché ha esteso la logica proposizionale con la quantificazione (per ogni… esiste…)
• Cantor, perché ha inventato il metodo di dimostrazione “diagonale”, che è stato poi messo a frutto da Goedel e da Turing
• Hilbert, perché ha dato nuova linfa al progetto di Leibniz di ottenere un metodo per ottenere la risposta a qualsiasi domanda tramite il calcolo
• Goedel, perché ha dimostrato che il progetto di Hilbert è irrealizzabile
• Turing, perché ha definito con precisione il concetto di “problema computabile” (favolosi quegli anni… più o meno nello stesso periodo Hamming definiva con precisione il concetto di “informazione”. Bello che si possa dare una definizione precisa a concetti apparentemente sfuggenti.) Non solo: Turing ha anche concepito l’idea dell’algoritmo universale, ovvero di una singola macchina che è in grado di risolvere qualsiasi problema computabile. Da quest’idea nasce l’elaboratore di uso generale che conosciamo oggi: con il mio computer posso risolvere problemi di analisi matematica, archiviare indirizzi, editare immagini… non c’è limite.
• Von Neumann, perché ha progettato l’architettura generale degli elaboratori che usiamo ancora oggi, e continueremo ad usare per un bel pezzo, visto che non ci sono all’orizzonte alternative plausibili.

L’argomento fondamentale del libro è che sì, gli ingegneri che hanno progettato l’hardware hanno la loro parte di merito, ma è l’idea logica a monte che è più importante e ha portato più lontano. Per fare un paio di esempi dal libro: Eckert e Mauchly, gli ingegneri che hanno costruito ENIAC, sono stati geniali per come sono riusciti a rendere affidabile una macchina costruita con 15000 tubi elettronici, componenti notoriamente inaffidabili. Però era basata sulla notazione decimale: pensate che spreco! La notazione binaria è molto più economica. Non solo, ENIAC comprendeva meccanismi specializzati per calcolare funzioni trascendenti, analogamente a quanto avveniva nei differenziatori analogici che erano le macchine di calcolo più avanzate dell’epoca. Ma in un calcolatore digitale non c’è bisogno di questi aggeggi, perché le funzioni trascendenti si approssimano con serie che possono essere calcolate con le ordinarie operazioni aritmetiche. I logici, invece, la sapevano più lunga. Già Leibniz era un sostenitore della notazione binaria. E Turing, nel suo ACE report, sosteneva l’idea che il calcolatore doveva implementare direttamente solo le operazioni più elementari, perché quelle più complesse (come quelle aritmetiche) potevano essere ottenute mediante quella che oggi si chiamerebbe “microprogrammazione”.

Ben scritto, avvincente e conciso.

Ci sono altri libri più approfonditi su questi argomenti; i seguenti sono sempre di divulgazione, tutti e tre veramente belli.

• Turing: the Enigma, di Andrew Hodges. Grandissima biografia.
• Goedel, Escher, Bach: an Eternal Golden Braid, di Douglas Hofstaedter. Labirintico e illuminante viaggio nella logica e nell’intelligenza artificiale.
• Mechanizing Proof, di Donald MacKenzie. Grande compendio sugli sforzi di dimostrare automaticamente la correttezza dei programmi.

Lunedì il mio amico Federico ci ha elargito una lezione gratuita e informale di esperanto, all’ottimo pub “Old Fox” di piazza S. Agostino. Ho sempre considerato gli esperantisti degli stravaganti un po’ pazzi. Non che non lo siano :-) ma sull’esperanto ho cambiato idea. Non è una cosa così assurda come potrebbe sembrare dall’esterno. Siamo condizionati a pensare che imparare le lingue sia molto difficile; probabilmente questo proviene dalla difficoltà oggettiva di imparare l’inglese (pronuncia difficile, comprensione del parlato molto difficile, e per ogni parola bisogna imparare a memoria come si scrive perché non c’è un metodo); o il francese (pronuncia difficile, ortografia baroccamente complessa); o il tedesco (razionale, ma occorre imparare a memoria la grammatica, come per il latino). Non siamo preparati a pensare che imparare un’altra lingua possa essere molto facile.

Nel caso in questione, l’esperanto può sembrare buffo perché prende in prestito le parole da tutte le lingue (“dànkon!” – grazie; “salùton” – ciao; “viro” – essere umano maschio adulto). Ma se ti lasci spiegare alcune semplici regole, è stupefacente quanto riesci ad imparare in poco tempo. L’esperanto è stato costruito in maniera razionale allo scopo di essere efficace; facile da imparare, facile da usare. C’è un sistema: ad esempio, conoscendo la parola “program-o” (programma; tutti i nomi finiscono in -o) puoi ricavare “program-isto” (programmatore), “program-ejo” (luogo dove si programma: software house), “program-aro” (insieme di programmi: software). E ancora: “program-a” è l’aggettivo: “programmatico”, “program-e” è una specie di avverbio: “programmaticamente”, “program-i” è il verbo “programmare”.

Federico ci ha spiegato le basi: l’alfabeto, i pronomi, le desinenze (16 in tutto, anch’esse sistematiche: ad esempio le desinenze dei nomi sono program-o, program-oj (nominativo singolare e plurale), program-on, program-ojn (accusativo singolare e plurale); per i verbi, si possono fare molte conversazioni conoscendo solo -i, -as, -is e -u: infinito (program-i, programmare), presente (“mi program-as”: io programmo, ma anche “vi program-as”: tu programmi, voi programmate. Una sola desinenza per tutte le persone.), passato (“mi program-is”, io programmai oppure programmavo), imperativo (“program-u!”, programma!)

Poi abbiamo letto, da bravi scolari, un dialogo da un semplice racconto che si può trovare online, “Gerda malapèris!” che significa “Gerda è sparita”. Anche qui c’è un sistema: “apèri” significa apparire; il prefisso “mal-” nega, percui “malapèri” significa sparire. E’ stato divertente.

Insomma, mi sembra plausibile quello che gli esperantisti sostengono, che dedicando 1/10 di quello che la maggior parte delle persone spendono in termini di tempo e fatica per imparare l’inglese, si può imparare l’esperanto a un livello che permette di conversare e corrispondere bene e senza fatica.

Vernor Vinge è uno dei miei autori preferiti. Il suo romanzo che preferisco è A Deepness in the Sky, che è fantascienza molto classica, scientifica, a base di astronavi del lontano futuro e alieni.

Questo Rainbow’s End è molto più vicino a noi; parla di un futuro prossimo. Ci sono echi di Neuromante per come la Rete è pervasiva nella vita dei personaggi. Ma mentre Gibson immaginava un “ciberspazio” separato dalla realtà reale, tanto che chi ci navigava stava praticamente inebetito di fronte al proprio “deck”, in questo romanzo la Rete compenetra la realtà; i personaggi percepiscono una “realtà aumentata” piuttosto che una realtà virtuale.

Ci sento anche un eco di La Luna è una severa maestra, per via di uno dei personaggi che probabilmente non è un essere umano; ma qui non voglio entrare per non rivelare troppo della trama.

Vinge è un positivista; è uno dei pochi scrittori o sceneggiatori contemporanei che non descrive un futuro triste e oscuro, anche se nel mondo di Rainbow’s End problemi ce ne sono: il più grave è il pericolo del terrorismo su vasta scala, che è un rischio tanto più concreto in un mondo in cui uno può fare ingegneria genetica a casa sua. Nei libri di Vinge non ci sono aspetti orrorifici né soprannaturali; l’unica “magia” è nella capacità delle persone di scegliere fra il male e il bene.

Insomma, un buon cyberpunk moderno.

Ho iniziato da poco a leggere Getting Things Done di David Allen. Normalmente un libro di con questo titolo non l’avrei mai minimamente considerato, lo avrei messo sullo stesso piano dei libri tipo “How to pick up girls” che Wayne di Wayne’s world (1992) trova nello scaffale del suo untuoso e infido rivale in amore.

Però GTD è diventato famoso fra gli agilisti. Ci sono tante persone che lo raccomandano, che mi sono convinto a comprarlo e leggerlo; e da pochi giorni, ho conseguito una vittoria per me fondamentale: ho vuotato la inbox di Gmail!!!

GTD ti insegna a processare la tua inbox, e a separare tutto in diverse categorie. In questo momento la mia categoria “@Agire” contiene una dozzina di thread. Molto più gestibile che non la inbox di una cinquantina di cose miste che ero ormai abituato a tenere. Non ho ancora finito GTD, ma mi sento già molto meglio. Decisamente un libro raccomandato a chiunque debba tenere traccia di tanti progetti contemporaneamente.

In Sourcesense l’area sviluppo Agile consiste per ora in un singolo team; il metodo di lavoro è Extreme Programming. Crediamo nell’importanza di restare un team, per cui non mandiamo le persone da sole dal cliente per lunghi periodi. Semmai andiamo dal cliente come team, in modo che il lavoro venga organizzato secondo le regole del team e non secondo le indicazioni del cliente (cioè non facciamo “body rental”.) Il mio ruolo in tutto ciò è di coach e project manager.

Il nostro team in questo momento si compone di 5 persone e speriamo di crescere fino a 8 nei prossimi mesi. Oltre quel numero immagino che splitteremo il team in due team separati, ma non è ancora il momento di pensarci.

Cerchiamo qualcuno che sia competente dal punto di vista tecnico, e che capisca e condivida i valori di XP.

I nostri progetti sono in questo momento tutti in Java, anche se in passato abbiamo fatto qualche cosa con Rails, e non escludo di poter fare qualche cosa con Rails in futuro. La cosa a cui maggiormente aspiriamo è di diffondere la pulce XP anche ai nostri clienti; abbiamo già in corso un esperienza di mentoring in cui facciamo un team misto Sourcesense-cliente per insegnare XP ai loro sviluppatori.

La sede di lavoro è nella zona di Milano. Non si escludono trasferte nel caso di mentoring, ma eventuali trasferte prolungate vengono concordate preventivamente con le persone. L’offerta è per un contratto di assunzione a tempo indeterminato.

Sourcesense (www.sourcesense.com) è una società giovane e in crescita che punta alla qualità delle persone e all’eccellenza tecnica. Siamo specializzati in Open Source e sviluppo Agile.

Se sei interessato o interessata, mandami il tuo CV!

Mi sono sempre piaciuti i linguaggi funzionali, e un tempo ero infatuato anche di Prolog. All’epoca (parliamo di un tempo in cui invece dei blog si leggevano le news) sentivo di quando in quando parlare di Erlang nei newsgroup che seguivo (comp.lang.lisp? comp.lang.functional? chi si ricorda?) Veniva guardato come uno strano animale, l’unico della compagnia usato nella programmazione embedded. Non feci la fatica di cercare più informazioni all’epoca, ero già occupato a sufficienza.

Passano 10 anni; Erlang viene ostracizzato dalla stessa azienda dove è nato, Joe Armstrong va in accademia e scrive prima una eccellente tesi di dottorato; poi un libro per i Pragmatici. Oggi Erlang è sul radar di molti. Si presenta come un linguaggio di programmazione basato su una concezione precisa, con un numero limitato di feature. I linguaggi che hanno cercato di vincere includendo ogni possibile feature immaginabile sono in declino, e l’interesse per Erlang è in salita. Erlang potrebbe essere il linguaggio ideale per applicazioni web: concorrente, semplice, robusto, con un database “a oggetti” integrato, promette di scalare facilmente fino a migliaia di connessioni concorrenti.

Non ho ancora imparato a programmare in Erlang (a mia discolpa, passo gran parte del mio tempo a fare corsi, mentoring e coaching sui metodi Agili, cosa che mi appassiona di più!) Però il mio lavoro come docente a contratto all’Università dell’Insubria mi da il vantaggio di avere ogni tanto giovani brillanti che mi chiedono una tesi… Così posso chiedere a loro di imparare Erlang e raccontare quello che hanno imparato. Tempo fa Marco Trinci ha realizzato un chat server sincrono su http.

Mercoledì 19 marzo si è laureato Jacopo Girardi, con un’altra tesi centrata su Erlang.

Read the rest of this entry »