TITLE: Speed Training for Software Developers
AUTHOR: Eugene Wallingford
DATE: December 06, 2004  6:57 PM
DESC: Speed work-outs are proven technique for running faster, even when it's seemingly all in fun.  Can we learn a lesson from running that will help us develop software better?
-----
BODY:
In making analogies between software development and running,
I've occasionally commented on sustainable pace, the notion
from XP that teams should work at a pace they can sustain
over time rather than at breakneck paces that lead to bad
software and burn-out.  In
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-07.html#e2004-07-15T12_07_34.htm">
   one entry</A>,
I discuss the value of continuous feedback in monitoring
pace.  In
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-08.html#e2004-08-27T13_09_04.htm">
   another</A>,
I describe what can happen when one doesn't maintain a
sustainable pace, in the short tem and over the longer term.

Not unexpectedly, I'm not alone in this analogy.  Erik Meade
recently
<A HREF="http://weblogs.java.net/blog/emeade/archive/2004/12/fartlek_increas.html">
   blogged</A>
on sustainable pace and business practice.  I was initially
drawn to his article by its title reference to
<I>increasing</I> your sustainable pace via the fartlek.
While I liked his use of the analogy to comment on standard
business practice, I was surprised that he didn't delve
deeper into the title's idea.

<A HREF="http://www.therunningadvisor.com/Training.html#fartleks">
   Fartlek</A>
is Swedish for "speed play" and refers to an unstructured
way for increasing one's speed while running: occasionally
speed up and run faster for a while, then slow down and
recover.  We can contrast this approach to more structured
speed work-outs such as
<A HREF="http://www.runnersworld.com/article/0,5033,s6-51-54-0-624,00.html">
   Yasso 800s</A>,
which specify speeds and durations for fast intervals
and recoveries.  In a fartlek, one simply has fun speeding
up and slowing down.  This works especially well when working
out with a friend or friends, because partners can take turns
choosing distances and speeds and rewards.  In the case of
both fartleks and structured interval training, though, the
idea is the same:  By running faster, you can train your body
to run faster better.

Can this work for software development?  Can we train
ourselves to develop software faster better?

It is certainly the case that we can learn to work faster
with practice when at the stage of internalizing knowledge.
I encourage students to work on their speed in in-class
exercises, as a way to prepare for the time constraints
of exams.  If you are in the habit of working leisurely
on every programming task you face, then an exam of ten
problems in seventy-five minutes can seem like a marathon.
By practicing -- solving lots of problems, and trying to
solve them quickly -- students can improve their speed.
This works because the practice helps them to internalize
facts and skills.  You don't want forever to be in the
position of having to look up in the Java documentation
whether
<A HREF="http://java.sun.com/j2se/1.4.2/docs/api/java/util/Vector.html">
   Vector</A>s
respond to <TT>length()</TT> or
<A HREF="http://java.sun.com/j2se/1.4.2/docs/api/java/util/Vector.html#size()">
   size()</A>.

I sometimes wonder whether working faster actually helps
students get faster or not, but even if it doesn't I am
certain that it helps them assess how well they've internalized
basic facts and standard tasks.

But fartleks for a software development team?  Again, working
on speed may well help teams that are at the beginning of
their learning curves: learning to pair program, learning
to program test-first, learning to use
<A HREF="http://www.junit.org/">
   JUnit</A>,
...  All benefit from lots of practice, and I do believe
that trying to work efficiently, rather than lollygagging
as if time were free, is a great way to internalize knowledge
and practice.  I see the results in the teams that make up
my agile software development course this semester.  The teams
that worked with the intention of getting better, of attempting
to master agile practices in good faith, became more skilled
developers.  The teams that treated project assignments as
mostly a hurdle to surmount still struggle with tools and
practices.  But how much could speed work have helped them?

The bigger question in my mind involves <I>mature</I>
development teams.  Will occasional speed workouts, whether
from deadline pressure on live jobs or on contrived
exercises in the studio, help a team perform faster the
next time they face time pressure?  I'm unsure.  I'd love to
<A HREF="mailto:wallingf@cs.uni.edu">
   hear what you think</A>.

If it does work, we agile developers have a not-so-secret
advantage...  Pair programming is like always training with
a friend!

When a runner prefers to run alone rather than with others,
she can still do a structured work-out (your stopwatch is
your friend) or even run fartleks.  Running alone leaves
the whole motivational burden on the solo runner's shoulders,
but the self-motivated can succeed.  I have run nearly
every training run the last two years alone, more out of
circumstance than preference.  (I run early in the morning
and, at least when beginning, was unsuitable as a training
partner for just about any runner I knew.)  I can remember
only two group runs: a 7-miler with two faster friends about
two weeks before my
<A HREF="http://www.cs.uni.edu/~wallingf/personal/chicago-marathon/">
   first marathon</A>
last fall, and an 8-mile track workout the day before
Thanksgiving two weeks ago.  As for the latter, I *know* that
I trained better and harder with a friend at my side, because
I lacked the mental drive to go all out alone that morning.

Now I'm wondering about how pair programming might play this
motivational role sometimes when writing software.  But that
blog entry will have to wait until another day.
-----