Subject: "greedy" debugging algorithms

(This message is being sent to all CPSC 215 students and TA's)

In the past couple of days I've been trying to assist a student
whose find_closest_object() function is broken.  I've pointed
out a couple of fatal (segfault/bus error) causing flaws, and
in response to these the student has indeed changed the function
so that it no longer segfaults or bus errors.

But now the student asks me to help find a "new bug" which
is causing an all black image problem.

The problem is unfortunately that find_closest_object() is
STILL broken and is returning NULL for every ray. Needless
to say this DOES produce an all black image.

Bottom line:

Just because a function no longer segfaults or bus errors
doesn't mean its correct.

The ONLY way to attempt to verify correct behavior is a PAINFULLY
detailed analysis of program behavior via gdb or fprintf().

As I said early in the semester, the magic easy debug bullet
really and truly doesn't exist.

Being successful in "real-world" programming REQUIRES
BOTH the ability to methodically focus upon details AND a high
pain threshold. In the "real world" even expert programmers
may take multiple person-WEEKS to track down and defeat a
single bug.