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 list of ingredients with their quantities
- the cooking time
- the preparation time
- "Melting 50g of chocolate takes 30'' in the microwave"
- synonyms: Add, Pour
- complements: in a jar, with a mixer
- Make people collaborate on a quick design session
- Implement a parser for a DSL
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
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,...