TITLE: Should Code Die On Schedule?
AUTHOR: Eugene Wallingford
DATE: April 15, 2009  9:00 PM
DESC: 
-----
BODY:
Last evening, Mike Feathers
<A HREF="http://twitter.com/mfeathers/status/1521075554">
   tweeted a provocative idea</A>:
<EM>The world might be better if all code
disappeared at a fix age and we had to constantly
rewrite it</EM>.  Heck, he could even
<A HREF="http://twitter.com/mfeathers/status/1521151495">
   write a tool to seek and destroy</A>
all code as it reaches the age of three
months.  Crazy, huh?

Maybe this idea is not so crazy.  At my university
and most other places, hardware is on a 3- or
4-year "replacement cycle".  Whether we need new
computers in our student labs, we replace them
on a schedule.  Why?  Because we recognize that
hardware reaches a natural "end of life".  Using
it beyond that time means that we carry an
ever-increasing risk that it will fail.  Rather
than let it fail and be caught without for a short
while, we accept the upfront cost of replacing it
with newer, more reliable, better equipment.  The
benefit is piece of mind, and more reliable
performance.

Maybe we should recognize that software can be
like hardware.  It reaches a natural "end of life"
-- not because physical components wear out, but
because the weight of changing requirements and
growing desires push it farther out of compliance
with reality.  (This is like when we replace a
computer because its processor speed and RAM size
fall out of compliance with reality: the demands
of new operating systems and application software.)
Using software beyond its natural end of life
means that we carry an ever-increasing risk of
failure -- when it actually breaks, or when we
"suddenly" need to spend major time and money to
"maintain" it.  Rather than risk letting our
software fail out from under us, we could accept
the cost of replacing it with newer, more reliable,
better software.

One of the goals of the agile software development
community is to reduce the cost of changing our
code.  If agile approaches are successful, then
we might be more willing to bear the risk of our
code falling away from reality, because we are
not afraid of changing it.  (Agile approaches also
value continuous feedback, which allows us to
recognize the need for change early, perhaps before
it becomes too costly.)  But there may be times or
environments in which these techniques don't work
as well as we like.

Suppose that we committed to rewriting 1/4 of every
system every year.  This would allow graceful,
gradual migration to new technologies.  A possible
cost of this strategy is increasing complexity,
because our systems would come to be amalgams of
two, three, or even four technologies and programming
languages interoperating in one system.  But is this
all that much different from life now?  How many of
our systems already consist of modules in several
languages, several technologies, several styles?

Another side of me is skeptical.  Shouldn't our
programs just keep working?  Why not take care to
design them really well?  Why not change small parts
of the system as needed, rather than take on
wholesale changes we don't need yet?  Doesn't this
approach violate the principle of
<A HREF="http://c2.com/xp/YouArentGonnaNeedIt.html">
   YAGNI</A>?

Another advantage of the approach:  It gives us a
built-in path to continuous learning.  Rewriting
part of a system means digging into the code,
learning or re-learning what it's made of and how
it works.  With pair programming, we could bring
new people into a deeper understanding of the code.
This would help us to increase the feeling of
collective code ownership, as well as preserving
and replenishing corporate memory.

Another disadvantage of the approach:  It is hard
to maintain this sort of discipline in hard
financial times.  We see this with hardware, too.
When money is short, we often decide to lengthen
or eliminate the replacement cycle.  In such
times, my colleagues who traffic in computer labs
and faculty desktop computers are a little more
worried than usual; what happens if...  Software
development seems always to be under financial
pressure, because user demands grow to outpace
our capacity to produce meet them.  Even if we
decided to try this out for software, administration
might immediately declare exigency and fall back
into the old ways: build new systems, now, now,
now.

Even after thinking about the idea for a while
now, it still sounds a little crazy.  Then again,
sometimes crazy ideas have something to teach us.
It is not so crazy that I will dismiss it out of
hand.  Maybe I will try it some time just see
how it works.  If it does, I'll give Mike the
credit!
-----