How to handle “TDD does not work in real life!” during code katas

Doing code katas to learn real-life TDD can at first look like a scam to many developers. So here are three techniques to maintain a constructive mood.

If you have run coding dojos, I’m sure you’ve heard developers say things like:

All these small tests are a waste of time in real life. A few broad tests and good debugging skills are all I need!

This is stupid! There is no point in returning hard-coded values just to make the test green!

This works well for toy projects but won’t work on real-life and large codebases.

I cannot remember how many times I heard this kind of comment. Unfortunately, coding dojos have a Karate Kid flavor. In this old movie, the hero, Daniel, is taught Karate by practicing chores like painting a fence, waxing a car, etc. Eventually, Daniel wins his combats by repeating the chore moves. Developers I know who have practiced enough code katas are now very effective with TDD in their day-to-day work.

Midway in Karate Kid, though, the hero loses faith in the teaching and rebels against his master.

Unfortunately, developers can rebel against their coach during a code kata too!

Wouldn’t you love it if developers always remained constructive during and after code katas?

With time, I’ve discovered three habits that keep everyone in a constructive mood:

1. Listen to understand
2. Explain the pedagogy behind the coding dojo
3. Mob as early as possible

Listen to understand

When people complain about the kata, they say it for a reason. It can be fear, fatigue, or other emotions. As long as we don’t understand where this is coming from, they will accumulate resentment against us. So instead of arguing, it’s a more effective strategy to get everything out. The critical skill here is listening.

There is a glitch, though. A dojo is a group session. It’s OK to spend a few minutes so that someone can explain their point of view. However, it’s different to let this drag on and undermine everyone’s mood. In this case, it’s better to schedule a private chat with the person. Here is how to say this:

I’m sorry, I have to interrupt. I’m very interested to understand your point of view. I’m sure it is an opportunity to make these sessions more effective. But unfortunately, our discussion is turning into a dialogue, and the dojo is not the place for this. Are you available after the session to continue this discussion between us? Would you prefer to schedule a meeting together later today?

Listening is not about bringing arguments or trying to persuade. It’s about understanding the other’s point of view. Sometimes, a compassionate ear is all people need to remain constructive in the dojo.

Explain the pedagogy behind the coding dojo

Thinking of applying what they practice in kata in real life might be too much of a stretch for them at first. Let’s accept that. Yet, we want them to be in a ‘learning mindset’ during the sessions. The goal is to have them forget their doubts during the session to learn. Then, once they have mastered the techniques, applying them in real life might not seem so crazy.

We could explain all the pedagogy theories behind the katas. As humans, though, we love stories. It’s hardwired in our brains. So I’ve found it is more effective to explain why katas work through stories. I tell these stories before the first code kata. After that, it’s a good habit to remind passages whenever it feels that attendees have forgotten.

The coding dojo was invented in early 2000 by a few French eXtreme Programmers living in Paris. Emmanuel Gaillot, Laurent Bossavit for sure, and maybe others. They knew how to practice TDD and XP practices in real life, and we’re looking for a way to teach it. They got some inspired by martial arts and sports.

A dojo is a safe practice place

Martial artists might get hurt in competition, yet they don’t expect to get hurt in the dojo. Sometimes, real-life programming hurts: we get emergencies, burn the midnight oil, and go under a lot of stress… But not in the dojo. Failing at the exercise does not hurt and is of no consequence!

As coaches, we must do all we can to keep the coding dojo a fun and enjoyable experience. We should often remind that the goal is not to “fix” the problem but to practice and that it’s OK to “just try something.”

A kata is a developer’s real-life condensed into 2 hours.

There is a spark of genius in the coding dojo format. It squeezes many aspects of day-to-day programming in 2 hours!

• In real life, developers discover significant specification changes about what they built… last week! During a code kata, we stick to YAGNI (You Aren’t Gonna Need It). We only make the current tests green. We deliberately do not design for future tests.
• In real life, developers often inherit code written by someone else. During a code kata, we deliberately switch the driver every 5 minutes.
• In real life, developers have to collaborate on design or code. During a code kata, we pair or mob all the time.

This shows the participants that the point of these weird kata rules is not to bother them. On the contrary, these rules make them practice and improve fundamental programming skills.

Deliberate practice of refactoring skills

If it hurts, do it more often!

In martial arts, katas are sequences of moves that people practice until perfection. The notion of deliberate practice is present in all sports. Here is an example I often share with participants:

Suppose you are training for a swimming competition and you need to improve your flip. Here are two practice strategies:

1. Swim for 1 hour, and practice a flip every 50 meters
2. Swim 5 meters, come back, flip, repeat

If you want to improve your flips, the second is more effective:

• you’d be less tired
• you’d practice more flips
• you’d have a shorter feedback loop
• your coach could provide you more advice

The same thing happens in the coding dojo. The muscles we want to develop during coding dojos are TDD and coding with baby steps. The coding dojo is an accelerated way to grow refactoring muscles.

An opportunity to practice to the book

Be patient, don’t try to speed up before you can perform a technique slowly and correctly. (My Aïkido sensei)

Here is something I often say to coachees:

Now that you are taking the time to give TDD a try, you might as well be as disciplined as possible! Once you can apply it by the book on easy problems, you’ll see how to apply TDD in real-life.

The dojo is a unique occasion to experience TDD by the book. Participants will experience what TDD feels like in an ideal setting. They will assess the benefits of such a way of working. This will help them envision integrating parts of it into their daily work. With time, they might even be able to transform their day-to-day work into this ideal!

Additionally, practicing a watered-down version of TDD might not be motivating enough.

Learning TDD is like swimming front crawl when you only know how to swim breaststroke. It’s slower at first, but it eventually becomes faster and less tiring. (Someone on Okiwi slack)

Mob as early as possible

The most straightforward way to debunk “It does not work in real life” is to actually do it “in real life.” Alternating between code katas and mob sessions helps coachees to bridge the gap.

We show mob programming to the teams during the first days of coaching (Someone on Okiwi slack)

The easiest thing to do is: pick a user story the team is currently working on and run a mob session around it. Many people are still reluctant to mobbing, though. They are afraid that they’ll be wasting time by working all together. So instead, ask them what work would create the most knowledge sharing or is critical to do well.

It’s even more true after a refactoring kata. Ask the team members for a piece of code to apply the refactoring technique they practiced. Again, it works great to get advanced refactoring techniques into a team’s habits.

Running mob sessions is a perfect answer to comments like “TDD does not work in real life” during code katas. So here is how I tease the participants:

This session is for practice in an accessible setting. We’ll apply it to your codebase during the next mob session. No one learns to swim at the deep end of the pool!

Three techniques

It’s no surprise that a topic called eXtreme Programming will generate strong reactions! The most common critique we receive when we train people to XP practices is:

XP and TDD will not work in real life!

Dealing with these remarks is part of our job. Next time you face this remark, remember to apply these three techniques:

1. Listen (more than you think)
2. Remind everyone of the pedagogy
3. Apply in the mob as soon as possible

If you know other techniques to deal with “It won’t work in real life,” please share them in a comment!

Happy coaching!

---

Here are other posts you might that could interest you:

• 5 technical agile coaching tips to fight exhaustion from laggards
• How to coach a team that has been burnt by bad TDD
• Coding Dojo Troubleshooting
• A coding dojo exercises plan towards refactoring legacy code
• 3 compounding benefits of mob programming that make it cost-effective

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!