WillMaster Possibillites Logo EzineSeek Award
Bugs, and How They Can Happen
by
William "Will" Bontrager

Permission is granted to reprint this article in its entirety, provided no reprints are sent in conjunction with unsolicited bulk email, provided no fee or other value is exchanged, provided no changes are made to the article, and provided the author's name, signature lines, and copyright line are printed with the article; except you may change the article's title.

Years ago, while I was still working for the other guy, a financial printer in this case, the president of the company had a meeting with the senior staff.

This was a high-service shop where you could bring in your handwritten copy one evening and pick up your printed book the next morning. There were meeting rooms where you could consult with your attorneys, make changes to pages, and have a corrected proof in your hands within minutes. The company provided couriers from Los Angeles, California to Washington, DC for time-sensitive SEC filings.

In that meeting, a department head justified why it took so long to typeset and proof a page -- original keyboarding, proof reading, bounce back for corrections, proof reading, possibly another round or two of this because sometimes a proofreader misses a typo or a typesetter misses a proof mark.

I still remember the president's response. I remember his expression and his posture. I remember the gloss on the table and the location of the water cooler. And I remember the utter stillness immediately following his response:

"Why don't you just do it right in the first place?"

Well, why not? Because in real life typesetters and proofreaders are human and their attention will shift from time to time and they will miss details.

And that is also one of the reasons computer programs can have bugs. Programmers are human. (It's actually true!)

Most typographical bugs are caught during initial testing of the program. Others hang around for a while either because the section of code they're hiding in is rarely used (an error routine when a file isn't present, for example) or the condition stimulating the bug rarely happens or happens only at certain times (a misspelled name of a month, for example, that wreaks havoc only when that month comes around). Both of the examples have happened to me, and both have increased my resolve to pay attention to what I'm doing.

Some bugs are introduced because the programmer is missing essential information. For example, before the Master Syndication Gateway program was released (see http://willmaster.com/a/11/pl.pl?msg ), I tested it thoroughly. So I thought. Our server's name is our domain name. When the program went on sale, up pops this bug with the server name and domain name not resolving. When I found out that some server's names begin with the characters "www." followed by the domain name, I quickly squashed the bug. (This issue is not related to URLs. Server names and URLs, while usually complementary, are not the same thing.) You can use Master Pre-Installation Tester from http://willmaster.com/a/11/pl.pl?mpits to see what your server's name is.

Other bugs can come to life when a condition occurs that wasn't predicted or deemed of insufficient importance to consider. The Y2K bug of two years ago is a dramatic example of this.

The last class of bugs to be mentioned here are those introduced when a program is modified. All of the above situations apply, plus another consideration: If someone other than the original author(s) modifies the program, the person doing the modifications will need to study the entire script or be in danger of introducing bugs from lack of understanding how the script works. Making a change in one place could, without the knowledge of the programmer, cause a different and seemingly unrelated portion of the program to misbehave. Further, the misbehavior could be latent, not presenting problems until some future date -- which usually means the programmer needs to study the script all over again.

That is one of the reasons I recommend the original author do modifications on CGI scripts. Another reason is that testing must be exhaustive and will almost certainly take more time than if the original author made the changes.

Good programmers work diligently to prevent bugs. However, and for reasons discussed with more depth in my ebook "How to Hire a CGI Programmer" available from http://willmaster.com/a/11/pl.pl?pie2, no program can with certainty be guaranteed bug-free.

I've just re-read this article and I don't think it contains any bugs :)

Copyright 2001 William Bontrager
Programmer/Publisher, "WillMaster Possibilities" ezine
http://willmaster.com/possibilities/
subscribe-possibilities@willmaster.com
Business Home Page: http://willmaster.com/