Katas and Dojos

In addition to continually seeking new knowledge, successful professionals practice their craft on a regular basis. Musicians use scales as warm-up exercises, cosmetic surgeons practice on cadavers, athletes run drills and scrimmages, speakers warm up in front of a mirror, and martial arts practitioners practice katas—choreographed patterns of movement.

During such practice sessions, practitioners repeat common and basic elements that they learned at the outset of their careers. These drills help ingrain basic skills. Practitioners also use them to warm up for a performance or challenge. In the midst of a challenge, a skilled performer seeks to let their “muscle memory” kick in as much as possible to handle basic movements. That can help improve their ability to think and better react to their environment.

Further, mastery of basic movements is an essential foundation for growth and exploration. More sophisticated and effective forms are often creative variants to basic forms. Advanced professionals may sometimes even find that they can throw out basic rules. Their deep knowledge of basic forms allows them to recognize and accept the costs of discarding them.

Many developers have applied the martial arts concept of katas to TDD. The concept is much the same: test-drive the solution to a brief programming challenge. Repeat until you are able to demonstrate an ideal path to the solution by eliminating wasteful steps. Dave Thomas supplies a number of sample problems at his site (http://codekata.pragprog.com).

Applying Katas to TDD

Does it make sense to practice test-driving code? To build software, you work with an ample number of tools at any given time. Your hands interact with a keyboard to produce code. You interact with an editor who provides numerous ways to accomplish tasks. You work with a language and set of libraries (including a test framework) that similarly provide countless ways to produce solutions. Finally, you think about many things. And while each bit of thinking through a solution might seem to represent a unique, nonrepeatable process, there are many repetitive themes (patterns) in software development.

The more you practice these elements, the better you will become at each. The longest pole in the tent is no doubt the thinking part, but it’s still possible to get better at thinking through solving programming problems.

Where to get started? Find a kata that appeals to you, perhaps one you’ve seen demonstrated before. For a first kata, prefer something small, a challenge that you might be able to complete in an hour. Note the time and then test-drive a solution. If you get stuck, be willing to backtrack a bit. Finally, record the time you took to derive the solution.

If you became hopelessly mired, discard your attempt completely and try again, seeking help if need be. (You’ll know if you need to choose another first kata.)

Review your solution, and think about the steps you took to derive it. Run the kata again, preferably immediately (or within a reasonable period of time so that you don’t forget everything you just learned). Don’t memorize, but instead think about a better sequencing of steps to follow. Compare the time you took to the first time.

Repeat the kata from time to time, perhaps one to three times per week. Seek out tweaks and other refinements. For example, explore a better API or language construct, and seek to eliminate some typing by using a better editor shortcut. At some point, you’ll be close to an ideal solution, with the ability to derive it via a minimal set of steps and mistakes. It’s now a tool in your warm-up bag!

To improve your test-driven problem-solving ability, you’ll want to grow the number of katas in your bag. Solving different types of problems can teach you different techniques and help you get better at coming up with important insights.

Appendix 2, ​Code Kata: Roman Numeral Converter​ contains a simple starting point, the Roman numeral exercise, in which you test-drive an algorithm to convert an Arabic number to its Roman numeral equivalent. You might also try other exercises from this book, such as the Soundex example, as your first kata. Table 1, ​Kata Resources​ describes many useful kata resources.

Dojos

Katas are typically a solo pursuit (although they also work well with a pair). They’re something you can pick up at any time and bang away at for five minutes or fifty minutes. But you can also take your attempts at TDD mastery to the next level by performing katas as a team in a dojo. Like Japanese martial arts dojos, a TDD dojo is a group training session with some level of ceremony and structure.

For a typical dojo, allot sixty to ninety minutes in a room where you can project a single screen to everyone. To warm up the team to the notion of dojos, your first dojo might involve a single presenter or pair who demonstrates their path through a solution for a kata that they’ve already done before. The presenter’s job is to ensure everyone understands their programming choices before they move on to the next step.

For subsequent dojos, randori-style is more entertaining and engaging. Various structures for randori dojos exist; here’s one as described by the Coding Dojo wiki (at http://codingdojo.org):

• A starter pair tackles the problem chosen by the entire group at the outset of the dojo.

• The pair switches roles frequently between driver and navigator, perhaps using ping-pong pairing.

• The pair has a time limit, somewhere from five to fifteen minutes, to advance the solution. They are expected to describe what they are doing as they go.

• One member of the pair (typically the driver) swaps out of the pair once the time limit hits and is replaced by an audience member. All attendees are expected to swap into the pair at least once during the dojo.

• The audience may offer suggestions as appropriate.

You might choose a sensei to offer advice by asking questions (but not providing answers) and to otherwise help facilitate the dojo.

If the kata runs any more than a half-hour or so, take a five-minute break midway through. Finish with a brief retrospective: discuss what went well with the session, and decide what you will do differently for the next.

Randori dojos provide opportunities for everyone on the team to get involved. You might revert to presentation style when there’s a new problem that the team wants to tackle or when someone wants to demonstrate an end-to-end solution that they find more effective.

Dojos are about collaboration and sharing. Your team will have a better understanding of how others on the team approach problem solving, and you’ll pick up lots of new ideas along the way.