Last week we had our first Kata Night at our user group. I'd like to share a little of our experience with everyone as well as address a few points that were raised by our members.
The idea to start doing Code Katas in our meetings came from an excellent workshop Dave Nolf (@dnolf) and I attended at Codemash this year. This workshop was called Software Craftsmanship and was led by Steve Smith (@ardalis) and Brendan Enrick (@brendoneus). Throughout the day we did several katas which gave us the chance to exercise TDD and pair programming.
As soon as I got back to Toronto I knew I had to start working on doing this kind of exercises in our user group. Right away I sent an email to the guys and everybody seemed to be excited about the idea. The great thing is that we even got some new members to show up just to try the katas.
What we did
We worked on Uncle Bob's Prime Factors Kata. I chose this one because it's one of the shortest one we could do. It was also very easy for me to do the entire kata in a few minutes and show everyone how to approach the problem from the TDD perspective. Additionally, the fact that Uncle Bob has the slides with the entire solution done step by step was very helpful, so if anyone wanted to go over it later it would be very easy.
We first tried to do the kata individually and purposely not using tests. The idea was to give the guys a feeling of how hard it could be implement something without tests while trying to tackle the entire problem at once instead of incrementally. We then proceeded to do two more iterations, this time in pairs and using TDD. We switched the partners at each iteration and we also threw away the entire code from the previous attempt.
How it went
I had a feeling people were having a little difficulty trying to figure out how to do the tests, and how much to implement to make each test pass. Another factor was that no one had ever done this kind of exercise before. There might have been some hesitation and discomfort in coding in front of someone else for the first time.
On the other hand I could feel that there was a lot of excitement. At the final iteration people were really loosening up, talking more and clearly having more fun. Everyone was really stoked about solving the problem. When the time ran out everyone wanted a few more minutes to finish their implementation. Of course we didn't add any extra time, that's the whole point :-)
Final impressions
Talking to the guys afterwards I could really tell that the experience had been really positive. Some of them were saying that they could finally see themselves using unit testing in real life as they could now have some guidance on how to do it.
Even though the experience was mostly positive I'd like to address some of the concerns the guys had:
1. There was not enough time to finish the exercise, which left me a little frustrated; I wish we had more time.
The whole point of the katas is that you train yourself to complete the challenge in time. If you can finish a kata you've never done before in your first attempt and in time then either your skills are very sharp or the time allotted was too large. As you keep doing your kata, you will become faster and your code will improve. Don't be upset if you can't get everything done, just keep on exercising.
2. It was fun doing TDD and pair programming but I don't think it's practical to do it at work, it takes too long.
When you first start doing TDD it really seems like it takes a long time to come up with your tests. What you have to remember is that you will get better, writing tests is an art that requires experience. Once you get into the hang of it you will write your tests much quicker. You will also have a better feeling of what to test and how to test it.
More important yet, you will be writing better code. To make your code testable you will be forced to create smaller and more decoupled classes. You will use interfaces more than ever before. And whenever the need arises for the code to be refactored you will do it quicker than ever before as now you have tests to enforce that nothing has been broken in the process.
3. It was hard coming up with the minimum possible code to make the test pass. I had the solution pretty much done after the second test.
Again, test is an art. If you're not used to doing TDD your brain is trained to reach the entire solution at once, that's the way people have been writing software for a long time. TDD will help you tackle the problem in an incremental way, doing only the absolute necessary to make the test pass. The problem is finding what that minimum is and, again, that is why we are doing the katas. Through repetition and with the help of more experienced TDD programmers we will be able to find the balance.
Thanks
I'd like to thank everyone who came to the meeting and really pushed themselves into trying something new. I already have some katas in mind for our next meeting. See you then.
