Code Retreat and Pair Programming

[Ionut G. Stan]

Hi all,

This is my first email on this list, so a cheerful hello to everybody.

I'm writing to ask you something that I'm not 100% sure it belongs to this group,
but I believe you can answer it.

Saturday, I'm going to take part of a Code Retreat event. It's the first that I'll
attend and the first one organized by this group that I've recently become a
member of.

The person who organizes this says, in the announcement email, that the session
will be composed of 3 iterations, one hour each. Also, she says that we will do this
in pairs, following the pair programming methodology. But I don't really understand
when will the pairs switch? Should it be after the iteration? In which case, 4 iterations
will be better. Should it be, let's say, after 30 minutes?

I think the second option is not really viable, as the second developer, who begins
coding at half of the iteration is not starting from scratch, which I think is a key point
in code retreat. So, the first option should be better.

Anyways, code retreat should be about experimenting, and someone who was a copilot
in an iteration with a good developer, may have a block when is his turn to code. Is this
normal? Also, when should I, as a copilot, interrupt my pair when she's experimenting
with her code? I may think that she's doing something wrong, but she just wants to
experiment with it.

How does code retreat and pair programming fit together?  What's your opinion?

Thanks in advance for your answers and I hope I made myself clear.

-- 
Ionut G. Stan
I'm under construction  |  http://igstan.blogspot.com/

[eco...@gmail.com]

Hey Stan,

what I would recommend when pairing, actually I would recommend it always as it is great fun, is to use the ping pong approach that Dave Hoover coined some time ago.

While pairing you keep on switching roles (driver, navigator) on a test by test case. You write a test, it fails, you pass the keyboard to your pair. He codes to pass that test, codes the next test and passes you the keyboard.

Simple, and very fun to do. Coding becomes like a little race between the two of you.

Cheers,

Enrique

[Steven Smith]

That's what we do as well and it works very well.  The only time we don't is when we're getting very new apprentices up to speed, but within a couple of weeks they're ping-pong-ing too.

Steve

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[Mike Bria]

Hi Ionut,

I'm not sure if you'd be better switching up at iteration boundaries
or sooner, but I'd be interested to hear about what you try and how it
works out.

One thing I will say about your "co-pilot"/"interruption" questions -
good pairing, particularly in the case like yours where neither person
is any more familiar with the problem space than the other, isn't a
really "pilot"/"co-pilot" situation, but rather is more of a "equal
participants" interaction. Other words, you're both experimenting
together, discussing, passing ideas back and forth. So, the rules of
"interruption" basically default to your usual conversational
etiquette.

I'll also agree with the others that ping-ponging is a great way to
keep this interaction effective (and fun)!

Cheers
MB

[Olof Bjarnason]

2009/6/19 Ionut G. Stan <ionut....@gmail.com>

I Ionut,

I've only paired a little but I'll share anyway. (I've also tried remote pair programming with Simone search the archives, but that is another discussion)

The pilot wrote tests and made them pass / refactors, that is TDD:ed. The copilot asked questions, and pointed out typos and such. But mostly the copilot just watched/listened. Also it felt natural for me to keep explaining the test while I typed it, when I was piloting.

We then switched roles after 10-15 minutes.

It would be fun to try the ping-pong way of pairing that many have suggested already.

 

-- 
Ionut G. Stan
I'm under construction  |  http://igstan.blogspot.com/

--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english

[Michael Norton]

As a somewhat "seasoned" code retreat participant (been to a couple), I'd like to offer the following:

Keep the cycles to 30 minutes and switch pairs each cycle - this keeps it fresh and moving

Use TDD/BDD and use ping-pong (or carousel) pairing - this allows you to work as a team and it puts some structure around when to change pilot/co-pilot.

Pairing is collaborative; if your partner is blocked; talk them through it. If need be, show them what you're thinking.
If they are experimenting, ask them to talk you through it and help them with the thought process.
Code Retreat is about the journey. It is not a competition. Experimentation begets learning; go with it.

I've even done "combative ping-pong" which can be a lot of fun.
In this style, your objective is to write the least amount of code possible to get the test to pass. And I mean the least. Then write a valid failing test that forces your pair to do as much work as possible.
We did this in a carousel once. I expected the end result to be a dirty mess, but the end result was a simple, functional design with clean code. And we had a lot of fun with it.

Be sure to do a retrospective at the end of it all; what went well; what did not go well; what did we learn?

Have FUN!

http://docondev.blogspot.com/2009/03/code-retreat-2.html


Michael "Doc" Norton
http://docondev.blogspot.com/ - blog
DocOnDev - twitter

On Fri, Jun 19, 2009 at 10:07 AM, Ionut G. Stan <ionut....@gmail.com> wrote:

[Ionut Gabriel Stan]

Hi guys,

Some aftermath impression after yesterday's code retreat meeting (as
Mike Bria suggested). Sorry for the length of the email, I squeezed it
as much as I could.

First of all, a little presentation of what we did.

The problem to solve was Conway's game of life. Each iteration was one
hour long, pair switch happened (or should have happened) each 10
minutes. There was no TDD in the beginning, as the organizers
considered it was too much for a first time session of pair
programming, also some of the people had never done unit test, let
alone TDD. We also had several rules to respect when writing the code:

- meaningful method and variable names
- each method should have at most 6 lines
- no comments in the code

Now, my impressions.

Pair programming was a little different than I thought. The fact that
my pair and I had somewhat different styles of coding (and I'm not
talking about the place of the curly braces, but rather the structure
and organization of the program) wasn't that nice. There were times
when I felt I wanted to erase pretty large chunks of my pair's code.
It wasn't because he's way of doing things was worse then mine,
because mine wasn't that effective after all. He was pretty much an
algorithm guy, while I was pretty much an API/DSL guy and I believe
here laid the problem. These differences made things a little bit
harder. At some point we didn't even respect the pair switch interval.

Some other thing that I noticed. If you're coding with someone, you're
in a team, and a team is judged by its combined result, especially
when you're switching pairs inside the same code retreat iteration.
That means if you don't like something about your pair way of doing
things, you have to tell him. I didn't really do that and as a result
I didn't like when the organizers (masters in the software craftsmen
parlance?) pointed out flaws in our program design. My final sentiment
was that I'm not that much of a team guy, which probably has to do
with the fact that I'm the only programmer at my day job for over an
year and a half.

I liked thought the fact that I could bounce ideas with my team mate.
Especially related to the algorithm. He pointed out some nice ways of
doing things, while I came with others. As I thought before, and now
saw with my eyes, a program developed within a pair is likely to have
less bugs then one developed on your own.

Being a first time session of code retreat we only planned for 3
iterations, from which the last one was what I believe you guys call a
carousel. We got a projector connected to one of the laptops, and one
of the masters began the iteration. He wrote the initial test method
after which he implemented the method to pass the test. All in the
spirit of red, green, refactor. Next, someone else came and wrote a
test, then someone else came and wrote some code to make the test
pass, and so on. This was quite nice because we were only 6 people and
we could easily share ideas. The other thing is that we used C# for
this final iteration, while my colleague and me don't have that much
knowledge of the language (we can read it, but we feel sloppy when
writing it), but we were helped when writing the code and in the end
everyone was equal. This final part proved to be enjoyed by everyone.
Someone even asked why didn't we start with it.

In the end I liked the meeting and I discovered that I also have to
hone my social skills in order to have great pair programming
activity. Knowing *just* about TDD, DSLs, patterns, naming
conventions, algorithms and such won't help me much when pairing.

We're planning the next meeting somewhere in the mountains. We want to
rent a chalet or something and spend a full weekend doing pair
programming, code retreat and the like. So if someone wants to see the
Romanian Carpathians and do some pair programming here in Romania,
drop me a line and I'll let you know when we're going to do it. I know
Corey Haines wants to spend some time pair programming here. Oh, he's
the one that sparked all these, when he evangelized about pair
programming, code retreat and other concepts at a previous meeting of
ours, so a big thanks goes to him.

Also, thank you guys for the previous emails, about ping-pong TDD and
other ideas. I'm going to try out the ping-pong part the next time.

[alecslupu]

HI!
i have been yesterday on the code retreat meeting, and i have paired
with Ionut. I am that "algorithm guy" he's speaking about.
honestly, i have found the concepts like TDD (though i knew about the
functional tests, but i have thought they can be written after the
initial developing process ended), but at this point, i have learned
that TDD can help you out for many, many headaches. Even if we haven't
agreed on pairing strategy is because none of us knew exactly what
that meant and also, because we were thinking too far, i do share the
impressions about this meeting and the things that i have found out in
there. I think i have to mention that this meeting was the first time
when i have got involved into a craftsmanship session.
I hope me and Ionut could find some time in order to make some more
pairing sessions in private, in order to improve our social
skills :).

I loved that carousel thing, and i have found that "C sharp doesn't
hurt".

I would like to end up my first post into this group by thanking to
the organizers, to Corey, and to Ionut for the invite.
By the way: when is the next meeting in romania ?

Alecs

> >http://docondev.blogspot.com/- blog
> > DocOnDev - twitter
>
> > On Fri, Jun 19, 2009 at 10:07 AM, Ionut G. Stan <ionut.g.s...@gmail.com>

[Curtis Cooley]

On Fri, Jun 19, 2009 at 7:24 AM, Steven Smith<ssmith...@gmail.com> wrote:
> That's what we do as well and it works very well.  The only time we don't is
> when we're getting very new apprentices up to speed, but within a couple of
> weeks they're ping-pong-ing too.
>
>

I strongly recommend this as your primary paring technique. Very
effective in keeping both pairs actively involved and the
communication level very high.

With new developers I modify it slightly. I write the test and the
newer developer gets it to pass. That way I'm controlling the pace and
progress towards task completion, but the new guy is active and
writing code. Sometimes I'll refactor and sometimes I'll walk him
through it. Usually it depends on how many times he has to open the
refactor menu to find extract method before learning it's alt-m :)
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.

[Alexandru-Emil Lupu]

Hi!
I think that the developers should fail almost every pair programming, until their pairing session will be like a naturally conversation.

A tight exercise must be first completed by two craftsmanship masters, in order to show that the exercise is finish-able. This  exercise in the pairing session, will discourage some, but encourage others. By doing this, we can get the coding standards higher, being helped by the motivation of the developer itself.

I would put a question like this: "How determined are you to improve your skills ?".  Depending on the developer's answer, i might tell him either to join and practice, either not to punish itself and leave.

For the moment, i am not a craftsmanship master. I would like to be. But for that i would need to find my pair to practice, and improve our skills.

Alecs

--
As programmers create bigger & better idiot proof programs, so the universe creates bigger & better idiots!
I am on twitter:
http://twitter.com/alecslupu
I am on linkedIn: http://www.linkedin.com/in/alecslupu
Tel: (+4)0748.543.798

[AlexBolboaca]

Hi all,

First, for the people who don't know me in this group, I was one of
the organizers and the one called in the previous mails "master". I
don't think of myself as a master; I am an aspiring software craftsman
much like the others, the only different thing being that I had the
opportunity to have a mentor a few years ago, one who taught me how to
write clean code. I've always wanted to pass this knowledge to other
programmers, but I didn't know how - until Maria Diaconu and I
organized the first Romanian Agile conference (www.openagile.ro) and
we met Corey Haines. He told us about the code retreats, coding dojos,
coding katas etc. So we thought: why not do this ourselves? So this is
a little bit of context related to what happened on Saturday in
Bucharest.

From the organizing perspective, we took some decisions that would
make easier the learning process that happens during a code retreat.
We decided on three iterations instead of six, as I know it's the
"standard". We decided on providing with a few simple things to
practice, related to writing clean code. Pairing was important, and we
knew the participants have never paired before. Ideally, we would have
introduced TDD from the beginning, only people didn't know much about
it. The idea was as much for the participants to learn about TDD, pair
programming, emergent design and clean code and for us to learn what
it means to organize something like this and how should we prepare.

The first two iterations were meant for the participants to experiment
this new situation - pairing and writing clean code. We looked at how
the teams were doing and tried to give them hints on writing cleaner
code. Not surprising for us, pairing feels a little bit awkward the
first times, but it's one of the best way to improve the communication
skills and your code at the same time.

For the third iteration, we thought of showing a little bit of TDD. I
started the implementation and then asked someone else to come and
write code and so on. While this was for participants the best part of
the day, I believe that the pairing before that was very important.
People learn better *after* they tried it themselves.

In the end, I believe the event was successful at showing a few very
important concepts and methods of work. However, there is a long way
ahead. We weren't able to implement much of the problem in the given
conditions, which clearly shows that everybody in the group needs more
practice. I think that we know now how to do it, and we understand
that it's important. I can only hope more people will come to the next
meetings.

So, the next plans are:
- practice, practice, practice - for everyone (including myself!)
- we are already in the process of organizing a new, longer and better
code retreat in the mountains - will be announced on the Romanian's
community web site - www.agileworks.ro -, like all the other events
- as soon as we can convince a real master to come, I can't wait to
learn more while he will drive a new code retreat/coding dojo or any
other such event.

So this is my view on the event. I hope our community starts to grow,
and we will have more to report in the near future. Thanks for the
feedback and for the support from the community.

Alexandru Bolboacă
Aspiring Software Craftsman
www.alexbolboaca.ro
www.agileworks.ro
www.mozaicworks.com

[Michael Norton]

Alex:

I commend you on your efforts. This is great!!

Perhaps for your next Code Retreat, you can start with Randori style and use that to show the group how TDD and pairing can work. You can also "stage" the Randori with a select group of folks who are more proficient at Clean Code. Then, after showing how it is done, run the iterations. Encourage folks to pair with some of the more seasoned/experienced developers.

I personally had the opportunity to pair with Both Corey Haines and JB Rainsburger. The experiences were significantly different, but both very rewarding.

- Doc

[AlexBolboaca]

Yes, Maria and I thought about that and I believe that's he best way
to go, because participants need to learn first how to do TDD and to
write clean code. Only then the code retreat will become practice.
As for the select group of folks, it's hard to find them. There are
only 5 signers of the manifesto from Bucharest, two of them being me
and Maria. If I do find them, it would be great to do this. However,
as things stand now, we would rather look to bringing some craftsmen
from abroad - feel free to pressure anybody you know or think about
coming to Bucharest ;).

Thanks for the praise,

Alexandru Bolboacă
Aspiring Software Craftsman
www.alexbolboaca.ro
www.agileworks.ro
www.mozaicworks.com

On Jun 22, 11:48 pm, Michael Norton <mich...@docondev.com> wrote:
> Alex:
>
> I commend you on your efforts. This is great!!
>
> Perhaps for your next Code Retreat, you can start with Randori style and use
> that to show the group how TDD and pairing can work. You can also "stage"
> the Randori with a select group of folks who are more proficient at Clean
> Code. Then, after showing how it is done, run the iterations. Encourage
> folks to pair with some of the more seasoned/experienced developers.
>
> I personally had the opportunity to pair with Both Corey Haines and JB
> Rainsburger. The experiences were significantly different, but both very
> rewarding.
>
> - Doc
>

> > community web site -www.agileworks.ro-, like all the other events

[AlexBolboaca]

Hello,

For anybody who's interested, we are organizing the second code
retreat in Romania, near Bran. Details here: http://www.agileworks.ro/bucuresti-agile-scrum-more/
and registration here: http://www.meetup.com/The-Bucharest-Agile-Software-Meetup-Group/calendar/10769109/