TITLE: Don't Forget Your 3000-LOC Check-Up!
AUTHOR: Eugene Wallingford
DATE: July 06, 2011 12:23 PM
DESC: 
-----
BODY:
Yesterday, Michael Feathers
<A HREF="http://twitter.com/#!/mfeathers/status/88228021286346752">
   tweeted</A>:

<BLOCKQUOTE><EM>
If a code base is more complicated than a car, shouldn't it have
a maintenance plan too?
</EM></BLOCKQUOTE>

I asked him, "Refactoring every 3K miles?", and he joked back,
"Well, maybe every 3K lines."  I had thought about using LOC in
my tweet decided to stick with the auto analogy.  Whatever its
weaknesses, LOC seems to be the first place programmers' minds
go when we talk about the volume of code.  (Though, as much
traveling as Feathers and other big-time consultants and
speakers do in a year, maybe 3000 miles is the right magnitude
after all.)

Feathers makes a serious point, even if he didn't mean it too
seriously.  When we buy a car, we implicitly accept the notion
of scheduled maintenance: change the oil every so often; have
the engine tuned up every so often; replace the battery and
rotate the tires every so often.  We accept it because we know
that it makes our car run better and last longer.

When we buy software, we want it to run forever, as is.  Or
the company who sells it to us wants us to run it as-is forever
-- or buy a new version.  Imagine having to buy a new car as
soon as your current car started coughing, wheezing, or seizing
up on dirty oil.

I mentioned refactoring in my joke because it is part of the
maintenance plan built in to XP and used in so many agile
approaches to software development.  XP discourages long-form
maintenance in the form of refactoring every few months or
even weeks.  Instead, it encourages a sort of continuous
maintenance, in a tight test-code-refactor cycle.  It's kind
of like checking your car's oil, fluids, tires, etc., after
every use.

When we do that to a car, it's usually because the car is in
bad shape, breaking down as we try to extend its life.  But
continuous refactoring of a code base is usually a sign of
robust health.  It means that we know our code is in good
shape and ready for use -- and extension.  Teams that maintain
their code on automobile-like time scales are usually sitting
on a time bomb.  Users may be able to use the code, but the
programmers dare not touch its internals.

My other thought as I tweeted was about our inability, or
perhaps unwillingness, to make this idea come alive for the
students in our university CS programs.

It is an inability because it is so hard to create ways for
students to live with any body of code longer than a semester
or two, and time is a necessary ingredient facing the need for
maintenance.  Of all my project courses, compilers seems the
most frequent teacher of this lesson.  A semester may not be
long, but a compiler is complex enough, and a non-trivial
language spec hard enough to understand, to accelerate the
sense of age and deterioration.

It is perhaps an unwillingness because most every CS faculty
I know makes very little effort to change courses and degree
programs to make this lesson approachable.  The good news is
that making changes to bring this idea within our students'
learning horizons also brings a lot of other important
software development lessons within their horizons.
-----