The semicircle (episode 4 — Driver/Navigator)

You are late, but it is just getting started. You slip into your chair as quietly as you can. Hardly unnoticed, because the person who is standing near the projector calls you out, asks your name, and explains to you the purpose of tonight’s exercise.

“We are doing a mob, using TDD, using the Bowling Score kata. That guy,” he points to the person who is sitting at the laptop, “he’s the Driver. The Driver writes the code, but he doesn’t think. You are the Navigators. You tell the Driver what he should code. We change Driver every five minutes.”

“OK! Thank you. Sorry for being late.”

There are 8 of you sitting in a semicircle facing the wall monitor. Two people have their laptop open on their laps. It seems that everyone knows each other. Quite young people, except for one guy who seems to be over fifty. Audrey had said she would come, but she must be late because of work. You smile. You are a little anxious to have left work right at six with all there’s to do there. Thank goodness this meetup is two blocks from the office.

“We’re off!”
“What are we going to do?”

The driver is sitting at the keyboard looking at the others with a mocking attitude. Someone says:

“Write a test.” “What test?”
“Any one. Test that two plus two equals four. We want to see a test running.” “First make it fail. Write two plus three equals four.”

The Driver obeys. Expected 4, but got 5. At the bottom of the screen, in the status section, the message bar turns red.

“Now make it pass.”

He makes the test pass. The bar is green. “And now?”

The alarm sounds on the facilitator’s cell phone. Everyone moves one seat to the left,
including you. You are three spots from the Driver’s seat, a bit worried, but you tell yourself that you still have time to get in the game.

The person who just settled in at the keyboard is rubbing his hands and says: “So, I think we could start with the case of…”
The facilitator interrupts him mimicking the sound of a TV Game show buzzer. “Oh you do? It’s for the navigators to decide.”
Your neighbor to the left says calmly, “Let’s start with the trivial case where the player is only doing gutters. In that case, the score is zero.”

While the driver is aligning dozens of zeros in a list and fumbles while finding the left square bracket on the keyboard, you rack your brains trying to recall the rules of bowling, a game you’ve only played three times in your life. That was ten years ago.

The alarm sounds. Everyone shifts seats again.

The new Driver finishes writing the test and makes it pass. “What’s next?”
You go for it, suggesting, “Why not test what should happen if one of the throws is negative?”

Someone at the other end of the semicircle answers. “It could happen, but should we do that scenario before the other ones?”

Someone else adds “I don’t see how the machine that picks up the pins could communicate a number of pins smaller than zero.”

You reply. “If it’s a faulty machine?”

The discussion starts about the limitations of defensive programming. The facilitator raises his hand. “Hey!”
Everyone stops.

“The Driver has something to tell you!” The Driver smiles and says, “I’m bored.”
Someone to your left suggests, “Line up twenty shots without strike or spare. For example two and six, ten times in a row. The score will be eighty.”

The driver starts writing this test. Bell ringing, change of Driver.

The following Driver passes the test. You recognize the pattern he is putting in place in the code. You make suggestions that are well received. Everyone seems to be perfectly in agreement with the principle of writing the test before the code that will pass this test, so you don’t propose another approach. Curiosity.

It’s really less dark in this room than in the one you left behind your screen saver at work. It looks like all the obstacles are lifted in advance, made manifest, exposed in full light. Granted, the room is very small, even tiny, since the problem is particularly simple, and there are eight of us in this room. Six if we exclude the facilitator and the driver who don’t do the thinking.

Someone says, “Can you write Gutter with two t’s?” “Ok.”
“It doesn’t make a difference.”
“We haven’t decided, but are we coding in English?” “We’re coding in Java!”
“You understood me!” “OK for English.”
“OK then correct English.”

It’s your turn to be the Driver. You have no idea what should happen next. But that’s not the worst of it. You already have to get used to this keyboard and this environment, which are so different from what you have at work.

Someone is proposing to deal with spares. You follow the group’s instructions. You don’t see exactly where this kata is going, but you’re doing pretty well. As soon as you look for a shortcut in the IDE, someone tells you what it is. That’s cool. On several occasions, the requests of the participants are so conflicting that you don’t understand anything the group wants, so the facilitator intervenes.

We deal with the case of strikes. The design that the group chooses is surprising. You wouldn’t have coded the kata this way in the first place, but you think the approach is pretty consistent. And anyway, the last time you wrote a recursive function was several years ago.

What is surprising about this room isn’t so much its now perfect clarity but the total absence of heterogeneous objects on the floor and around the pillars. Everything is in its place. This gives an impression of calm, like a positive vibe. You sense that new things are possible, unpleasant surprises are not. We can see the obstacles coming from a distance. The most fascinating thing is that it seems that the room has a perfectly
adjustable architecture. Not long ago, the room was just a narrow corridor and now it’s much larger.

Someone in the group pointed out a pattern, which everyone was guessing at but no one had found a way to express. “This bowling game is like a state machine, with some complicated states, but only two possible transitions.”

And at that moment, the room changed shape, it became square, with three pillars in the middle and a triangular table.

Whenever the group embroils itself in discussing what to do next, the facilitator steps in and suggests trying to make one or the other of the various hypotheses work in a time box rather than having endless discussions.

The code is so well tested that it seems impossible to introduce an error without it being immediately apparent. You are looking for places where it could fail. On two occasions, you have a test written that should fail and show that there is a bug, but the test passes.

We come to final edge case. There is a discussion about what the maximum score can be in Bowling. One of the participants opens his laptop and does a search.

Someone says, “It’s complicated. Up until now, we didn’t need to count frames. Now we do.”

The room just got a new addition: a whole new floor. It’s a bit of a shock. But we can still see very clearly. And the group seems perfectly confident that the structure can continue to improve.

You realize now that the mobility of the elements in this room, this flawless flexibility, is mainly due to the fact that the room is permanently lit.

The facilitator announces that the kata is over. They wrap up. The facilitator gives each person a chance to give feedback.

“Not bad. New approach. I prefer it to the one I used before to solve this kata.” “We didn’t handle the case of input errors, finally!”
“But it doesn’t matter…”
“I appreciated the moment when everything came together after we discovered that the frame numbers must be taken into account …”
“Yes. There are two steps where the design is twisted.” “We could do better …”
“Do we need all these tests really?” “You’re asking if we need it ?!”
“No refactoring without tests.”
“Without tests, we can’t really reason about the code!”

You ask to speak again. “Excuse me, I am not very familiar with TDD, but it seems to me that I reason all day about the code that I have in front of me. And it has no tests. At least no tests like the ones you write. Have you ever tried this approach, but without doing any tests?”

The facilitator smiles. “We tried once or twice. It went in circles.” Someone suggests, “Note that mob debugging could be interesting too.”
“Leave me out,” another person answers. “There wouldn’t be enough action.”

You find yourself with the group in the street, looking for a place to have a drink. You decide to follow the group. You still have questions to ask the facilitator.


(to be continued)
Previous episodes :
1 — If the code could speak
2 — See/Advance
3 — Communication Breakdown

Leave a Reply

Your email address will not be published.


This form is protected by Google Recaptcha