Sent this to my father, a control systems engineer. He responded with his own story:<p>"This is a true story which I saw with my own eyes. In Arkansas... It was in the afternoon, at a boiler plant. Boilers have an induced draft fan that pulls combustion products from the combustion chamber. A big, big fan with an electric operated throttling damper.<p>The damper began behaving erratically and the operator jumped up, grabbed a firehose and started hosing down the actuator housing. I asked him what was going on. He said that the actuator had overheated and he was cooling it down and went on about it being a bad design.<p>Anyway, the actuator began working properly. He said this happens when the sun shines on the unit etc. And it was a bad design etc., Etc.etc<p>Then it happened again at 11:00 PM. Same story. I asked him about the fact it was cooler and the sun wasn't shining on it. Don't recall his answer but he explained it all away, got the fire hose out and fixed it and I got the bad design lecture again.<p>Turned out to be a loose wire. The shaking from the fire hose always fixed the problem temporarily and reinforced his belief.<p>He was truly disappointed."
I posted this before, but it's worth repeating now:<p>I heard a story about a terminal in a public terminal room that a user was able to consistently log in to if they were sitting down in a chair in front if the terminal, but never if they were standing up.<p>They thought it might be static electricity, or some mechanical problem, or "problem exists between keyboard and chair", but finally they noticed something else was amiss...<p>It turns out some joker had re-arranged the 1234567890 keys to be 0123456789, so when the user was standing up, they looked down at the keyboard and typed their password (which contained a digit, of course) by looking at the keys. But when they were sitting down, they touch typed without looking at the keys, and got their password correct!
I hate to be that person, but I doubt the story is true. The variance in time spent waiting in the checkout line is far greater than the time it takes to walk to the front vs back of the store.<p>What do you know? I google "snopes car allergic to ice cream" and find that it's an urban legend: <a href="http://www.snopes.com/autos/techno/icecream.asp" rel="nofollow">http://www.snopes.com/autos/techno/icecream.asp</a>
Reminds me of one of my all-time favorites -<p>The 500 mile email<p><a href="https://www.ibiblio.org/harris/500milemail.html" rel="nofollow">https://www.ibiblio.org/harris/500milemail.html</a>
Another (real) story of my own:<p>We had a piece of software that would present a dialog for the user to select a file, then parse and send the contents to an embedded device. This software was an internal tool and not very reliable, so it would crash if you selected a file with invalid contents.<p>Two engineers, Dan and Brian, came to me with a tricky problem. Every time Dan would open a specific file everything would work fine. Every time Brian selected the same file the program would crash. I was obviously skeptical and went to watch. We tried it 10-20 times and sure enough, it always failed for Brian and worked for Dan. I watched them perform the exact same steps.<p>Eventually I gave it a try myself and realized what was going on. Dan would click "open", select the file, then click OK. Brian would click "open" then double click the file.
This is the kind of bug report that will keep you busy (and occasionally drive you crazy) as an Open Source maintainer. The bug is real, but the reporter completely fails to (or is too "lazy" to) isolate the problem or build a simple test case without a lot of hand holding.<p>I recently filed a bug with Chromium[1]. It took me about 3 hours to isolate the problem and build a simple test case when I could have just reported "My HTML5 game fails to load when I refresh the page" - making it extremely time consuming for the Chrome maintainers (much more so than it was for me) to find the culprit.<p>Please isolate the problem when reporting bugs!<p>[1] <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=677633" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=677633</a>
Here's one of my favorites from my desktop support days. A frequent flying calls in one day to report that her keyboard is broken. Diagnostic questions indicate that it keeps entering spaces all on its own.<p>I bring a replacement but first sit town and test-drive it without any issue, to her surprise. Next, I watch her type. Now, this user happens to be a rather large woman, working at a somewhat cramped desk. After typing for a bit, she exclaims, "See, it's doing it again!" Sure enough, spaces are appearing in her word processor, and her thumbs are not pushing the spacebar. Her breasts, however, are. I delicately explained to her that she is "leaning" on the keyboard. By rearranging her desk and seat, the problem was happily solved.<p>Probably the most apt PEBKAC I've witnessed.
> A novice was trying to fix a broken Lisp machine by turning the power off and on.<p>> Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."<p>> Knight turned the machine off and on.<p>> The machine worked.<p><a href="http://www.catb.org/jargon/html/koans.html#id3141171" rel="nofollow">http://www.catb.org/jargon/html/koans.html#id3141171</a>
Many years ago we had a webserver that would stop working every other Friday around noon. I couldn't figure out what the problem was. I was the de-facto systems administrator, just because the previous left, so I was not really into this stuff. It was not a big deal, this was a non-essential development server, so I didn't pay much attention to it. I figured out the server rebooted, and the webserver didn't start automatically after a reboot. This was a configuration problem, and if it hadn't been for this, I maybe never would have known about the problem.<p>About half a year later we were working in the server room, replacing a server when a colleague unplugged the old UPS in there. Unplugging the UPS for a minute shouldn't be a problem. The battery would take over and nothing would go down.<p>But well, the two servers attached to it immediately went down. It took me a minute, and then it dawned to me that this was the problem. The UPS did a test every other Friday, shut the power off as a test, which caused the two attached servers to restart, after which the webserver didn't start...<p>We removed the UPS as we didn't need it in the first place, problem solved.
My father encountered one of these voodoo issues once. He works in satellite images processing. Basically uses Spot data to analyse ground vegetation coverage.<p>One day while processing a batch, he noticed one parcel was giving the most awkward results. Totally different that anything he ever saw. This bug troubled him for almost a week, he couldn't figure out wether the satellite malfunctioned or if something was amiss in his calculation. Then it clicked, and a quick internet search confirmed his intuition. The satellite took the picture right in the middle of a solar eclipse!
Not quite as obscure, but the solution to "I can list my tarsnap archives but I can't extract them" is "fix your broken path MTU discovery" -- listing archives accidentally avoids MTU problems because it doesn't send enough data at once to fill a MTU-sized segment.
I have this problem. When I drive home after a long commute, I have really, really loud wheel noise (loud like impossible to ignore, turning your head on the street kind of noise). This only happens when I am driving 40 minutes or more, and only on the last couple miles to my house (which happens to be several miles of downhill driving with a fairly steep grade towards the end). The noise continues to persist, even at very low speeds once I get into town. If I let the car sit for just five minutes or so, the noise goes away.<p>This doesn't happen every time I drive home. It might depend on environmental conditions. It won't ever happen if I just go for a quick drive up and down the hill. The dealership has not been able to find anything wrong with it or come up with any explanation. This has been happening for over two years, it's a 2013 Honda hybrid, bought new. I've speculated if it could some brake-related issue that only manifests when braking regeneration is suppressed when the battery is full. Has me at my wit's end. When I get home from work the dealership is closed, and even if I could make it into the dealership with the thing clanking away, by the time I could get in and talk to someone the noise would go away unless I had them on the phone and ready to hop into the car at a moment's notice. So much for the warranty.
Back when I was a severely cheap and short-sighted college student I drove a beater Chevy Corsica that had a recurring problem: it would stall if I stopped the car.<p>Now I could start the car fine, usually. But after driving for a few minutes, if I came to a stop the car would stutter, lurch and stall. I would then restart the car with a bit more effort and continue to the next stop, where the problem got worse and it would take longer and longer to get the car restarted. But eventually the car WOULD restart and I would continue on.<p>It was the perfect confluence of conditions to promote all kinds of stupid behavior. I always said, "I'm not driving again until I get this fixed" and two days later saying, "wellll, I can make it to the supermarket before it stalls!"<p>This went on for MONTHS, with the overall problem getting steadily worse. I could feel the car fighting to stay running as I slowed down. I became a master of giving myself a huge lead up to red lights and slowwwwly lurching up to them, desperately hoping the light would turn. One time I took a rolling right turn at a red, did a u-turn, took another right and kept going. One time I stalled at a tollbooth for 10 minutes. Like I said, I was an idiot.<p>I was certain this was going to be some tragic $1000 repair that I could ill-afford. When I finally brought the car in, the mechanic could find nothing wrong - except my air filter was exceptionally dirty. The car had simply been choked to death and needed more and more WIND to provide oxygen for combustion.
List of software folklore, including this, the 500 mile email, and the rest:<p><a href="http://beza1e1.tuxen.de/lore/" rel="nofollow">http://beza1e1.tuxen.de/lore/</a>
Reminds me of Ubuntu Bug 255161: Openoffice can't print on Tuesdays (<a href="https://news.ycombinator.com/item?id=8171956" rel="nofollow">https://news.ycombinator.com/item?id=8171956</a>)
I think this is the first time ever I can provide at least some amount of verification to a story published on the Internet.<p>A family friend was a service advisor for a GM dealership in the 60's and early 70's. He told this same story to me in the late 70's.<p>Whether its true, or, was used to teach service advisors not to dismiss 'crazy claims I don't know. But it's been around longer than year 2000 cited in the story.<p>Edit: So its an urban legend. At least this one predates the Internet
We just met with a similar problem. Guy A met a with a problem that VM cannot be initialized repeatedly but guy B tried hard but still cannot reproduce.
Turns out that A's user name is just a bit longer and hit systemd's 2K line limit.
Ok this is a true story, and i still cannot explain it. But i will tell you anyhow.<p>We had a small clock that we kept in the closet. When you got up in the morning to get your clothes you could also see the time of day. In a quiet night, you could hear it ticking away.<p>One night it stopped ticking.<p>In the morning, we opened the closet to see if the battery had died. We gave it a good 3 seconds to make sure the needle wouldn't move, ... It did. It started ticking away.<p>The night that followed we stayed quiet and listened. It was quiet. So battery first thing in the morning. Morning came, we opened the closet door. 3 seconds later, it ticked. That was odd.<p>In the middle of the day we came to the closet, opened the door, the needle was still. Some seconds passed, the little clock started ticking.<p>Now it became knowledge in the whole family. We were kids so we would take it for a game. From time to time we would just stop talking and listen and hear nothing, we open the closet the clock is still, then it starts suddenly. We called it a ghost.<p>Years went by, new batteries were put in place, the clock still behaved the same. Everytime you started looking at it, it would start ticking.<p>It became a boring thing. No one cared about the little clock any more. I would open the closet, see it still, take my stuff and close it and it wouldn't even tick. But then i open it back up and it starts ticking two seconds later. Meh.<p>Then i had an idea. It was an idea so crazy that i was scared to try. I consulted with my brothers their eyes grew wide... So we did it... We removed the battery from the clock and closed the door.<p>Thr next morning was quiet. We were getting ready to go to school. All three of us stood in front of the closet door. Ready to see what was going to happen. My older brother opened the door. And the clock was there, quiet.<p>One second passed. I was afraid of what was going to happen. Two seconds passed. Lord please... Three ... Tick.
Interesting story, but who will put most popular item at the front of the store? It will be in the back of the store so customers will pass the other items in store and buy something compulsively
Another Parable:<p>I heard this in a presentation that was emphasizing the need to actually speak to the Ops folks before deploying the solutions that dev dreamed up:<p>A toothpaste factory had a problem: Due to the way the production line was set up, sometimes empty boxes were shipped without the tube inside. People with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming off of it is perfect 100% of the time. Small variations in the environment (which cannot be controlled in a cost-effective fashion) mean quality assurance checks must be smartly distributed across the production line so that customers all the way down to the supermarket won’t get frustrated and purchase another product instead.<p>Understanding how important that was, the CEO of the toothpaste factory gathered the top people in the company together. Since their own engineering department was already stretched too thin, they decided to hire an external engineering company to solve their empty boxes problem.<p>The project followed the usual process: budget and project sponsor allocated, RFP (request for proposal), third-parties selected, and six months (and $8 million) later a fantastic solution was delivered — on time, on budget, high quality and everyone in the project had a great time. The problem was solved by using high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box would weigh less than it should. The line would stop, and someone had to walk over and yank the defective box off the line, then press another button to re-start the line.<p>A short time later, the CEO decided to have a look at the ROI (return on investment) of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. There were very few customer complaints, and they were gaining market share. “That was some money well spent!” he said, before looking closely at the other statistics in the report.<p>The number of defects picked up by the scales was 0 after three weeks of production use. How could that be? It should have been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers indicated the statistics were indeed correct. The scales were NOT picking up any defects, because all boxes that got to that point in the conveyor belt were good.<p>Perplexed, the CEO traveled down to the factory and walked up to the part of the line where the precision scales were installed. A few feet before the scale, a $20 desk fan was blowing any empty boxes off the belt and into a bin. Puzzled, the CEO turned to one of the workers who stated, “Oh, that…One of the guys put it there ’cause he was tired of walking over every time the bell rang!”<p><a href="http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.htm" rel="nofollow">http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.ht...</a>
How many times I've skipped checking something because... There's no way it could be that!<p>Only to spend 3+ hours troubleshooting other things, discovering in fact, it was the simple dumb thing.
rofl that doesn't sound very logical. He didn't have ANY other instance of him starting the car fast enough that it triggered the vapor lock?<p>fun story though.
I once helped a coworker fix her not working keyboard in a fun way. Her computer was working fine, and her keyboard worked with any other computer, but not with her own. She tried all the usual things except one: I told her to unplug the computer and actually wait 30 seconds, not just power cycle it.<p>My theory is that the USB hub had a bad capacitor or some such which needed to discharge fully before communication on that port could happen. Funny thing is that she worked in tech support and would give this advice to others all the time.
There was a better story about a printer / print server I remember reading somewhere -- someone here will remember and link it I'm sure. This story is so obviously contrived -- what would happen to the gentleman after his car would not start? By the time he called Triple-A or whomever, the car would start again, so the problem of time would be obvious even to a non-engineer.
Believe it or not I had a problem a bit similar only it was a problem with my transmission. I called it the ATM/Convenience Store problem.<p>If I made a quick stop then got back in my vehicle the automatic transmission wouldn't shift from 1st gear. I had to do all kinds of shifting stopping voodoo to get it to work.<p>I had brought it to the dealership several times but their mechanic said nothing was wrong or he couldn't find anything wrong. I didn't tell them it was the ATM a using it I said it was quick stop and go situations.<p>It still does it ocasionally but it seems age and wear are helping diminish the occurrences.
This speaks volume on how human can rationalize any phenomenon. When faced with a unexplained event, we all try to rationalize cause behind it even if there's not the real cause.
some more "impossible bug" stories:
<a href="https://www.reddit.com/r/linux/comments/2p6qy5/4_impossible_bugs_any_other_stories_like_these/" rel="nofollow">https://www.reddit.com/r/linux/comments/2p6qy5/4_impossible_...</a>
The top comment here should be the one about "correlation doesn't prove causation". Secondly, this makes me think of Cargo Cult[1] programming practices. Your practices might be right, but it's much more valuable to know <i>why</i> they're right. [ or often, unnecessary, as CC practices usually are ].<p>[1] <a href="https://en.wikipedia.org/wiki/Cargo_cult_science" rel="nofollow">https://en.wikipedia.org/wiki/Cargo_cult_science</a>