Tech Support FAIL
Jul. 11th, 2008 10:59 amShort story long: 48 hours ago our remote travel agents suddenly became unable to connect to the $AIRLINE reservation system. $AIRLINE swears they changed nothing; we know we changed nothing [and yeah, everybody says that...].
Call $AIRLINE Tech Support; look at configuration parameters for various items. The Level 1 finds something they feel is misconfigured, suggest we change. In the process, they say "well, no wonder this doesn't work; this is the wrong parameter". We remind them that it had been working just fine for over a year until two days ago.
Their reply: "No, you're wrong. That's impossible. It never worked."
Apparently all the staff travel we've done for the past year was imaginary.
At least it works now.
Call $AIRLINE Tech Support; look at configuration parameters for various items. The Level 1 finds something they feel is misconfigured, suggest we change. In the process, they say "well, no wonder this doesn't work; this is the wrong parameter". We remind them that it had been working just fine for over a year until two days ago.
Their reply: "No, you're wrong. That's impossible. It never worked."
Apparently all the staff travel we've done for the past year was imaginary.
At least it works now.
no subject
Date: 2008-07-11 04:20 pm (UTC)no subject
Date: 2008-07-11 04:30 pm (UTC)no subject
Date: 2008-07-11 04:31 pm (UTC)Client: Your upgrade broke feature X. My code no longer works!
Me: That feature never worked that way. Your code could never have worked.
C: It's been working for years!
M: Put back the old program, and if your code works, send me something to demonstrate the change in behavior.
C: [after putting back old program] But, but, but... I know it used to work this way.
I have yet to have someone prove me wrong if I say "that never worked".
My guess (pure speculation, however) for your case -- your configuration worked due to a bug on their side. They fixed the bug, and your parameter now fails, as it was supposed to. We have run into that case, where a bug fix now catches an error that used to "work" despite it being "wrong". (Depending on the original bug, we sometimes add a config variable to keep the old behavior.)
no subject
Date: 2008-07-11 04:34 pm (UTC)no subject
Date: 2008-07-11 06:41 pm (UTC)Generally, I shrug, fix the bug, and offer silent prayer to Eris for making busted-ass code do the right thing for no good reason.
no subject
Date: 2008-07-11 05:16 pm (UTC)If you are Microsoft, you include code which emulates long-fixed bugs so as to not break legacy programs. While this is good for compatibility, it makes for a whole big pile of crap.
no subject
Date: 2008-07-11 05:14 pm (UTC)I have, however, often said "What a pile of shit. How the hell did this ever work in the first place?"
no subject
Date: 2008-07-11 05:38 pm (UTC)no subject
Date: 2008-07-11 08:03 pm (UTC)no subject
Date: 2008-07-11 09:53 pm (UTC)Also, many moons ago I used to work for AOL. When AOL client connects it forms a VPN-ish tunnel (from what I understand, it acts like a VPN, but isn't completely a VPN for some reason...I never really got into that much detail with it while I was there.), and therefore you can't use any other VPN software with it. Even though it's impossible to have two VPNs on a machine run simultanously (or, rather, it is impossible in theory.), there were people who would call in and insist that it did work. Same thing would happen to me at Verizon, people insisting they were connected via VPN to both the VzB and VzT networks at the same time, even though that should be a physical impossiblity.
Sometimes weird shit works when it really shouldn't, and god only knows why. Usually when I get those calls I just say "well, you're the luckiest person on earth. That feature worked when it should have been impossible. However, I can't get it back to that state because that feature not working is intended." Who knows. I blame the lawn gnomes.
no subject
Date: 2008-07-12 01:46 am (UTC)