The adventures of teaching computing science to university students

Simple (non-coding) TDD Game

I did an intro to test driven development (TDD) talk for TechMeetup Aberdeen last night and started with the ‘simple TDD game‘. I modified the game based on comments there, and made a few changes of my own. I used 2×4 Lego bricks as ‘rulers’ to be the ‘testing tool’ as this was easier than finding a large number of actual rulers. I also added the ’round zero’ as suggested to show ‘current state’.

I wanted to try this game as it was the only TDD game I could find that wasn’t also a coding exercise. I wanted a way to introduce TDD to an audience that held a mixture of developers and others. It also let me try the game to see how it might work with a larger group of students by way of introduction to TDD at a later stage.

My modified game ran as follows:

Three one minute rounds with variations:

The ‘dev’ folds the paper where a fold should be, say 1.5cm, or 3cm in from an edge, or in our case use a 2×4 Lego brick (3cm long), but you could also use paperclips or something else that’s readily available to use as the ‘inspection tool’.

The ‘tester’ measures the fold to see if it meets ‘spec’.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration. Keep track of your score on a piece of paper.

Round 0 – Throw it over the wall simulation

There is no talking

Sit back to back, or maybe at different tables in the room if space allows. We were in a lecture theatre so side by side seemed to work ok. The dev should fold as many as possible and hand them to the tester, who should test as many as possible.

(You could discuss ‘queue’ wastage comments too about ‘stack’ waiting to test, and feedback loop on ‘right/wrong’ during retrospective of round.)

Round 1  Test After Development (TAD) simulation.

In this round, have the dev make the fold and the tester measure the placement of the fold. If its right, then good work! However if its not exact, then the paper is given back for a refold. At NO time can the dev person utilise the ruler, this is only to be used by the tester.

Once they team get the fold right, the unit of work can be counted as complete.

Allow the dev to utilise the ruler, the ruler in this instance simulates the test by having the dev use this the fold should be right first time. The tester can help in whichever way seems suitable.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration.

Finish, review the scores, discuss the insights from the game and relax.

We did brief retrospectives after each round to see how many people completed successful and what the ratio of folded/correct was for the teams. We didn’t go into comparisons of team practices, but that would be something to consider for a longer session perhaps.

One team inadvertently tried batching the folds as pieces stuck together, which led to a brief discussion of whether this would be a good idea or not. After pointing out that when it worked, this was fine, but that ultimately you’d be letting through untested pieces as you’d only be sampling the output to some extent and feedback would be delayed. Batch size of one is the preferred process for this game.

Some discussion went on about how the game rounds related to programming, and tied into these questions which brought home the main issue of shortening the feedback loop between coding and finding out if there were errors, or bugs.

1) how many of you work with legacy code? (legacy == untested code from Michael Feather’s definition)

2) how do you know your code works?

3) how do you know the new code you just added didn’t break the old code?

4) when will you find out if something broke? (how long is the feedback loop?)

5) what would happen if you speeded up this feedback loop?

The game ran well with the usual fun and noise you get with a good game as people realise the changes they need to make, and cheers at results become known. The one minute rounds went by very quickly and teams that thought they might fold 25 or more pieces found they only managed 10 or so, of which maybe 3 or 4 were ‘to spec’.

In any case this is a game to try again with a larger class. I also want to find a way to do this with only Lego so that I don’t need to keep cutting/tearing up pieces of paper, which become a chore quite quickly. Still, nice game and maybe it’s fine as it is now.