At Flywire we use several learning, development, and working techniques that I want to share with you, but as I was putting this post together, I realized that none of them could be explained separately. Instead, the techniques needed to be considered holistically because using them together gives an added value in comparison to using them separately. And there’s no better illustration of our working culture and how we combine these techniques than the Katayuno.

The Katayuno is a weekly open event we organize at our office every Tuesday morning. During the Katayuno, we pair code katas to learn TDD while enjoying a freshly baked breakfast.

The jargon

If you didn’t understand the last sentence above, “pair code katas to learn TDD,” I’ll explain.

A code kata is a small exercise in programming that is meant to help us programmers sharpen our skills through practice. Therefore, a kata is the ideal playground to learn and develop our skills in Test-Driven Development (TDD).

TDD is a software development process that uses tests to make the design emerge by following the red/green/refactor cycle.

One word of advice: it is a good idea to pair the katas. Pair programming is an agile software development technique in which two programmers work together at one workstation. The driver writes the code while the navigator reviews what is typed and keeps the flow.

Pairing has many benefits, including the power to promote knowledge spread, as both partners will organically teach each other. Also having two developers review the same code and discuss technical decisions leads to better designs.

The timeboxing is important, so we like to use pomodoros to count time. The pomodoro technique uses a timer to break work down into intervals, traditionally 25 minutes in length, separated by short breaks. It helps us to focus and minimizes interruptions.

To make the definitions easier to understand, and to bring them to life, we put together an example of a real kata for you in the next section of this post.

The kata

So for this kata I recruited a pair and spent two pomodoros, which is the time we use in Katayunos. We’ll be using Ruby and Rspec.

Two-player card game is an abbreviated version of the Trading Card kata.

I prepared the exercise to the “table ready” state, from where we can start running the game, as I thought you would enjoy the gameplay more than the table preparation. first commit

The rules of the game are as follows:

Before starting the pomodoro, we hold a conversation in order to get context and set the focus of the pomodoro. It is important that both participants are aligned on the context. Sometimes it is a good idea to spend a whole pomodoro ensuring both participants understand the task and deciding a strategy.

We choose to use the first pomodoro to address the design of the first turn.

First, we write down what “the first turn is prepared” means for us (Assert):

Next, we decide what needs to be done for this state to be achieved (Act):

Then, we make a minimum effort to make this compile in the test (Arrange):

Finally, in the Game class:

In TDD, you are red when you write a test that fails to expose a lack of functionality. At this point we are red, because Game::start does not prepare the first turn. commit

Our goal now is to make the test turn green, again writing the least required. In our first expect, the player must have four cards in their hands:

This code forces us to create the functionality of drawing cards for the player. So we write a unit test:

And make it compile creating Player::draw. At this point, both the end-to-end and unit test are red, and the trace points to that Player::draw.

After having this method implemented:

The unit test and the first expect of the end-to-end will turn green:

Now, we repeat this cycle until all expects are green. commit


After a short break, we start the second pomodoro, during which we focus on refactor. Refactor is the practice of restructuring code without changing its behavior to improve the design.

This time, my colleague will drive since it’s healthy to switch roles often when pairing.

Among others actions, we extract a private method Game::deal_hand to make Game::start readable:

We are aware of that reckless player assignation. As soon as we write a test where both players must participate, this flaw will be revealed and amended. This process is called triangulation.


It’s important to remember that the goal of the katas isn’t to complete them. In fact, katas are discarded after completing the timebox and started from scratch again, often with another pair.

The true intention of katas is to learn. In this case, over the course of two pomodoros we learned how to use tests to organically design a game, not to mention we also had a great time :)

Join us at Katayunos!

Meri is one of our software developers. She also collaborates as a Katayuno facilitator.