It is time for our third Dojo. Same setup as in the first dojo. Same CheckOut kata – different participants. Would this group solve the challenge in the given time frame or perhaps find some deeper meaning for coding?
10 Minute Design
“No big drawings, no big upfront design – not a bad start!”
Sounds like a TV Shop commercial: 10 minute design. What do you get? Mostly nothing. These guys had some discussion but nothing very spectacular. No big drawings, no big upfront design – not a bad start!
The silent coders
The dojoers
This group was relatively quiet. They focused on coding and writing tests instead! Most of the discussion was around the keyboard layout of Mac. Following their communication was interesting; some member just started designing and others silently agreed. Good or not? In any case their progress was impressive.
A Static method!?
“Someone wrote a static method.”
Someone wrote a static method. There it was on the screen and no one disagreed! I held my breath. As a participant, I would have removed that and tried to provoke some discussion around it. Here you have it:
public static Double countPrice(Product product, int count) {
Pair discount = discountPrices.get(product);
if (discount != null) {
int discountQuantity = discount.fst;
Double singlePrice = (count % discountQuantity) *
productPrices.get(product);
Double discountPrice = ((count - (count %
discountQuantity) ) /
discountQuantity) *
discount.snd;
return singlePrice + discountPrice;
}
return productPrices.get(product) * count;
}
(See the complete dojo solution.)
What do you think? Is this the worst evil ever or a clever solution to the exact problem? Feel free to comment!
Three, two, one, …, Time’s up!
15 minutes to go and they were so close! Only few more lines of code and the solution would fulfill the original requirements. Would they make it? Last test was still red! Yes! A newly dojoed piece of code and it fulfilled the requirements. This team made it! Third time is the charm.
“This group’s ability to concentrate on the essential was unbelievable.”
As passionate developers we did not stop there. The shop owner (me) wanted to sell melons. Programming continued. No big ceremonies just a little grin on their faces the dojoers continued the work. And they were able to finish the additional melon feature! This group’s ability to concentrate on the essential was unbelievable. They were a real team!
What did these three Dojos teach?
“Where the first group barely wrote 50 lines the last group was able to finish the solution!”
It was interesting to see how different these three Dojos were. Yet they had so many similarities. The original idea for the solution was pretty similar. The biggest difference was the amount of lines actually implemented. Where the first group barely wrote 50 lines the last group was able to finish the solution! But the level of discussion was deeper in the dojos with less progress with coding. I think the key learning – or let’s say reinforcement – was that if you seek progress, don’t try to solve the problems just by discussion and planning. Instead:
- It is better to make the problem visible by coding and then have focused discussion around the chosen implementation.
- Discuss, but know when to stop.
- Make decisions and proceed.
- Be not afraid for wrong decisions. -> You will soon discover what doesn’t work and you can choose a better solution!
And you should always remember to:
5. Refactor!
Looking forward for the next dojo,
Pasi Honkanen 04/07/2011
Special thanks to: Heikki Häyhä, Marno Kulmala, Jukka Puranen, Esko Pylsy, Jukka Rantala & co.
