Feedback from another Dojo

Today's Dojo was interesting, at least interesting enough to keep a trace of it.

The subject

I wrote a small Dojo subject a week ago that was selected by the group. The subject was to have a DSL to describe Recipes and to be able to compute some data about it.

Let's take the easy-child-access yogurt recipe:

• Pour one yogurt
• Add 3 eggs
• Add 100 ml of vegetal oil
• Add 200g of sugar
• Mix all with 300g of flour
• Cook during 30' at 180° celsius
  

The idea is to be able to compute:

• the list of ingredients with their quantities
  
• the cooking time
• the preparation time

Of course, you can start with simple calculation rules and add more complex ones such as:

• "Melting 50g of chocolate takes 30'' in the microwave"

You can also play with some grammar aspects:

• synonyms: Add, Pour
• complements: in a jar, with a mixer
• ...
  

I had several objectives with this subject:

• Make people collaborate on a quick design session
• Implement a parser for a DSL

So far, people decided to vote for this subject and we chose to focus on the quick design session then on some coding.

The Quick Design Session

This session was elaborated with somebody at the board during 5 mn, sketching a domain model. We quickly converged on the main classes: Recipe, Action, Ingredient, Quantity and thought about some kind of PreparationTimeEngine that was responsible for calculating preparation time depending on an action and its ingredients.

The acceptance test

We started coding an acceptance test for a very simple recipe: a yogurt with sugar!

• Take 1 yogurt
• Pour 10g of sugar
  

And programming the acceptance test took us the remaining 35' we had on the session,...

The retrospective

Yes, the result was not tremendous, and I am still thinking: "wow, 5 poor classes, 1 acceptance test = 1,5 hour, not a great productivity".

Anyway, I liked this Dojo for what we learned:

• :-) The quick design session pleased everybody because they really had the opportunity to share a common design. Something to do again "live", because this really accelerates the feeling of common ownership
  

• :-) I liked the emphasis on getting the acceptance test as readable as possible and the hunt for local variables that were not necessary

• :-) I liked the discussion around the necessity to have factory methods: createAction,...

• :-) There's no better place to jellify the group around fun and quality code
  

• :-\ Some pair co-pilot were relatively silent. Their role was taken up by the group

• :-\ Yes, I still think the productivity was poor and I think this shows plenty of improvement room for the group

• :-? We should try to enforce the rule that the group is silent and only the pair should talk. The other ones could take notes, observing the functionning of the pair

• :-? I wondered about the use of Java for this kind of Dojo. Python or Ruby would be more appropriate and productive

• :-? It is certainly better to prepare the Dojo subjects, so that the participants can get up to speed in a limited time. I had prepared a written spec with an acceptance test, but written acceptance tests would have been better. I think this is even more true with some of the subjects we wanted to do: Bayesian Filter for spam, Java Plugin Framework,...

Now, let's see how goes the next one.