Observations from katas

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?

Comments:

[Daniel] - Feb 18, 2010

Can you please point me to the definition of the Java EE Spike Kata?

[Daniel] - Feb 22, 2010

Interesting…
So then you must have forgotten one of the following:

  • no IDE allowed
  • includes 60 mins for lunch
    Otherwise I think this can be done in about 10mins.

Anyhow: Looking forward to a more detailed definition of kata.

Johannes Brodwall - Feb 22, 2010

An IDE is allowed, but code generation is not. The first point of the exercise is to really understand what code is needed for a full stack application. The second point is to explore testing at different levels, so you must write tests for both the web, the DAO and the controller.

The final point is to get a feeling how long it really takes to get something verifiably working. Before I started practicing, I thought it would take 10 minutes. After I practiced, but before I started timing myself, I though it would take 20 minutes. After I started timing myself, 90 minutes was about right.

Code generation isn’t necessarily bad, but the point of the exercise it to explore what code will be generated. You don’t necessarily have to test everything, but the point of the exercise is to explore how you would test anything.

Johannes Brodwall - Feb 19, 2010

I haven’t defined it properly (but it’s on my todo list). Here is a brief description:

Objective: To test drive a new Java web application that updates and queries a database.

Acceptance test: A WebDriver test that accesses the application to insert a “Person” object in the application and then searches for the same person.

I start by writing this test, which gives an outside-in approach. However, that means that the test will not pass before I’ve written and got to pass a number of lower-level tests.