What are Code Katas and Why Should we Care?

What are Code Katas and Why Should we Care?

The REAL kata!

While we, as software system developers, certainly know that our day to day work can bring a lot of satisfaction and improvement to our profession, there prove to be other ways that we can also try out to flex our coding “muscle”. “Kata” is a term borrowed from the world of martial arts. According to Wikipedia, a kata “is a detailed choreographed pattern of movements made to be practiced alone, but are also practiced within groups and in unison when training.” That sounds a bit different that what you might’ve expected. But if you think about it, our coding craft is not that much different. We practice a pattern of strokes, sometimes alone, but also in groups, you might know as teams, or pairs, that sometimes translate into pair programming sessions.

The term “kata” in regard to software craftsmanship has been coined for the first time by Dave Thomas, one of Agile’s founding fathers. Programmers have always proven their affection to their craft by comparing it to some rather mystic concepts. For example, Robert C. Martin (aka Uncle Bob), wrote an article called “The Programming Dojo”. Others have called it a mystical art or even compared good programmers with ninjas ! Truth is, unlike other crafts, ours rarely ends in a finite, absolute, product. Of course we can deliver a software package to a client, but that doesn’t mean that the object of our delivery doesn’t have room for improvement. Maybe the client will send it back because they found a small defect, or maybe they will ask for new functionality. Or sometimes, God-forbid, they might ask for a complete re-write. Ours is truly an endless path of perfecting our craft. We do not build a product, like a wooden spoon, or a katana, that can be delivered and used for a long time without other intervention. Our product is a volatile, changeable, almost energy-like creation that lives and evolves, almost like a biological organism.

But I digress. Back to the problem at hand, I want to show a few ways that one can improve their programming prowess through a simple method. This method isn’t only a mental exercise, but also a way to reinforce some day to day tools, that I believe, all software engineers should possess. I will exemplify the development of a code kata based on the famous problem called Conway’s Game of Life. According to codingdojo.org , we need to follow a few rules in order to provide a software program that is able to provide a next generation of Conway’s game of life, taking as input any starting position. More information about this problem can be found on this wiki page: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life .

We have to start by providing a 2-dimensional grid of cells. Each cell is either alive or dead. No life can exist off the edges of the grid. These rules need to be followed when computing Conway’s next generation:

1. Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
2. Any live cell with more than three live neighbours dies, as if by overcrowding.
3. Any live cell with two or three live neighbours lives on to the next generation.
4. Any dead cell with exactly three live neighbours becomes a live cell.

Because we want to train our TDD ways, we will start our journey with a couple of simple tests. I decided to use Scala for this workshop, but the tool is not awesomely important right now!

We shall then write some code that will make these two tests pass. The simplest code that could possibly work! Be aware that I said multiple things will be trained. Going through the Green-Red-Refactor loop, it might mean that the simplest thing doesn’t include helper methods already refactored. But I have just shown these refactoring upfront, materialised in this case as a helper type and grid-generating method.

This is just a warm-up so that we get a chance to set up our project, do a bit of coding and also remember to use the awesome sbt ~test that will continuously run our test suite while waiting to detect code changes.

But now it’s time to add some real function to our block! We will start with a 3x3 grid example, where only elements grid(0, 0) and grid(0, 1) are alive.

Scala has neat ways of quickly displaying visually our grids, by use of multiline strings, stripMargin and the | character. We can of course start developing our game of life method in our ConwayGoL object. That is because we have made a new failing test. This kata therefore will train our TDD routines pretty well I’d say. So just continue adding tests that make the next small feature fail, write just enough production code to make it work, then refactor.

Talking about refactoring, this is another skill these katas will train for us. It will help develop an eye for situations where we feel that we should mercilessly refactor . I have written Conway’s four rules as four different one liners. After that, my initial generation generator — pun intended — will become something like:

But please notice that we might end up with too much indentation. Too much indentation can often be considered a code smell, so let’s extract the valid rule checking if clause into its own separate thing.

These are a few examples of us interacting with a new code kata. I must admit, in preparation for writing this article, this was my first time I had solved this interesting problem. It was very rewarding to be able to do it.

So, in conclusion, I would like to list some of the advantages I find when solving code katas:

• Practice TDD
• Refactor mercilessly skills
• Give you a chance to mess around with new tech and languages
• Brain muscle flexing
• Selfish sense of accomplishment :)

In case it’s needed, you can find my own solution at this GitHub repo: https://github.com/alexmacavei/game-of-life-kata . It is by no means perfect, it could definitely be improved by writing more tests and the getAliveNeighbours method can also be improved. I will leave these as exercises to the reader.