Facing Reality

“If we wish to draw philosophical conclusions about our own existence,

our significance, and the significance of the universe itself,

our conclusions should be based on empirical knowledge.

A truly open mind means forcing our imaginations to conform to the evidence of reality,

and not vice versa,

whether or not we like the implications.”

Lawrence M. Krauss,

A Universe from Nothing: Why There Is Something Rather Than Nothing

If there is one thing that is unique about programming, it is that you cannot convince a computer that you are right and it is wrong. It will blindly do exactly what you tell it to do, every time, without fail. (Of course there are hardware failures, but let us set that aside for now).

If there is a problem, you the programmer are responsible and the machine will not get it right until you do. It has been said that this is a big factor in the strange sense of humor that many programmers have. When faced with a machine that will unflinchingly tell you that you are wrong every time, something has to give and it will not be the machine.

So smile, check your source code, again, and keep going. Remember, we are placing our lives in the hands of these machines more and more every day and we are counting on you and your colleagues to get it right.

Software Defects

Defect-free software does not exist

Wietse Venema

However, that doesn't mean you shouldn't try your hardest. And give me a bug that fails spectacularly, those are usually the ones that are easiest to find. It's those little tiny errors that only occasionally show up that are the really hard ones.

When I first started programming, I was doing real-time, multi-processor, embedded systems. Now there were some bugs! I can remember spending more than a week trying to find a particularly pernicious one. Now we have source code debuggers, but back then all I had was the equivalent of the asm mode of gdb and debug writes to I/O ports or memory locations. I have been caught debugging and patching in some opcodes by hand into a C/C++ program to see if that would fix the problem. Old habits die hard.

At one point I was responsible for all of the I/O drivers of an MP/M system and had spent several days and a final 24 straight hrs the day before a demo trying to get it working. It seemed like the system would work just fine and then just lose its mind. We had to cancel the demo and I went home and slept, leaving as others were coming to work the next day. Eventually we found out that an interrupt routine was losing the carry bit in the accumulator (interestingly, that system and associated compiler did a inordinate amount of status checking using the carry bit).

64 bits worth of status and data in that processor and I was saving 63 of them. 98.4% accuracy was not good enough, it never is with computers.

A machine is an unforgiving executor of what we write, not what we mean, which is why many of us develop such a odd-ball sense of humor. You have to relieve the pressure somehow.

Anyone have or know of any great bug or bug hunting stories? Add them to the comment section. I would enjoy reading and learning from them. Meanwhile, check out the 500-mail email problem.