The Game of Test-Driven Development

A Day of Coding and Experimentation Above the Rooftops of Vienna

On a crisp November Saturday, about thirty developers gathered at SQUER's Vienna office to practice Test-Driven Development. We learned, experimented, and rediscovered the joy of crafting code. One key takeaway stood out for me: it is okay to learn from things you make and then throw them away.

November 2025

The event was part of the Global Day of Coderetreat.

On November 8, 2025, around three dozen developers gathered for a full day of focused practice at SQUER's Vienna offices for a Code Retreat on Test-Driven Development (TDD). The event ran from 9:00 to 17:00 and was organized by SQUER, with Tricentis as the second sponsor. A Code Retreat is a day dedicated to sharpening software craftsmanship: you solve the same problem in short iterations, reflect, reset, and try again. Each time with new constraints and new partners.

SQUER's Paul Rohorzka introduced the Code Retreat.

The Atmosphere above Alsergrund

SQUER hosted us on the sixth floor of their space in the newly renovated Althanquartier complex surrounding the Franz Josef railway station. Despite the gray skies, the view over Vienna's ninth district Alsergrund was astounding and set an airy mood. After coffee and pastries, we switched to workshop mode. This kicked off a day of experimententation without pressure. We had playful discussions, and rediscovered the small joys of writing good code with others.

The view from the terrace was stunning.

Focus on TDD

SQUER's software evangelist Paul Rohorzka opened the day and then handed over to our trainer, Ivett Ördög. Among the participants was Dr. Peter Kofler, the Code Cop. He originally introduced me to coding dojos, TDD, and this style of code retreat back when I worked at Sportradar.

The core exercise for each session was implementing parts of Conway's Game of Life using TDD. We used the "ping-pong" style of pair programming, popularized by practitioners such as Emily Bache, where one person writes a failing test (red), the other writes the minimal code to make it pass (green), and then the code needs to be refactored. Once that is done, you switch roles. In a typical 35-minute session, each person would write three or four tests. You learn to think on your feet, express intent cleanly in tests, and truly listen to how your partner reasons about code. And you did not have to finish anything. The journey is the reward!

We could reassure ourselves of the exact rules of Conway's Game of Life.

Learning Through Constraints

Each round introduced fresh constraints and limitations. Some were straightforward like "assume an existing interface; mock it, don't implement it." Others were delightfully adventurous: in one session, pairs weren't allowed to talk. One developer acted as a very literal AI, while the other wrote "prompts." The "AI" implemented exactly what was asked, even when the prompt's flaws became obvious. It was a pretty good way to expose assumptions, ambiguity, and how much meaning we pack between the lines when we speak.

I was happy to take part in the Code Retreat

Shifting Mindsets Due to AI

This was my second TDD training this year. The first was in January in Linz. It is striking how much the mindset has shifted since then. AI has landed with force. Several developers admitted that writing boilerplate without an AI assistant now requires real effort. That dependency surfaced during the exercises and retrospectives: useful in day-to-day work, yes, but also a reminder to keep our fundamental skills sharp.

We coded hard for no money, so hard for it, honey!

What I appreciated most was the safe experimental sandbox. In day jobs, process and delivery cadence can crowd out exploration. Here, we could try things, discard them, and try again.

SQUER had set up a really cool environment for work.

Each session ended with a short retrospective. We stood in a circle and shared what happened, what we noticed, and what we might change next round. Those tiny reflections add up: the practice clicked for most of us, and some of us mentioned how blind spots had surfaced. We could exchange our experience and let our ideas travel across the room.

It was surprising how quickly each session went by.

In every session, we changed partners and coded using TDD.

Whole-Day Retrospective

We closed with a broader retrospective. Our trainer Ivett Ördög asked us three questions. We discussed in small groups and then presented. I had the honor of speaking for my group. The first person "I" in the notes below represents the speaker at the time, but could often be read as "we."

Ivett asked us three questions to recap the day.

What surprised you?

• "I've pair-programmed before, but never ping-pong. Writing tests first and trading roles clicked for me. So much shared context emerges without heavy hand-offs."
• "I solved the challenge of the hexagonal Game of Life. I had no idea you only need two directions. It was easier than I thought. The hex grid didn't make it harder than the regular square grid."
• "I thought there was one right way to approach the problem, but together we found different solutions that were sometimes better. The diversity of backgrounds and thinking really helped to get different perspectives."
• "I was surprised how dependent many of us are becoming on AI. We might be losing some basics when we rely on it for boilerplate."
• "I've developed the Game of Life inside-out and outside-in, but this time I saw someone implement it from what I can only call from the middle-up. And it was also Game of Life using an 'infinite board' instead of a fixed-sized one."
• "I was surprised how hard it was for me to get back into real discussions about the work, and how delightful it felt once I did."

In the final retrospective, we split up in groups and answered Ivett's questions to reflect on the whole day.

What did you learn?

• "I like TDD, but I don't enjoy pure TDD when working in an existing codebase."
• "It's okay to throw things away and learn from them." (This refers to code, not material things. Please don't litter!)
• "I should do more TDD."
• "Listen properly and really understand what the other person is saying."
• "I was new to TDD; today was a good learning experience and introduced a fresh mindset."
• "Throw prototypes away before they reach production!"
• "So many people hold misconceptions about TDD; it's seen as limiting, but it doesn't slow you down, it enables you!"

We had snacks and pastries to keep us going through the day.

What will you do differently?

• "Apply the ping-pong principle in my programming practice."
• "Slow down in development to craft a solution I'm genuinely happy with."
• "Use TDD more often."
• "Use testing more deliberately in general."

Retreat into Energy - Move Forward by Playing a Game

I left energized. Code Retreats provide rare spaces to practice, not to release finished code; to re-learn fundamentals; and to enjoy the craft with other people who care. Maybe test-driven development is a bit like a game, you can keep trying until you get it right. Perhaps this makes TDD even like the Game of Life. Simple rules create complex behavior, and with each small iteration, something unexpectedly alive begins to emerge from the code. (Or maybe, I'm just high on coding.)

If you've never been at a code retreat, I highly recommend trying one. I have the feeling, you won't regret it. And if you'd like more from our facilitator, check out Next Increment with Ivett Ördög on YouTube.

Many thanks to SQUER for hosting and to Tricentis for supporting the day. Most of all, thanks to everyone who showed up, paired up, tested, coded, deleted, and learned together.

The office was in the large complex at the Franz Josef railway station: hard to believe that only a short while ago, this was a massive construction site.