You are here: Home » as3 » Rhyme Harder: an alternative pair-programming provocation

At March’s try{harder} Level Up conference, we did our usual day of code-retreat style pair-programming.

The intent is to pair for around an hour at a time with a number of different partners. All code is thrown away at the end of each cycle, because the focus is on process and reflection, not progress. At the start of each cycle you begin again on the problem, as if the code you’ve written previously had never been written.

Whether or not you should keep the understanding you gained is a more complex question; it’s impossible to unlearn, but by cycle 6 you’re generally pretty certain that what you learned in cycle 1 was not that useful after all.

Pairs can vary language and approach – we used Ruby, Python and AS3 – but there’s an emphasis on some kind of test-driven process. Test-driving can happen through conventional TDD, BDD or – our favourite at try{harder} – “TDD as if you meant it”, in which all production code is written in the test case.

We like the “TDD as if you meant it” approach because it forces you to defer committing to a definition of the solution in terms of classes, and we find that the code we write is often very different from the code we expected to write at the start of each session.

Why change the exercise?

In the past we’ve used Conway’s Game of Life as the provocation. It works well, but in some ways it feels too meaty (especially in AS3) – offering so much scope that it’s easy to vary sessions simply by shifting between the domains of the problem (the rules, the display, rendering, cycle controls and so on).

For the purposes of reflecting on tdd-fundamentals, clean code, method and variable naming, and so on, the provocation-problem chosen is almost irrelevant (provided it can be understood and held in mind without taking up too many attention slots). We were all set to use Conway’s Game of Life as usual, when, during a seminar about ‘hard to test’ code, we stumbled upon a smaller problem that led to the opportunity to reflect in more detail on the “assumptions and understanding” axis of test-driven programming. We’ve nick-named the problem “Rhyme Harder” and it goes a little something like this:

Rhyme Harder

1. You are building a game to teach children (or second language students) about the alphabet letter names, in relation to simple phonics (sounds of letter combinations).
2. The player is offered a display which shows each of the 26 letters of the alphabet.
3. The player “wins” by clicking a sequence of letters which starts with A, ends with Z, and includes each of the 26 letters once and only once.
4. The sequence may not include any pairs of consecutive letters with names belonging to the same phonic group.

Phonic groups

Phonic groups pull together letters which have names which contain the same vowel sound – for example “A and K”, “B and C”, “M and N”. Phonic groups can potentially vary depending on country and region – “Zee and B” or “Zed and F”. In Scotland some accents would say “J and I” (so that the J rhymes with I) rather than “J and K”.

Opportunities for variation

In the first couple of cycles, most pairs were satisfied with exploring different ways of representing and checking “the rules”. Successive cycles revealed that the problem has plenty of scope for reflection and exploration – for example:

• Rules can be checked on a turn-by-turn basis, or only when the 26th item in the sequence is submitted
• Checking the move can return a “yes” or “no” result, or a result which contains all the next valid moves (which could be useful for hinting)
• It can be useful to explore how to open the way for sophisticated scoring options such as rewarding words spelled along the route

What I find most interesting about exploring these alternatives is that frequently we pass through an increase in complexity, while we unpick our assumptions, and come out the other side with a simpler solution. (Something I’ve also scribbled about before). The experienced reminded me that questioning my assumptions explicitly can lead me to more elegant, less unwieldy solutions.

Remembering to look down

I’ve talked before about “The MacGuyver Principle” in programming – in which the most important trait is the ability to just not look down. At the time I was thinking this way with regard to programming without tests, but pairing has led me to understand that even when I’m testing, I still spend a great deal of energy just trying not to look down. I’m wilfully blind to the assumptions that my tests make.

Robin Wilding, aka @redannick , gave a great presentation at try{harder} about the benefits of striving for less, not more, flow.

Flow - ‘wow, did 3 hours really just go past? I was totally in the zone, ah, wow, I really need to pee… ‘ – is how we get stuff done, but too much flow can allow us to stay suspended in wrong assumptions, Wile E Coyote style, only experiencing the crash to the floor when we finally, usually accidentally, look down.

Just… don't… look… down…

Pairing forces you to look down far more frequently. Which hurts. On the up side, often it allows you to notice that you’re about to run off a cliff, before it happens. The more conceptually complex the problem (or provocation), the more value there is in pairing, in my experience.

Suck it and see

If you’re heading to Beyond Tellerand – Play in Cologne in April (the conference that used to be FFK), come along to the post-conference pair-programming workshop on “Building intelligent applications” that I’ll be running on the 27th April.

It’s 250 euros for the full-day workshop (the price is not entirely clear on the workshops page, but if you click through to bookings you should see the correct price there).  I’ll be writing more about what you can expect from that workshop in the coming days – feel free to get in touch via twitter if you have any questions about it right now. I can’t wait to see you there!

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website Visit Stray on Twitter

Places I like

• Creative Badger

Tags

read my thoughts