Last month I joined an initiative by a group of Spanish Agile followers called
12 meses 12 Katas. The idea is that each and every month during 2011, we will be practising a
Kata, and sharing our code through
github, and for those adventurous enough to record themselves, also through this
vimeo channel.
There is a ton of resources in the net about what a Kata is and why are they important so I will not get into that, but I would like to stress the last bit of pragmatic Dave's definition:
"
[...] remember that the point of the kata is not arriving at a correct answer. The point is the stuff you learn along the way."
After having practised the February Kata a bunch of times, I wanted to write a bit about the process and reflect on my own deliberate practice and learning journey during these last couple of weeks.
When I first saw the Kata, I thought it was going to be easy peasy. Yes, totally missed the point; it's not about the problem but about practising it, but in any case, I was so very wrong! It turned out to be a lot more complex than anticipated, and I even thought for a couple of days that I was having some type of programmers block. Sticking to strict TDD didn't help much either, when you are not as used to use it as you first thought!
I went through 3 different solutions:
The First solution was very complex and it was very influenced by Maths. I was tracking all this positions for different numbers, and had a ton of if branches and all that. Messy!
Then I saw a recursive solution to the Kata. YES, I SAW IT; call it cheating if you want to, I couldn't care less. When I saw the simple solution, it made me think...Why did I start coding without thinking a bit about the problem itself. I should have a look at the relations among numbers, which ones are the special cases, and so on. In a nutshell, the Domain is very important, even in small projects. That was Lesson one for me, hope it sticks!
I'd say it has to do with our nature or background as scientists. That initial thought of 'I can do this with a bit of math', yields an answer, but it is too complex, not so difficult to write, but long, and difficult to maintain. A quick but thorough look at the domain shows that the cases can be simplified if you play a bit with them. Special cases such as 4, 9, and all numbers terminating in any of the two, can be easily automated.
So I started working on a recursive solution. At first I wrote a recursion with a wonky base case, and it worked anyway on one direction (arabic to roman), but it did not for the opposite. There was a mix here of problems with copy by value in Java, and objects and primitives. If it hadn't been for the primitive case, I wouldn't have noticed the flaw in the recursion. Which leads me to think that test are great, but obviously not a silver bullet! You still have to get the algorithm right! Another example of this can be seen in my video, when I mix up L and D in the tests themselves! So Lesson two is: no silver bullets.
Recursion can feel easy at times, but when it is easy to write, it makes you wonder if there is another way. And in fact there was. In this case a simple loop could yield the same results as the recursion, and that was my last solution.
I feel that I have a better understanding of what Katas are good for, after practising them deliberately for the last couple of months. When you are in the job, you just go to the point, and choose a collection, or refactor to an iterative process, but you don't get to dig out more information. Doing the kata in my own time, I consider that spending some of it in the details of how to choose that collection, or when to refactor is far more beneficial. This is something I had read about before, but never experienced by myself. Lesson three: deliberate practice is necessary.
What else did I learn/review this month?
- review of Maps in Java (mainly due to the fact that I needed order in my collection). Although I started the kata with arrays (some people will say that it was faster and all that), I decided to go for a map in the end, cause having two different arrays (one for arabic numbers and one for their roman counterparts) was not expressing the intent of the mapping.
- review of recursion and refactorings applied to the recursion itself. Interesting to find out that most newish compilers will automatically substitute a tail recursion for an iteration for you, so if the intent of the algorithm is clearer with the recursion, I will definitely go with that form from now on.
- I wanted to use cucumber for acceptance testing so finally got to set up
cuke4duke to run cucumber features on Java programs. It is so much fun!
- Writing cucumber features has reminded me (yet again) of my little knowledge of regular expressions. Also brings up the fact that writing features is a lot harder than reading somebody else's. Hopefully if I use them more, both things will stick in my brain, at least the basics anyway!
- Lastly, it has been quite strange to watch my kata after recording it. Does not feel like it is me (especially due to my supersonic typing up speed! Nah, it's fake, I've doubled up the speed cause the Kata was far too long!). It's definitely the case that what you think you are doing and what you actually do are two different things. The more I see it, the more I'd like to change things. But I think that that is good anyway!
As I mentioned earlier, the kata was a bit long for a video so I have sped it up! Generally katas are recorded with a piece of classical music as background. I've chosen a piece from my extensive collection, which pretty much means that it was the only 1 out of 6 classical tracks in my itunes that was long enough for the video!!! Hope you enjoy it!
Roman Numerals Java + cuke4duke (Double speed) from
Josmas Flores on
Vimeo.
