TITLE: Becoming More Agile in Class, No. 2
AUTHOR: Eugene Wallingford
DATE: May 19, 2014  4:09 PM
DESC: 
-----
BODY:
After spending a couple of days becoming familiar with
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2014-05.html#e2014-05-14T16_52_10.htm">
   pair programming and unit tests</A>,
for Day 4 we moved on to the next step: refactoring.  I had
the students study the "before" code base from Martin Fowler's
book, <EM>Refactoring</EM>, to identify several ways they
thought we could improve it.  Then they worked in pairs to
implement their ideas.  The code itself is pretty simple -- a
small part of the information system for a movie rental store
-- and let the students focus on practice with tools, running
tests, and keeping the code base "green".

We all know Fowler's canonical definition of refactoring:

<BLOCKQUOTE><EM>
 Refactoring is the process of changing a software system in
 such a way that it does not alter the external behavior of
 the code yet improves its internal structure.
</EM></BLOCKQUOTE>

... but it's easy to forget that refactoring really is
<B>about design</B>.  Programmers with limited experience in
Java or OOP can bring only so much to the conversation about
improving an OO program written in Java.  We can refactor
confidently and well only if we have a target in mind, one
we understand and can envision in our code.  Further, creating
a good software design requires taste, and taste generally
comes from experience.

I noticed this lack of experience manifesting itself in the
way my students tried to decompose the work of a refactoring
into small, safe steps.  When we struggle with decomposing a
refactoring, we naturally struggle with choosing the next
step to work on.  Kent Beck calls this the challenge of
<EM>succession</EM>.  Ordering the steps of a refactoring is
a more subtle challenge than many programmers realize at first.

This session reminded me why I like to teach design and
refactoring in parallel: coming to appreciate new code smells
and quickly learning how to refactor code into a better state.
This way, programming skill grows along side the design skill.

On Day 5, we tried to put the skills from the three previous
days all together, using an XP-style <B>test-code-refactor-repeat</B>
cycle to implement a bit of code.  Students worked on either
<A HREF="http://codekata.com/kata/kata09-back-to-the-checkout/">
   the Checkout kata</A>
from Dave Thomas or
<A HREF="http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/">
   a tic-tac-toe game</A>
based on a write-up by Gojko Adzic.  No, these are not the most
exciting programs to build, but as I told the class, this makes
it possible for them to focus on the XP practices and habits of
mind -- small steps, unit tests, and refactoring -- without
having to work too hard to grok the domain.

My initial impression as the students worked was that the
exercise wasn't going as well as I had hoped it would.  The
step size was too big, and the tests were too intrusive, and
the refactoring was almost non-existent.  Afterwards, though,
I realized that programmers learning such foreign new habits
must go through this phase.  The best I can do is inject an
occasional suggestion or question, hoping that it helps
speed them along the curve.

This morning, I decided to have each student pair up with
someone who had worked on the other task last time, flip a
coin, and work on the one of the same two tasks.  This way,
each pair had someone working on the same problem again and
someone working on a new problem.  I instructed them to start
from scratch -- new code, new thoughts -- and have the person
new to the task write the first test.

The goal wass to create an asymmetry within each pair.
Working on the same piece again would be valuable for the
partner doing so, in the way playing finger exercises or
etudes is valuable for a musician.  At the same time, the
other partner would see a new problem, bringing fresh eyes
and thoughts to the exercise.  This approach seems like a
good one, as it varies the experience for both members of
the pair.  I know how important varying the environment can
be for student learning, but I sometimes forget to do that
often enough in class.

The results seemed so much better today.  Students commented
that they made better progress this time around, not because
one of them had worked on the same problem last time, but
because they were feeling more comfortable with the XP
practices.  One students something to the effect,

<BLOCKQUOTE><EM>
 Last time, we were trying to work on the simplest or
 smallest piece of code we could write.  This time, we were
 trying to work on the smallest piece of functionality we
 could add to the program.
</EM></BLOCKQUOTE>

That's a solid insight from an undergrad, even one with a
couple of years programming experience.

I also liked the conversation I was hearing among the pairs.
They asked each other, "Should we do this feature next, or
this other?" and said, "I'm not sure how we can test this."
-- and then talked it over before proceeding.  One pair had
a wider disparity in OO experience, so the more experienced
programmer was thinking out loud as he drove, taking into
account comments from his partner as he coded.

This is a good sign.  I'm under no illusion that they have
all suddenly mastered ordering features, writing unit tests,
or refactoring.  We'll hit bumps over the next three weeks.
But they all seem to be pretty comfortable with working
together and collaborating on code.  That's an essential
skill on an agile team.

Next up: the Planning Game for a project that we'll work on
for the rest of the class.  They chose their own system to
build, a cool little Android game app.  That will change the
dynamic a bit for customer collaboration and story writing,
but I think that the increased desire to see a finished
product will increase their motivation to master the skills
and practice.  My job as part-time customer, part-time coach
will require extra vigilance to keep them on track.
-----