Heisenbugs are bugs that vanish when you turn debugging on.
Schrodinbugs are bugs that don’t manifest until you read the code and realize they could never possibly have worked, whereupon they don’t. These are impossible, yet happen despite this.
Vizzinibugs are the single most common type of user interface bug. They are when the user follows an action path inconceivable to the original programmer. These include things like “What do you mean ‘Esc’ isn’t part of ‘Press Any Key To Continue’”, “I always fill out the password field first”, “I put in October in the ‘From’, and March in the ‘To’ so they’d come back in the opposite order” and the all-time classic, “But what if I want to put commas in my titles?”.
Okay, not an all-time classic, but one bug that Epistula doesn’t have anymore. I’m not sure why anyone would want commas in titles, but there you go. Vizzinibugs are such not because they are inherantly stupid requests, but more that the programmer just didn’t even conceive someone might do that.
But my favourite Vizzinibug of all time was actually my fault. It was in a piece of software for a company I worked for ages ago which, as part of the signup form, requested the date of birth for the customer. It was part of a batch of changes, so I duped another column, built some Crazy drop-downs to input it & change it, take the result, format it and dump it into the date column in the database. So far, so hoopy.
I tested it. Over the next couple of months my coworker tested it, the line manager of our traditional-webdev no-person-over-35 team tested it, the young, hoopy client tested it and ran though the whole thing, and it went into internal beta, all were happy.
A little while later, we started getting back some reports. Apparently some people couldn’t get the thing to save their birthday. The young, hoopy client tested it, and couldn’t reproduce it. My line manager couldn’t reproduce it. Neither could me or my coworker.
Humm.
Okay, could you send us the user id of an affected user please? Meantime marked as WTF.
From us to manager to client contact to users to contact to manager to us, and we had an example. Time to go database diving…
… This user has a birthday set. Oh, that’s a coincidence, it’s January 1st 19… oh. Nineteen seventy.
January the first 1970 is an important date in the Unix world. It’s zero. The Unix Epoch time format is defined, in fact, as seconds since then, and quite a few things work in it. My dropdowns didn’t. The database didn’t. But the functions to format the dropdown results and make sure they were a valid date, and not allow the 31st Feb?
Yeah.
Clicky, Clicky, Fix.
The thing is every person who tested it, from us right to the client, used their own birthday. And since not a single person had a birthday before 1970 – one person was _in_ 1970, but didn’t trigger it – we entirely missed the problem. One of those things that makes you look twice at data validation things, really.
And testing, of course.