We may already know a lot, but we don’t know everything yet! That’s why we’re always open to new things. Twelve of our tool developers from the game technology studio took part in the first Goodgame Studios Code Retreat in order to improve their skills in test-driven development and pair programming. Urs, the organizer and host of the event, comes from it-agile and is currently working as a Scrum Master at Goodgame Studios. Here he explains the basics of a Code Retreat.
Two minds, one machine.
The first lesson that the developers from our game core, technical integration, and profiling teams learned in this workshop is that pair programming is possible and effective. Regardless of whether an expert and a newbie are working together or two veterans are sharing the computer, each partner can always benefit from the other. They share information about a new tool, bounce their ideas off each other, and draw upon their partner’s knowledge. If one has a question, their partner either knows the answer or they can find it together.
TDD. No compromises.
TDD stands for Test-Driven Development. “Test-driven” development is when the developer starts their project by writing a code snippet which will test the result of the program. The program itself doesn’t follow until later. The tasks alternate between developing new tests and expanding the program, creating a rhythm. The tests tell the developer if the program has met all of their expectations, or the expectations of the customer as the case may be. This lets the developer change and restructure the source code at any time without having to worry about its correctness. If something doesn’t work, they are the first to notice it, not the customer. That gives the developer the courage to experiment and always learn new things.
New code. Every time.
Every 45 minutes the pairs switch, delete the old code, and start from scratch again. The participants work on the same exercise each time. Each round brings them one step further and teaches them something new. The conditions change for every round as well. The first round focuses primarily on solving the problem using TDD and pair programming, then the host increases the difficulty for each subsequent round. This means that, for example, the pairs often need to switch back and forth between active and passive roles, or they have to develop such simple designs that it takes them two minutes at most to write the test and fulfill its requirements. In this way, each round presents a new challenge, even if the programmers are already familiar with the task.
The host, an experienced software developer, is always on hand to offer his assistance. He might help one pair to maintain dialogue, another to solve a puzzle, and a third pair to work in more detail. Even if the task is always the same one, each participant learns something different.
We’re talking about code.
After each round, the developers take a short break to discuss their challenges, solutions, and new ideas. What have they gained, what have they rejected? This informs the entire team about any particularities or problems one of the pairs discovered so that everyone can apply this knowledge to the upcoming rounds – and to their daily work.
By Urs Reupke, agile coach and coder