tom thinks

LinkShare Referral Prg

date 2001-04-10:11:32
Software I think I've mentioned before the recollections of one of the first programmers of an electronic computer at Los Alamos during the war. The person wrote that he was amazed to find that his programs didn't always work the first time, and after a while it slowly dawned on him that he was going to spend most of the rest of his life searching for bugs.

I'm personally not a very good coder--I've done a lot of it, but it isn't where my real forte' is. Design and algorithm development are much more my thing--in particular, UI is generally something that happens to somebody else. So when I do dive into code, I'm apt to make mistakes, and my typical mistake is of the form that the program does the right thing when the expected condition occurs, but the wrong thing otherwise. Ensuring correct behavior in all cases is the trick.

I once worked with a developer who never made this kind of mistake, and used to get deeply frustrated when I did. He just didn't understand how it was possible that anyone could do this kind of thing.

Beyond bugs, this kind of error can lead to some pretty funny looking code: stuff that does the right thing, but does it in a really weird way. A friend at another company once pointed out the following:
 
if ((a == 3) && (a == 4))

which, as he said, is a complicated way of saying, if (false). More subtle instances of this kind of thing are far more prevalent than I think most of us realize.

Find Enlightenment