A decade and a half ago (or maybe two?), I was working at a software service shop. This shop has been in charge of support of a built-to-order native Win32 application (in Visual Basic or Delphi or something like that) initially developed by another previous company that had long disappeared.
One day a coworker got a support call from a user. Far from mythical outbursts of irate customers, an understandable the voice at the other end of the line remained extremely calm and eager to help resolving the issue, although you could feel a gleam of despair in the back of her voice.
The woman at the other end of the line had to input troves of data daily in a specific form in the application, basically taking a stack of whatever field-ridden paper forms they received and entering them into the system via the equivalent digital form manually.
She was adamant that every time she attempted to input a specific, optional date the form would close on its own, losing all of the input data. To make matters worse the specific date was the last one to be entered, thus all the already-repetitive hard work of inputting an entire form was getting even more annoying.
To make matters even more complicated, she was working part-time, in rotation with another person covering for days she was off. The other person never encountered the problem!
So their solution for years had been that the woman who was reaching out to our support would input everything but the affected date field, save but not validate the form, and place the paper form in a special basket; the second person would then go through the paper stack again and fill the missing dates.
They would go to the extent of telling people who submitted the form that the affected date would lengthen the form processing by a few days. Somehow this flied quite well as people would understand that this was a case where the date would imply more work (as in, actual work, e.g cross-checking more stuff or more internal paperwork or whatever) on our customer's side.
In any case, this solution would stop working soon as the woman was going to go full time again and the other person in rotation would move to do something else. The customer had put up with this for an absurdly long time but now they were painted into a corner so they were left with hardly any option but to reach out for support.
We couldn't hardly believe this was happening, but the person was very articulate and came up with a quite complete description of the situation that in most support cases you only dream of having. So my coworker dove into the code base, which was not ours and only received the occasional bug fix or small development to keep the software compliant. He could not find anything in the code, he could not reproduce anything locally, the date field - of any of the other fields for that matter - looked like any other standard field, but there must have been something.
Confounded, the only thing we could think of was that it only happened on the user machine somehow. He asked to remotely connect and try it on the user's machine. No dice. He asked for the person to do it, anxiously watching as the user cautiously moved the pointer towards the date field when suddenly the form vanished! He went at it again and did the exact same thing, down to when things are clicked or typed and whatnot, but nope! But the user could still reliably reproduce it, over and over again.
Could it be that doing things through a remote connection affect the ability to reproduce? Out of options, he asked for the other person - which likely was at the office that day - that used to input the form to come over and input the same thing directly, watching the screen as fields filled up. It looked _exactly_ the same as when the usual user was doing it, but it worked.
We now could not see any other option but to move the investigation on site. Two people were tasked to that end to cover all possible grounds and brainstorm on the spot.
Arriving on site, they were greeted by this very amenable woman affected by the bug. They entered a small, poorly lit office, one taking a seat next to the user and the other standing due to the lack of space, and watched the user as she powered up an absurdly small, overaged CRT screen, then booted the ancient PC. As the user started typing on the $5 keyboard, moved the creaky mouse around they could not help but feel compassion as they saw the daily stack of paper forms that had to be entered every day, all day long, using such poor equipment and inhumane conditions when the customer company was throwing seemingly endless and voluminous amounts of money at our employer.
Focusing on the actions on the screen, the team member leading the investigation went through all stages of bewilderment and despair as the user arched forward to aim at the impossibly tiny date field on that tiny old screen, and just like that, the window vanished. His mind helplessly racing, in the stillness of the moment a voice raised up from behind:
"Can you do it again?"
Said the one standing up.
So, with unabated calmness only zen masters can achieve, she nodded, proceeded with moves repeated a million times over, and the window closed again.
"Yup, I got it".
You see, one of the requirements for this digital form was to match the paper form in layout
and wholly fit in the screen. To achieve that, the font size and UI element dimensions were dialled down. On the user's small, poor, aging screen in a badly lit environment and with an impossibly bad mouse this made UI elements spectacularly hard to interact with, especially the date picker drop down. So when reaching to that specific optional date picker in a specific place of the screen the user had to lurch forward a bit to take a good look
and lurch a little bit further and to the right to extend the arm to mover the pointer over there and click to make the date picker appear. As it turns out the affected user was a bit overweight and with this very movement her -
ahem - "sizeable" right breast ever so slightly brushed against a key on the right side of the old, mushy keyboard, in a way that made it register a keypress without any audible or haptic feedback. That keypress - which I can't recall which it is - turned out to be what closed the form.
We could have patched the software to prevent that from happening. We didn't. Instead a report was produced that in no uncertain terms - but not pointing at the actual mechanical details - a combination of hardware and poor, non-ergonomic work environment was identified as the root cause; and not just that, but through small talk it was learned that the reason she was working part time was medical and largely caused by these terrible work conditions, so we added a note "as a courtesy" they could maybe end up being liable for any health issue that would "hypothetically" come up buy working in such environments. She got a new computer and display, a proper keyboard an mouse, a better desk and chair, and, I seem to recall, an additional light. The customer complied, reported the issue as fixed, and as far as we know the issue never occurred again.