Email iconarrow-down-circleGroup 8arrow-rightGroup 4arrow-rightGroup 4Combined ShapeUntitled 2Untitled 2ozFill 166crosscupcake-icondribbble iconPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

When we introduced two new developers to our team who didn’t have previous exposure to Test Driven Development (TDD) or Behaviour Driven Development (BDD) we made a few mistake, the biggest of which was thinking that we could get them up to speed quickly by only working on live projects. But learning TDD and BDD (or any other technically challenging skill) when trying to write production-ready code is not a particularly good approach.

The refactor death spiral: I’m not talking about the all-important refactoring that we embrace; I’m talking about the fact that as technically challenging skills are practiced they reveal new and better ways to approach them. Mistakes (a lot) are made along the way and it’s perfectly possible to end up in a never-ending cycle of refactoring the way you do things (such as writing spec tests) and having to revisit all previous code you’ve ever written, when you realise you’ve been testing the wrong things for instance. This can suck up so much time that there are very few moments for learning left and eventually you grind to a halt.

Too much pressure on the learner: the pressure of having to deliver quality code using techniques you’re unfamiliar with can cause a lot of stress/anxiety. This stress results in developers becoming frustrated, making mistakes and potentially not putting into practice best practices at all; for example, in order to get things ‘done’ developers write implementation and then tests, resulting in a very slow progress in terms of TDD learning.

Not enough support from mentors: experienced developers, locked into a sprint and needing to get their work done find it difficult to dedicate the necessary mentoring required and those learning find it difficult to ask for help resulting in a big dip in productivity.

Code Kata – a way to learn fast

The way to excel at anything, whether you’re a professional athlete, musician or developer, is not through competitive racing, live performances or deploying to production, these are the fruits of your labour. Before that comes hard work otherwise known as practice.

A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each.

We’ve found that Code Kata provides us with a fast way to learn in intense, short and fun sessions.  First, let’s look at where a developer will learn most when taking a typical user story through to completion during a sprint:

Plan > design > spec > implement > test > review

Generally, most learning takes place at 2 points in this process, first during the design phase when figuring out the implementation and test strategy and secondly (and mainly) during the review stage when feedback occurs.

Taking one of our small user stories, the end-to-end of this process can take over a day and in fact, due to our fixed sprint lengths, the test > review part might not occur for several days after the developer has initially left the card so a developer has to wait up to 1 week (the length of our sprints) for a single learning touch point. This is not introducing enough points for feedback and so learning is slow.

Code Kata provides us with a quicker way to iterate through the whole cycle.

Plan > design > spec > implement > test > review – in 30 minutes!

Every Friday at 4pm the entire dev teams at the Green Room (ourselves and our friends Browser London) stop working on client projects and settle down for a 2-hour CodeKata session. The principle is pretty simple, to start with we draw names out of a hat to make up 4 pairs of developers. I then provide both teams with the same CodeKata problem for that week. An example from Dave Thomas’s very useful website being:

Just because we need to sort something doesn’t necessarily mean we need to use a conventional sorting algorithm. There are times when whipping up a sort of our own can outperform these generic routines. Our challenge this week is to implement a couple of different sorts. In the Pragmatic Lottery, we select each week’s winning combination by drawing balls. There are sixty balls, numbered 0 to 59. The balls are drawn by the personable, but somewhat distracted, Daisy Mae. As a result, some weeks five numbers are drawn, while other weeks seven, nine, or even fifteen balls make it to the winner’s rack. Regardless of the number of balls drawn, our viewers need to see the list of winning numbers in sorted order just as soon as possible. So, your challenge is to come up with some code that accepts each number as it is drawn and presents the sorted list of numbers so far.

Round 1

Having allowed the teams 5 minutes to discuss the problem between them I start the stopwatch and set each pair of programmers on their way. In typical pair-programming style, one takes the reins (keyboard, mouse etc) and the other must observe, comment and contribute constructively.

Once the stopwatch hits 15 minutes I ask all pairs to swap roles so that the one at the keyboard is now the one observing, commenting etc.

I then time a further 15 minutes and provide a 2 minute warning followed by blasting out the Countdown tune with 30 seconds to go.

Round 2

We don’t allow much more than a few minutes between the rounds (to keep intensity levels up) and the first thing I request is for each team to completely delete all evidence of their work in the first round.

I then get the pairs to swap (so we have 4 completely new pairs) and repeat the process outlined in round one.

The interesting thing about Round 2 is that whilst each developer has a clearer understanding of the problem and a particular approach to the way they solved it the first time, the other developer in the pair may have approached the problem completely differently. Therefore, the hardest part at the start of this round is for the pair to consolidate their understanding of the problem and agree on a ‘third’ way or at least a way that both are satisfied with. This is an incredibly important part of development (resolving conflicting ideas) practiced very rapidly.

Round 3

As with Round 2, delete code, swap pairs and start the stopwatch

Final review

Whilst we don’t code review our CodeKata’s (pair programming is a good real-time peer review method anyway), we find that at the end of the session, there is a great vibe and everyone is keen to discuss how it all went and share their different approaches. Make the most of this energy because it‘s an energy you want to harness. As it’s the end of Friday, beer also helps at this stage!

Useful tips for those running the Code Kata session

Help each team to work as a pair: I haven’t been into too much detail about the nature of pair programming which can be read about elsewhere online but it’s a very important factor in the Code Kata sessions. It should, in theory, enable learning to occur during implementation because the developer not at the keyboard is observing, commenting and questioning, providing continuous feedback (but not dictating, criticising or controlling).

Don’t enforce completion: if you place too much emphasis on completing the task (and some developers will focus too hard on this too) developers will start to sacrifice quality. This is what happens in production environments when too much pressure is placed on ‘velocity’ over quality. If your aim for these sessions is to speed developers up, allow them to practice without feeling the pressure of completing the task within a set timeframe. You’ll find that once practiced, programming techniques become second nature and the end result will be faster development AND higher quality code. Win win.

Ensure they do delete the code: We want to re-enforce the fact that there are always multiple ways of solving the same problem and that’s especially true for programming. Ask 10 developers to solve the Kata above. Do they all solve the same problem in the same way? Absolutely not. Most likely you’ll have 10 different implementations. And the best implementation? Probably none of them, potentially a combination of some (or all) of them and maybe something completely different. The point is, it’s good for developers to understand there’s more than one way of doing something and that throwing away your code and starting again is sometimes the best option (how many times have you seen developers hammering away, ending up burrowed deep in the rabbit warren? In classic Kenny Rogers style, learning when to walk away from a particular implementation choice is a valuable skill that will save you a lifetime of pain:

You got to know when to hold ’em, know when to fold ’em, Know when to walk away and know when to run.

Help pairs to contribute equally: observe the pairings and help them to treat each other as equals. It’s often difficult when you have a lead dev paired with a junior but it’s important that this is about both contributing equally. This isn’t a mentoring session.

Be strict on time: from time to time you’ll be ‘encouraged’ to give a bit more time. But this is because too much emphasis is being placed on task completion which we aren’t concerned with. Speak to the developers and re-assure them it’s not about completion, once they understand they will stop asking for more time!

Help to make it fun but keep it intense: play some novel (but not distracting) background music, initiate discussions, provide rewards, do whatever you need to unleash your developers from sobriety! Focus on removing anxieties and reassure that making mistakes and failing is good.

Encourage discourse:  The room should be buzzing with individual pairs constantly discussing, agreeing, disagreeing but all the time highly focussed on the task. If the room is quiet and people are disengaging from the process then something is wrong

Find Katas that are challenging but not out of reach: I made a big mistake the third session I ran: the enthusiasm that was evident after each previous session carried me away and I set a very challenging task. In hindsight it was just too complex for the session and you could feel the enthusiasm and intensity collapse. By the final round, developers were on their mobiles, looking at the cricket score and at the end of the session everyone seemed deflated, making their excuses to go home instead of the usual hubbub of conversation post Kata.

Acknowledgements

I’d like to thank Marcello Duarte , Head of Training at INVIQA for the advise he gave me during last months London Behat User Group

Share: