I was going to post this to Reddit, but realized this would be a little too obvious if anyone who knew me saw this.
My favorite bug was proprietary at Kana, but given that it’s nearly 25 years back it’s safe to share.
We had a web based client that most of our customers used for most things, and a Visual Basic 6 “Power Client” for customers who preferred it, but I think some admin tasks never got translated to the web version.
We had one very large client who could no longer manage part their system of because the VB client would just crash on a given screen. We had no good telemetry to figure out what was happening, and nobody in QA could replicate it. Eventually they sent me – a very junior engineer, and after the bad layoffs in 2001 one of the very few people who still knew any VB6.
This is not a travel story; customer was in the South Bay, Kana was in the the then-dodgy end of Menlo Park*, so just a long drive from our office. This was in the days LONG before VPNs were common, and there was some… fun… details getting onto their network, with the eventual winning way being was by dialing in via my laptop on a phone line borrowed from a fax machine.
Once I was on and had their manager of the customer service department that used our software on my laptop, it took 30 seconds to replicate. If we’d just had a stack trace logged somewhere, this could have been solved a month+ quicker.
The actual bug? It was hitting an overflow; some Java dev had written interface code in VB, and I’m sure assumed that CInt on VB6 was 32 bits like a Java int. It was 16 bits, though, and they were the first customer to hit an ID for that particular administrative object over 32767.
I offered them a patched build on the spot, but they preferred getting it through our formal release process. It was still PDQ.
Not a very interesting bug from a technical perspective, but the hoops I had to go through to debug it were in their weird way very satisfying.