ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Stagner" <>
Subject Re: "select" isn't broken
Date Tue, 29 Jan 2002 19:37:48 GMT
Herman, Dave wrote:

>>Tip #26.1: "select" *usually* isn't broken.
> True, but in 99% of the cases (statistics blatantly fabricated), people sit
> and stare at their screen and think, "Java must be insane," or "my computer
> must be insane," or "the basic laws of the universe must have just shifted
> before my very eyes." Then a fresh pair of eyes comes along and points out
> that, no, Java is case-sensitive and you forgot to capitalize this word, or
> your CLASSPATH is wrong, or some other such common mistake.
> I've been amazed at how bad people are at breaking down a problem when
> debugging; usually they just give blank, incredulous looks at the offending
> computer. I like the rule of "select isn't broken" because it suggests that
> people's first impulse of blaming the underlying system or seeing the
> universe crashing around them is far too dramatic. It's like a little nudge
> for us to pull up our sleeves and start digging through the code (, build
> script, etc.) for the culprit.

Actually, Tip #26 is followed by #27 - "Don't assume it -- prove it". 
Don't assume select is broken, but don't assume it's *not* broken, 
either.  As much as i like the attitude of #26, i've been bitten by 
broken operating systems, compilers, etc too many times to take it too 

I completely agree that most programmers have virtually no debugging 
skills at all. It's much easier to blame the environment than to look 
for causes in the code.  Hence my fondness for #27.  If you can't 
*prove* that system X is to blame for your bug, then you have no 
business assuming that (or at least, you should treat it as an unproven 
theory).  Now, write a minimal test for the supposed bug.  I actually 
like writing tests for such bugs *outside* the normal environment, as 
fresh throwaway code.  That way, i can be sure that nothing in my own 
complex environment is triggering it.

That being said, test-first programming was a revelation to me.  I'll 
never go back to assuming it works.  When i first discovered the mmap() 
bug years ago, the shared memory code was completely, unfixably coupled 
to the parser.  Heck, the parser was ultimately tied to the operation of 
a proprietary image scanner... there wasn't even a way to force 
identical test batches. I *had* to write an independent test program.

This sort of environment is not at all unusual.  How many programmers 
get to learn their craft on systems that are designed to be 
automatically buildable and testable?  Not many, as far as i can see. 
Serious debugging requires that systems can be isolated, when in fact 
most software seems tightly coupled.  If young programmers never get to 
work where debugging is easy, how are they supposed to learn to do it?


David Stagner

National Marrow Donor Program
3001 Broadway Street NE
Broadway Ridge Suite 500
Minneapolis, MN  55413


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message