TITLE: Small Differences Can Have a Large Effect
AUTHOR: Eugene Wallingford
DATE: February 03, 2005  4:01 PM
DESC: Runners know to limit the size of the change to their running regimen.  yet over time, they can make remarkably fast progress.  The power of compoiunding is at work.  Can software developers adopt new practices with similar success?
-----
BODY:
The temperature here has risen to unseasonably high
levels the last week or so.  That means that I am
able to run outdoors again.  And I love it -- fresh
air and open space are where the great running is.
I live where the American Midwest meets its Great
Plains, so by most folks' standard the land here
is flat.  But I live near a river, and we do have
gently rising and falling terrain, which makes
every run more interesting and more challenging than
any track can offer.

One thing I notice whenever I am able to break away
from track running is an increase in the variability
of my pace.  When I run on a short indoor track,
I usually find myself running relatively steady lap
times, drawn into a rhythm by the short, repetitive
environment.

Another thing I notice is that tend to run faster
than I'd like, even on days I'd rather take it
easy.  One good result of this is that
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-01.html#e2005-01-14T09_15_31.htm">
   I get faster</A>,
but the negative side effect is that I end up more
tired all week long.  That affects the other parts
of my life, like my teaching and my time with my
family.

You might think that a couple of seconds per lap
-- say, 52 second laps instead of 54 -- wouldn't make
that much difference.  That's less than 4%, right?
But a small difference in effort can have a big
effect of the body.  That small difference compounds
at every lap, much like interest in a bank account.
What feels comfortable in the moment can be less
so far after the fact, when that compounded difference
makes itself apparent.  There can value be in such
stresses ("the only way to get faster is to run
faster"), but there are also risks: a depressed
immune system, increased susceptibility to injury,
and the tiredness I mentioned earlier.

Most runners learn early to respect small changes
and to use them wisely.  They learn to mix relatively
easy runs and even off days in with their harder
runs as a way to protect the body from overuse.
Folks who train for a marathon are usually told
never to increase their weekly mileage by more
than 10% in a given week, and to drop back every
second or third week in order to let the body
adjust to endurance stress.

At first, the 10% Rule seems like an inordinate
restriction.  "At this rate, it will take me
<EM>forever</EM> to get ready for the marathon!"
Well, not forever, but it will take a while.
Most people don't have any real choice, though.
The human body isn't tuned to accepting huge
changes in endurance very quickly.

But their is hope, in the bank account analogy
above.  You may have heard of the
<A HREF="http://beginnersinvest.about.com/cs/21jumpstreet/a/012501a.htm">
   Rule of 72</A>,
an old heuristic from accounting that tells us
roughly how quickly a balance can double.  If
a bank account draws 5% interest a year, then
the balance will double in roughly 72/5 ~~
14 years.  At 10% interest, it will double in
about seven.  This is only a heuristic, but the
estimates are pretty close to the real numbers.

Applied to our running, the Rule of 72 reminds
us that if we increase our mileage 10% a week,
then we can double our mileage in only seven
weeks!  Throw in a couple of adjustment weeks,
and still we can double in 10 weeks or less.
And that's at a safe rate of increase that will
feel comfortable to most people and protect their
bodies from undue risks at the same time.  Think
about it:  Even if you can only jog three miles
at a time right now, you could be ready to finish
a marathon in roughly 30 weeks!  (Most training
plans for beginners can get you there faster,
so this is really just an upper bound...)

What does this all have to do with software
development?  Well, I have been thinking about
how to encourage students, especially those in
my first-year course, to adopt new habits, such
as test-driven design and refactoring.  I had
hoped that, by introducing these ideas early in
their curriculum, they wouldn't be too set in their
ways yet, with old habits too deeply ingrained yet.
But even as second-semester programmers, many of
them seem deeply wedded to how they program now.
Of course, programmers and students are people, too,
so they bring with them cognitive habits from other
courses and other subjects, and these habits interact
with new habits we'd like them to learn.  (Think
deeply about the problem.  Write the entire program
from scratch.  Type it in.  Compile it.  Run it.
Submit it.  Repeat.)

How can I help them adopt new practices?  The XP
mailing list discusses this problem all the time,
with occasional new ideas and frequent reminders
that people don't change easily.  Keith Ray
recently posted a 
<A HREF="http://homepage.mac.com/keithray/blog/2005/01/29/">
   short essay</A>
with links to some experience reports on incremental
versus wholesale adoption of XP.  I've been focusing
on incremental change for the most part, due to the
limits of my control over students' motivation and
behavior.

The 10% Rule is an incremental strategy.  The Rule
of 72 shows that such small changes can add up to
large effects quickly.

If students spends 10 minutes refactoring on the
first day, and then add 10% each subsequent day,
they could double their refactoring time in a week!
Pretty soon, refactoring will feel natural, a part
of the test-code-refactor rhythm, and they won't
need to watch the clock any more.

I'm not sure how to use this approach with testing.
So far, I've just started with small exercises and
made them a bit larger as time passed, so that the
number of tests needed has grown slowly.  But I know
that many still write their tests after they think
they are done with the assignment.  I shouldn't
complain -- at least they have tests now, whereas
before they had none.  And the tests support refactoring.
But I'd like to help them see the value in writing
the tests sooner, even first.

Together, the 10% Rule and the Rule of 72 can result
in big gains when the developer commits to a new
practice in a disciplined way.  Without commitment,
change may well never happen.  A runner who doesn't
run enough miles, somehow increasing stamina and
strength, isn't likely to make to the level of a
marathon.  That discipline is essential.  The 10%
Rule offers a safe and steady path forward, counting
on the Rule of 72 to accumulate effects quicker than
you might realize.
-----