It's been awhile since anyone's managed to break "my" application at work, given all the bullet-proofing code that's accreted over mumble-six-mumble years. The "broken" web page is set up to submit the user's input to the web server if the user clicks the "Submit" button or (as a convenience) presses the "Enter" key. Nothing fancy.
But what happens when the user clicks the "Submit" button and then hits the "Enter" key a short moment later? As it turns out, this submits the same input form twice.
Oops.
So far as I know, this is the first time a user's done that in the four-plus years that this web application has been my baby. (Perversely, I was delighted to learn that it still had quirks I hadn't known about. Of course, the fallout from this bug is pretty minor, because the duplicate request was easily deleted. If you're going to have a quirk, that's a good kind to have...)
My odd joy in quirkiness aside, the incident plays up how very difficult it is to test (and thus to bullet-proof) software that relies on humans to input data. Part of the problem is that professional software testers generally understand how the application they're testing is supposed to be used. This makes it less likely that they will think to "push the wrong buttons," if you will. Programmers who do all their own testing are even less likely to find those kinds of bugs, because programmers also know what's happening inside the black box. Even the afore-mentioned user who accidentally submitted the form twice is quite familiar with the system.
I'm sure that my programming elders can easily one-up my itty-bitty bug that only took four years to find. But for non-programmers and those just starting, the takeaway is: Never consider code unbreakable. When we talk about "bullet-proofing" an application, we're mainly talking in terms of Kevlar vests, not the Popemobile.
