Houston Way Dojo #2 Pro Enum – Switch Case ?

Here we go again

“Could this group reach a solution?”

We held our second dojo. Participants had changed but as in the first dojo they had virtually no previous dojo experiences.  The problem was the same CheckOut kata as in our first dojo. This offered the intriguing possibility for a comparison between the groups! Could this group reach a solution?

This time we had six coders participating. Time intervals were the same and I reserved the same amount of time for the design.

So we went ahead with the same one liner: “Strict TDD and here is the problem”.

Design phase

“Could we please draw that on the flip chart?”

After 5 or 10 seconds someone said: “Could we think about this problem for a minute or two alone?” Extremely wise move I thought. Everybody agreed and participants started planning on their own index cards.
It probably took another 30 seconds when the first one spoke up again: “Could we please draw that on the flip chart?” Wise move once again. Two brave ones grabbed a pen and started drawing their vision of the domain. There actually started to occur objects essential in solving the problem!

To the keyboard, set, go!

“Method naming: it’s damn difficult to please everyone.”

First pair started the implementation. They created the first test and things started to run smoothly: discussion, questions, tests, red, green, refactoring – oops! Not much refactoring! Method naming was controversial as usual: it’s damn difficult to please everyone. There was a debate about class responsibilities and a long discussion around one of the key issues in this problem: discounts. Which class takes that responsibility?

“Coding choices come from the heart.”

We had a long discussion about switch-cases. It appeared that some of us had not written those for ages. We thought we found a link between enums and switch cases – one leads to another? The switch discussion proved once again that coding choices come from the heart. At the end the common understanding of switches was not to prefer them.

public int getDiscountedPrice(Product product, int count) {

  switch(product) {
      case APPLE: return countApples(count);
      case ORANGE: return countOranges(count);
      case BANANA: return countBananas(count);
      default: return 0;
  }
}

private int countApples(int count) {
    int discountMount = count/5;
    int total = discountMount*APPLE_DISCOUNT_PRICE_FOR_FIVE_APPLES;
    total += (count-discountMount*5)*Product.APPLE.getPriceAsCents();
    return total;
}

“I could hear the sweet sound of keyboard tapping and smooth conversation.”

It was the discount debate that kept slowing the team down. With a gentle push they picked one direction and once again I could hear the sweet sound of keyboard tapping and smooth conversation.

Time is up – where are we?

“The second team wrote more lines of code than the first one.”

We could see the finish line, but we could not touch it. Damn those unmade decisions! Tough it is not a race, we want to get things done. The second team wrote more lines of code than the first one. But they had less conversation and less ideological discussion. Perhaps I also pushed the team too much? Nevertheless, both teams were good! We must remember that coding is not the point. It is what happens around the coding. In both teams discussion and learning did take place!

Let’s soon hear what happens in the third Dojo. Will they be the first ones to solve the challenge?

Pasi Honkanen

Thanks to: Henri Meltaus, Petteri Parkkila, Vesa Ylönen, Mikko Timoharju, Timo Friman, Kristiina Saarinen

Houston Inc. 03/14/2011 #houstonway