I’ve told a few people this over the years, but I hate the term “code kata.”
More accurately, I hate that people call code katas what would otherwise just be “programming problems.”
In martial arts, a kata is a choreographed routine that teaches and reinforces form and movement. Here’s a short video that shows a beginner’s kata. You can see that the stance, the punching, and the blocking moves are repeated in different transitions. A practitioner would do that kata the same way each time.
The goal? To internalize the movement so it becomes second-nature, so that outside of a kata there is less need for conscious thought when deciding what move to do. The position of the head, hips, and shoulders, the movement of the feet, and the general stance of the practitioner are all things that might feel unnatural and forced at first. Repeating the katas help make it feel natural.
Code katas, on the other hand, don’t usually look anything like a martial arts kata. There’s a problem statement, and you are left to solve it on your own.
They are great exercises, and the more famous ones are at CodeKata.com. I think they are helpful for a developer to gain experience with the hard work of software development, which is mostly thinking.
But the word “kata” implies a form to repeat.
Uncle Bob Martin’s bowling game kata, to me, is a kata, because it’s purpose is to teach the red-green-refactor cadence of test-driven development.
For people new to TDD, it’s a great way to learn how to test-drive the design of code. One of the subtle lessons is going through the design upfront and then discovering at the end that the code’s implementation is simpler and doesn’t necessarily look like the initial design. But the important part is writing a test first, writing just enough code to make it pass, and then refactoring out any duplication. Over and over.
I’ve done the bowling game kata a few times, and I’ve seen Uncle Bob demonstrate it twice. The TDD form was always the same, but it wasn’t rigid and mindless. It was helpful to have the slides and follow along, especially as the original kata was implemented in Java and I was doing it in C++. I had a guide that gave me the feedback I needed to know if I was on the right track. “I moved on to the next test, but I see the next slide had us refactor. Whoops. I forgot the refactor part of red-green-refactor.”
Contrast this code kata with what usually passes for a code kata: “Here’s an interesting problem statement. Solve it.”
There’s no guide. There’s not usually a right or wrong way to solve it. And when you do it, there’s no feedback that lets you know you did well or where you need more work. It’s just a programming problem or puzzle.
And while they are useful, I wouldn’t call them katas.
Unfortunately, we’ve had code katas for long enough that I don’t see this name going away anytime soon.
What’s your opinion on calling them “code katas”? Am I missing something subtle about them that makes the name appropriate?