Rob,
If you hangout here long enough, you will become one of us and reliably won't matter. I speak from experience, my standards are slipping.
For most programmers reliably is is handled by taking out the debug checks when software is released so the code is smaller and runs faster.
Here is a quote from long ago:
Turning off dynamic semantic checks once you've finished debugging your program is like taking off your seat belt once you've left the driveway.
This quote is wrong, modern programmers don't believe in seat belts or airbags. We are at the level of automobiles 60 years ago, there are no seat belts.
Modern programmers don't diagnose and fix bugs, they turn Bohrbugs into Heisenbugs. One way to make life better for users is to convert Bohrbugs into Heisenbugs.
This is good enough because Bohrbugs are showstoppers for users: every time the user does the same thing, he or she will encounter the same bug. With Heisenbugs, on the other hand, the bugs often go away when you run the program again. This is a perfect match for the way users already behave on the Web. If they go to a Web page and it fails to respond, they just click “refresh” and that usually solves the problem.
Here is a definition:
Jim Gray drew a distinction between two kinds of bugs. The first kind are bugs that behave predictably and repeatedly—that is, they occur every time the program encounters the same inputs and goes through the same sequence of steps. These are Bohrbugs, named for the Bohr atom, by analogy with the classical atomic model where electrons circle around the nucleus in planetary-like orbits. Bohrbugs are great when debugging a program, since they are easier to reproduce and find their root causes.
The second kind of bug is the Heisenbug, named for Heisenberg’s Uncertainty Principle and meant to connote the inherit uncertainty in quantum mechanics, which are unpredictable and cannot be reliably reproduced. The most common Heisenbugs these days are concurrency errors (a.k.a. race conditions), which depend on the order and timing of scheduling events to appear. Heisenbugs are also often sensitive to the observer effect; attempts to find the bug by inserting debugging code or running in a debugger often disrupt the sequence of events that led to the bug, making it go away.
Jim Gray wrote this in 1985 and not much has changed. http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf