Repetition doesn't increase experience, and has no value. btw take a note that I didn't -1, because I still don't fully understand what you are trying to do
–
BЈовићMar 5 '12 at 10:06

11

As Bruce Lee said, performing kata without an opponent (aka a reason) is like attempting to learn how to swim on dry land.
–
jfrankcarrMar 5 '12 at 12:05

3

I personally find repetition DOES increase experience. When I've done something once, I might not get it. Do it 1000 times in 3 organizations over 10 years and I get it better and more because I have... the benefits of... experience :)
–
junkyMar 5 '12 at 15:39

2

@junky I don't understand what exactly are you doing 1000 times? For example? Implement the same algorithm 1000 times? That is not experience. You can train a monkey to do exactly same thing ;/)2
–
BЈовићMar 5 '12 at 19:40

2

I hope you are going to discuss usefulness when you try to convince others to adopt katas. Otherwise, you'll fail & you will lose some credibility as well. Always discuss usefulness when you introduce a new concept to a team
–
MarkJMar 6 '12 at 12:36

4 Answers
4

How you introduce code katas into your workplace depends very much on what you want to get out of them.

In my case I wanted to encourage the use of Test Driven Development so I ran a Cyber-Dojo. With this sort of exercise, the emphasis is not on the code itself, but on the process of writing the code.

We spent an afternoon, in pairs, repeating the same kata, but under different conditions. We started with all groups doing one exercise at the same time. This provided a baseline.

We then discussed some of the basic principles of TDD, had everyone change partners and repeat the same kata. We repeated the same kata to de-emphasise the generation of code and instead concentrate people on the process of naming test cases and the Red/Green cycle.

Then we repeated the kata again, but roughly every 10 minutes one person in each group would move to another group, simulating the rather fluid team environments we often find ourselves in these days.

In the final iteration, we had both partners change every 10 minutes or so into different groups. This helped to demonstrate that with TDD, even the handover from one team to a completely different one needn't necessarily be too painful, since the project should only every be one Red/Green cycle from working.

The interesting thing was, there were few people who had done any TDD before the session, but what TDD knowledge there was rapidly spread until by the final iteration through the kata, most people were thinking in a TDD way or could at least appreciate why it might be beneficial.

People generally said that the afternoon was both fun and informative and we are now looking at other ways to use Cyber-Dojo at my workplace.

Cyber-Dojo, written by Jon Jagger is works incredibly well for this sort of exercise. It is a web based integrated environment for doing deliberate practice of TDD and learning about team dynamics. It has lots of kata's selected specifically to help people concentrate on the process of TDD and not the problem. It also supports a range of languages, from Python and Ruby to Java and C++.

The best thing is, after doing a kata you can then go back and look at the red/green progression (or maybe not *8') of each of the groups participating. It's traffic lights are a great way to visualise how the TDD process works.

If you want your own CyberDojo server, the whole project can be found at github and there is even a Turnkey Linux appliance virtual machine linked from there, which means that assuming you already have VMware player or VirtualBox installed, you can be up and running within a few minutes of downloading the appliance!

The question is "effective ways to introduce X into the workplace". I will not discuss if you should or should not. The way to introduce it is to look at your own organization and determine who is in the right position to introduce it.

In some organizations the best approach is through management. They rule some workplaces, so anything that they don't think is beneficial will be squashed. Otherwise participants will be forced to hide it from management, thus limiting its effectiveness.

In other workplaces the best approach is to get buy-in from a senior developer. They can encourage others to participate. They can get their entire team/project involved.

The 3rd approach is to get another respected developer involved. They have earned enough leeway that their time invested in X is not seen as a waste of time.

After it is introduced, be prepared to collect data and prove that it: increases productivity; reduces defects; or reduces training time.

+1 Also, be prepared to accept that what you are trying to introduce might not be a good idea or a business priority:)
–
Andres F.Mar 5 '12 at 16:16

ALign Capabailty and Desire i.e. make sure that those that can want to and those that want to can. In your case, you want to, but do you have the authority to make changes. The develoeprs are capable of doing it, but do they have the desire. If you align these two things, any change is made significantly easier.
–
mattnzMar 6 '12 at 9:18

1

This is how to get managers & senior devs to accept it. You will also need to get junior devs to accept it if they are going to get any benefit: there's a danger they could see it as remedial homework imposed by the boss, which could actually be demotivating. You should also define what benefits you expect for the organisation from these exercises.
–
MarkJMar 6 '12 at 12:33

One idea is when implementing a new algorithm that is a bit tricky or difficult is have multiple developers implement it independently. More than likely there will be two or more different implementations. Then switch with each other and try and implent the others implementation independently. Then get together and determine which way is best. This way you practice and it looks like you are just getting to the best solution.