Observations from katas

how-to
Dec 23, 20092 mins

Lately, I’ve been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I’ve chosen are:

  • Java EE Spike: An application that stores People with names to a database and lets me search for them. I’ve repeated this pair programming with several different programmers.
  • Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,… you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with “coconut”.

I’ve learned a lot from repeating these exercises:

  • Using test-driven development it takes me longer to get to something that “should work in principle”, but shorter to get to something that works correctly.
  • When refactoring to a new data structure, add the new structure while keeping the old one, make switching between them as simple as changing a single line. Delete the old when it works.
  • There’s always an automated refactoring you still want to help you out. Extract Parameter Object was my big one.
  • Writing for example a method invocation and then using quickfix to have the IDE generate the method is the quickest way of writing code available to you.
  • After 8 iterations, the Java EE Spike takes me 80 minutes solo. Pair programming with another programmer who had practiced: 65 minutes. I don’t know why!
  • Pair programming a moderately complex kata like the Java EE Spike is fun. It’s also a good chance to discuss different roles of different tests.
  • There is a huge difference between a test that takes 3 seconds to run and one that takes 0.5 seconds when you’re test driving. More surprisingly, there’s a big difference between a test that takes 0.5 seconds and one that takes 0.01 seconds
  • If you think test-driven development is not for you or that it’s bunk, you probably write really slow tests.

What are your latest coding observations?