Coding Kata Month

I’m very lucky to be working at eBay with some of the most talented people I know. More fortunate still perhaps that they indulge me in my regular experiments in making our department a better place to work. I’ve been thinking about what I perceive as deficiencies in coding kata and talking to one of my colleagues at EPD (European Product Development) about this since maybe midyear 2016. As we talked about the similarities and differences in martial arts and coding kata, we began to explore what we might do in order to shift the needle on current coding kata practice.

To that end, we kicked off ‘Kata Month’ in December. It was very much an exploratory exercise to see what would happen if we solved the same kata every day for a month. Rather than do a kata until it was ‘solved’, what if we practiced it daily and with a view to deliberately practicing elements of coding? Truth be told, it very nearly did not happen, and I owe thanks to my manager Paul Hammond, who pushed me to kick off the exercise despite not being completely prepared. My tendency is to over-engineer and given the various pressures of our day to day I’d likely have delayed until January or February to try and have everything as I wanted it. As it turned out, we had enough in place and so with pretty much zero notice, I sent out the following email in December week 1:

Honestly, I was a little taken aback at how enthusiastically the initiative was picked up by the teams. I figured they might get a kick out of it, but they grabbed the idea and ran with it. They talked about it over lunch, they talked about it across teams. After a long and challenging year, it was great to see the crew jumping in with so much energy.

I dived in with equal enthusiasm. Honestly, I’d not coded in anger in well over a year, and I was painfully rusty. On day one, I realised how much I’d forgotten about TDD and got an embarrassingly small amount of code written. On day 2, I sort of hit my groove and worked out where I wanted to go with a solution. On day 3, I’d nailed a working solution to the problem, and by day 4, I knocked it out in about 20 minutes and started looking at how to evolve the data structures I’d chosen to make my solution extensible. I was feeling pretty good about myself.

I sat down to pair with one of our programmers in week 2. At the end of the first session I had the humbling experience of seeing just how much I had to learn about TDD (not to mention intentional programming and various design patterns). The other thing it did was make me realise just how rich this area of kata could be. Having an interesting problem to solve was one thing, but putting together a repeatable solution that incorporates a contextually appropriate use of both fundamental and advanced programming skills has so much potential.

I won’t give you a detailed rundown of the entire month; suffice it to say there were some interesting things to come out of it. Some of them code-related, some not.

For example, we stipulated one hour for kata between 11 and 12 (just before most people go to lunch). The consensus was after a couple of weeks that this was quite disruptive to the day overall. The teams had standup in the morning, then a small amount of time to work before kata started, then lunch and then the afternoon. Productivity-wise, there was the general feeling that half the day was gone before any project work got done. For future iterations of kata month, we’ll kick off the day with kata. If nothing else, at least that way folks are starting the day writing code — something that you don’t always get to do despite best intentions.

Another interesting thing that came out of our Friday review sessions was that some people were bored after ‘solving’ the kata. This was what I really wanted to address — that kata are not a thing to be ‘solved’, but a way to practice fundamentals. To some extent this was helped by the variety from week to week (individual, pairing, mobbing, etc.), but we also discussed using the time to work on weak points or selecting a different approach to solving the problem or even making more effective use of the IDE to do some of the heavy lifting. In hindsight, this might have been different if I’d spent more time setting the scene at the beginning, explaining how kata work in martial arts and what I was expecting. It also helped reinforce to me the importance of having a repeatable solution in place. Having a repeatable solution takes the ‘solving’ part out of the equation and lets you focus on practice of implementing a solution (more on that in a future post).

At the end of the month, I ran a retro and put out a survey to the participants. I’d like to share some of the responses.

What were your major take-aways from Kata Month?

What changes would you like to see for the next time we run this exercise?

It was interesting to see the various viewpoints of the people that participated, what their preconceptions and assumptions were, and how they changed over time. As far as our Friday sessions went, they were quite unstructured and in hindsight we could have made a lot more of them. We looked through some code, but with the exception of week 3 where we did an impromptu mobbing session, we didn’t really demo any writing of code. Given my views on kata as a visual teaching and learning aid, that feels like an opportunity missed.

Setting expectations early on was also a recurring theme. I think there is a place for some amount of ritual to designate a mental shift required for working on kata. It need not be elaborate, but something that puts the practitioner in the mindset of deliberate practice. In that way, the goal and the aim is clear — execute the kata in order to practice your fundamentals.

We talked also about the fact that this was a ‘greenfields’ kata and that it might be useful to try to do a kata along similar lines that was refactoring existing code that had issues of varying kinds. There are refactoring kata out there, but I quite like the idea of having kata that exist in pairs to exercise similar principles in both greenfields and brownfields situations, possibly even having kata whose solution works for one situation but needs refactoring to suit another. There are subtly different skills involved in selecting a particular design pattern to implement a solution versus recognising when existing code should be refactored to use that pattern.

Since kata month finished, I’ve put together a small working group of interested folks with the aim of putting together some kata of our own. We’re working to that end now, to come up with a problem and a solution that is representative of the skills required by an EPD programmer. My intention, once we have something that works for us, is to then share those with the wider world. In the meantime, there is no shortage of kata ‘problems’ out there, but very few of them are accompanied with a solution. About the only one that springs to mind is Bob Martin’s Bowling Kata. I think there is certainly scope for other existing kata to similarly have repeatable solutions designed for them — not simply ‘solved’, but achieving a repeatable solution deliberately designed to exercise fundamentals and good design principles in context.