A bug that occurs as closely as possible to closing time, and which is serious enough that you can't possibly leave until it's fixed.  Usually ShowStoppers, a Five o Clock Bug is always a CriticalBug, and may be a VoodooBug, HeisenBug, or SchroedinBug.  In short, a BugFromHell leading to a DebuggingNightmare which may leave you with WarStories of HeroicDebugging.

Typically, these bugs involve fundamental business-critical things such as secure handling of customer credit card information, ability to login to the application, ability for the application to retrieve data from a critical remote system, etc.  Also, they're usually noticed just ''after'' a release, rather than in pre-release testing.

There are several different types of Five o Clock Bugs:

* A Soft Five o Clock Bug starts out as a normal bug, nowhere near 5:00.  It takes a little longer to debug than you'd expected, and you're not fully confident of the results, but by 4:15 the tests are all passing and it seems to be fixed...until you realize at 4:45 that the tests are wrong, the bug is as bad as ever, and you have to start over.

* A Hard Five o Clock Bug strikes without warning between 4:30 and 5:00.  Everyone is pretty much satisfied that the release is good (not perfect, but good enough for today).  You're logging your time, about to shut down your tools, and getting ready to pack up.  Then a developer looks up as if she'd seen a ghost.  A manager comes rushing over.  A tester exclaims "I've never seen anything like that before!".  It's going to be a long night.

* A Friday Five o Clock Bug is the worst.  It would be the same as any other Five o Clock Bug, except that it happens on a Friday.  Not just any Friday, but the Friday of the big launch, the day before the Saturday of the big promotion, which comes before the Monday that the client CEO shows off the new program to thousands of journalists, customers, and competitors at the big trade show.  Scratch your plans for the weekend.

'''Lessons Learned:'''
* Never ever schedule a release on a Friday afternoon, no matter how small you think it is.  Preferably not on a Friday at all.
* Don't test in the afternoon.  You might uncover something you'll wish you hadn't.  Instead, code in the afternoon and test the previous day's code in the morning.

----
CategoryDebugging, CategoryBug