The Unexpected Bug

    If you have programmed, you have seen bugs.  The only bug-free code is no code at all.  Everything can break, it just depends on the conditions.   There are a few other programmer clichés, but they slip my mind at the moment.  All of these canards speak to one fundamental fact, you will find bugs in your code.  You may even grow to rely on errors or exceptions to handle your debugging and logic design.  I would not recommend this, but it illustrates that every programmer has their bug 'tolerance level'.   Once that level or alarm goes off, then that bug has to be fixed or scheduled for a fix before you go mad (or your boss sees it in action. During a demo. To the Client.)  
    Of course all bugs are not the same.  Some are irritating, slow down or hamper performance, or just do something wrong that only you, the developer, can notice.  All of these may trigger a hunt for the culprit, but usually can be cataloged, recorded, and ignored when initially found*.
    The bug that always gets the attention is the one that you did not see coming.  You are working your way through some test cases or running the code to see how your latest changes perform and POOF!  You app drops out and your debugger really has no clue why.  Well, some clues, but not enough to find the exact spot of the problem.  After your initial shock that the tools have failed you, you start wondering what caused the crash?  Can I recreate this crash?  Luckily, apps are not huge software programs, so getting back to where it crashed is usually pretty simple.  If it crashes again, great!  You have now found the problem area and are much closer to finding the root cause.  If it doesn't crash, you now wonder if you recreated it right or have a more subtle problem in your code.  (My C developer hat is shouting, "Check your pointers!")
    Now the catalog process begins.  If you can recreate it, chances are you can find the problem area and fix it on the spot.  If it is too big to fix, it can be logged as a TODO for the future.  Now you have to try to avoid doing that crash sequence until the fix is in, but sometimes it can wait.  Most of the times, it can't wait because it could be the symptom of something more serious in the your code.  Either way, it will take time to uncover, document, and fix.  This is the programmer's 'padding' when trying to estimate a how long a program will take to write.  If you mess up too much or don't get the design right initially, you can blow up your timeline pretty quickly.  The padding in your estimate allows smaller delays and bugs to be fixed without the stress of a missed deadline.  Of course, if you do finish early, then you can add some extra features.   Win/Win!
    On the other hand, a little extra testing might be a better way to use up that extra time.  You never know what might happen.


* Now that last statement depends on who found it.  My friends that perform testing on software will often disagree on the priority with the programmer.  They are usually right, as they are closer to a customer than the programmer, but priorities are sometimes tricky.