A bug with catastropic behaviour.

Example: Accidentally pressing Enter/Submit before entering the WHERE clause in an SQL DELETE statement.

''That's not a bug, any more than doing "rm -rf /" as root on a UNIX/Linux box is a "bug".  It's stupid, but it's not a bug. It would be an hindenbug to have software composing a DELETE statement forgetting a proper WHERE clause in certain edge circumnstances.''

''Here's a HindenBug story:''

''Many years ago, we developed a large billing/scheduling/bookkeeping/payroll system for a client.  Our client had many franchises, and every franchise used our software.  Worried that franchises might leave the franchise organisation and strike out independently, our client asked us to implement a "time bomb" that would permanently lock out the software if not explicitly renewed every year with an authorisation code from the franchise organisation.  We implemented it, tested it, and deployed it.''

''A few days after deployment -- a Monday morning, as I recall -- we started getting urgent, angry calls from franchises, many threatening legal action.  At franchise site after franchise site, the "time bomb" was going off, locking out the users and shutting down the software.  We couldn't get users back in, as the lock was designed to resist even the most clever bypass attempts.''

''Desperately, we scanned the source code to see what went wrong.  Turns out a subtle HindenBug in the date routines caused the right combination of today's date minus the last renewal date to return -- instead of something less than a year -- a value of about a hundred years!  The software thought it hadn't been renewed within the obligatory one year period and so it locked itself down.''

''We fixed the source and built a new executable.  Today, we'd simply upload it to our Web site for the franchises to download and they'd be back in business in a few minutes.  Unfortunately, in those days, the Internet was barely known outside of academia and research.  Our client didn't have it, nor did their franchises.  We normally deployed updates via diskette, mailed in the post.  The only electronic connection we had was via PCAnywhere, a popular remote-desktop utility, at 2400 bps.  So, we generated a binary diff between the new executable and the deployed one and constructed a patch and a patch installer.  The diff utility and the patch installer were written by me within an hour, in the most fevered coding rush of my career.  Then, one by one, we remotely logged into each franchise system, uploaded the patch, ran the patch installer, and verified the software was working.  Then we heaved a sigh of relief.''

''Grumblings about "business interruption" lawsuits continued for a few weeks before users cooled off.  We didn't get sued, but we removed the "time bomb" and I refused to ever deploy one again.''

''By the way, in some interpretations, even the above isn't a "HindenBug" per se.  Some interpretations hold that a HindenBug is one that has a big impact on the '''software''', e.g., an OS kernel bug that breaks every application.  Its real world impact is irrelevant.  On the other hand, a flaky Date implementation in business software is likely to affect a significant proportion of almost any application, and is therefore certainly a Hindenbug by any definition.''