TITLE: The Rare Pleasure of Pairing
AUTHOR: Eugene Wallingford
DATE: June 01, 2010  9:39 PM
DESC: 
-----
BODY:
When my student team began the second iteration of our
project this morning, one member had no partner.  So
I jumped in to fill the void for half an hour or so.
When the missing student arrived, he joined us and
we worked as a trio.

What a treat!  Most of the time, I code alone, and far
too often the only code I work closely with is code
I have written.  Working with another programmer was
a lot of fun.  We talked as we studied and tried our
ideas about how the code worked out on one another.
Studying someone's code added a second dimension to
the fun, because neither of us brought much experience
with this part of the system to our pairing session.
That meant real study, and real learning.

Our programming session reminded me just how valuable
tests can be.  We bounced back and forth between the
class we needed to extend and its tests.  We would
study the code, come up with an idea of how it
worked, and then inspected the tests to confirm or
disconfirm our idea.  At one point, we were studying
a particularly confusing method.  We finally figured
out what it was doing and went to the tests to check
our understanding.  But there was no test to help us...
and there should have been.  So we wrote a test that
embodied what we thought should happen, ran it, and
-- voilé -- it passed.  That felt good.

The story my partner and I picked out turned out to
be effectively solved by the existing code.  Rather
than taking the easy way out, mark the story as done,
and grab another story card, we decided to clean up
the code a bit.  We were a bit disturbed at having to
study that confusing method so long and generally at
having to work so hard to understand the class as a
whole.  So we refactored the class to express the
code's intent more clearly.  The biggest product of
our clean-up was a helper class to structure the
parts of a journal entry and name them.  This meant
taking a horizontal slice of data that was originally
sliced vertically.  This clarified several of the
internal interfaces and even simplified one hairy
loop with an if statement that selected on value type
into two simpler loops.  Ahh.

Is the new code better than the previous version?  We
think so, but we won't know until the next developers
to touch it, whether others our ourselves, bump into
it again.  I will say that it is at least more explicit.
The intention of the code shows up in the names of local
variables and formal parameters; it shows up in blocks
that send messages to objects of the same kind.  It
shows up in tests that make finer-grained assertions
about the behavior of the system.  That feels like an
improvement to me and, hopefully, my partners.  We'll
know more soon enough.

I would love to have more chances like the one I had
today.
-----