Dancing rabbits hawking toilet paper (was Re: Big Leak, Titanic going down again!)

[glen e. p. ropella]

At 09:22 AM 2/29/00 +0000, you wrote:
> return now, and going through the code many times. In the end, it was a
> small change in the code I had recently introduced. Since I made many
> small changes at the same time, regrading them as straightforward, it was
> difficult to trace the culprit. Of course, it was what seemed most
> unlikely.
>
> So I would suggest trying to recall all recent changes and going
> through them line by line. They are more likely the cause then older
> pieces of code.

Thanks for segue, Jan!  This is the best advice I've
seen in a long time.  I'd like to take this opportunity to
suggest that everyone do two things whilst developing a Swarm
application:

1. When going about debugging things, or when doing exploratory
tweaking on a large body of code, make only one change at a time.
2. When developing, changing the feature set, or creating code,
use CVS.

The reasons for this are obvious to anyone who already uses
CVS or to somebody who's been coding long enough to have stepped
back a few hundred times to yet again rethink their modus
operandi.  For (1), the justification lies in a disciplined
search of the software's behavior space.  While I grant that
evolutionary search works for many spaces, top-down thinking
still wins in a debugging task. [grin]  Spend more time than
you want thinking up a hypothesis for why the program is
behaving in the buggy way, then base your debugging techniques
on that hypothesis.  Tools like dmalloc, electricfence, etc.
are a CRUTCH, not a solution.  Of course, we all break our
legs once in a while; so using a crutch is the sensible thing
to do.  But, imagine a healthy person trying to run a marathon
using a crutch and you'll get the right metaphor for when
these devices are useful and when they get in the way.

The justification for (2) lies in exactly what Jan mentioned.
CVS won't force you to regularly commit your code to a repository
(allowing it to explicitly identify every change since the
last commit).  But, it will facilitate change tracking.  If
you're working in a CVS sandbox, at any point you can do a
"cvs diff" and CVS will point out *every* difference you've
made since your last commit.  Even if you're rather strange,
like me, and you only like to commit things when a complete
feature is added, sometimes entailing hundreds of tiny
changes throughout a body of code (which indicates bad design,
of course ;), it still packages up "what might be wrong" in a
single report for your leisurely perusal.

So, suffice it to say that I'm a fan of source code management
tools, particularly CVS.  [grin]  And I strongly suggest that
everybody use it.

Now back to your regularly scheduled thread.

glen
p.s. the subject was taken from a quote by Rod Serling, who said
that it was hard to make a documentary for television because
it's hard to hold a thread when one is interrupted every 10
minutes by dancing rabbits hawking toilet paper... or somesuch.


--
glen e. p. ropella =><= The front line is everywhere. Hail Eris!
Home: http://forager.swarm.com/~gepr              (505) 424-0448
Work: http://www.swarm.com                        (505) 995-0818

                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.