Hacker News new | comments | show | ask | jobs | submit login
Car allergic to vanilla ice cream (2000) (uwaterloo.ca)
753 points by kornish 261 days ago | hide | past | web | 133 comments | favorite



Sent this to my father, a control systems engineer. He responded with his own story:

"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.

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.

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

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.

Turned out to be a loose wire. The shaking from the fire hose always fixed the problem temporarily and reinforced his belief.

He was truly disappointed."


Shaking things often fixes problems. This reminds me of the following story:

> [O]ne of the earliest [applications] of dither came in World War II. Airplane bombers used mechanical computers to perform navigation and bomb trajectory calculations. Curiously, these computers (boxes filled with hundreds of gears and cogs) performed more accurately when flying on board the aircraft, and less well on ground. Engineers realized that the vibration from the aircraft reduced the error from sticky moving parts. Instead of moving in short jerks, they moved more continuously. Small vibrating motors were built into the computers, and their vibration was called dither from the Middle English verb "didderen," meaning "to tremble." Today, when you tap a mechanical meter to increase its accuracy, you are applying dither, and modern dictionaries define dither as a highly nervous, confused, or agitated state. In minute quantities, dither successfully makes a digitization system a little more analog in the good sense of the word.

— Ken Pohlmann, Principles of Digital Audio


> Shaking things often fixes problems.

Oh, indeed. I remember my father, a disabled former engineer, having an expensive McIntosh audio system. He was always fiddling with it, fixing it, applying anti oxidation spray, etc. My parents decided the large wall furniture (in which the audio system was, together with books, TV, etc) was to be replaced.

It turned out that during the giant relocation one of the compartments of his system (IIRC it was the tuner, but it might have been the pre-amplifier or amplifier as well) had become broken. My father, who was nearly blind, made it his project to repair the installation. He was failing, and my parents discussed sending the broken part of the audio system back for repair which would set us back a large sum of money.

Then, at some point, there was an earthquake of 5,5 on the Richter scale. (Having just looked it up the epicenter being 5,8 it was the largest earthquake ever registered in The Netherlands.)

The damage: a photo of a family member, protected by glass, had fallen and the glass was broken. In our wall, a rift appeared. Many things just weren't on their correct place. The radio? Ah, the radio. It worked again when it was put on!!


A similar phenomenon occurs with aircraft altimeters. They move smoothly in small propellor planes but tend to stick and then jump maybe 50ft at a time in gliders. Tapping the altimeter is standard procedure if you want to see small movements.


And also with humans! Vibrating insoles can make the elderly less prone to falls, because adding noise can bring the signal of differential pressures on parts of the foot high enough for them to feel that they're off-balance before they're unable to recover.


It might even help on maintaining your bones healthy ! [1]

[1] https://www.ncbi.nlm.nih.gov/pubmed/27145947


Or as Arkwright always said "just j-j-jiggle it a bit".


It can also help with some occasional minor digestive issues.


A classic!


I had a mouse that would stop working occasionally. The pointer would jigger and shake, or get "sticky" on some parts of the screen.

After a few weeks I narrowed the problem down, it happeneed in the late afternoon, but it worked fine in the evening. It also worked when it was raining.

So it had something to do with the sun shining through the window.

So I took the mouse apart and found that it had little rollers inside, each roller had a small black disc with holes in it. An LED one one side and a photoreceptor on the other... I assume it worked by counting the flashes of light through the holes in the disc.

The plastic cover on the mouse must be semi transparent and when hit by the sun, the photoreceptor was giving weird readings. I covered the mouse in black tape and never had the problem again.


I posted this before, but it's worth repeating now:

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.

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...

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!


Why does a touch typist suddenly look at the keyboard when he's standing up? Or are the people standing the same that don't know how to properly use a keyboard?


It's an awkward position for your wrists to be in. You can't touch the home row with most of your fingers and hit the digits comfortably at the same time. That means moving your hands a lot, which means touch typing is likely to go badly.


This awkward position has to do with the position of the keyboard relative to the shoulders (thus how the arms are positioned so the fingers reach the keys). There's nothing inherent in standing itself: just whether the desk set up positions the keyboard correctly. This is true whether standing or not. Standing versus sitting is mostly a difference from the waist down, is it not?

Edit to add: It appears my parent and I had different assumptions regarding the setup, which we cleared up below.


The thing inherent in standing is that you're higher up and the desk isn't. (Presumably this wasn't a height-adjustable desk.) So your arms are more extended, not in the standard orientation for touch typing.


Gotcha. I was assuming the desk is set up appropriately whether seated or standing. I think we're in agreement that improper environments are improper. :)


What an odd assumption to make.


Perhaps. Maybe even a mistaken one. What's great I think is that people can discuss things and figure out why it is they might have some disagreement, and learn that there might not actually be one, perhaps only due to a misunderstanding.


Yes, height-adjustable desks are a relatively recent thing.


The best height adjustable desk I've ever had was back in 1999. It even had the extra burden of raising a 22" CRT I had at the time.

Admittedly I've not looked hard, but never saw a desk for sale as good as the ones Southwestern Bell had for everyone back then.


Wow. I had no clue. Do you remember the manufacturer?


Wish I did. Been looking for one similar since and never found one (as said before, not looked hard, but have definitely tried off and on).


Source and one discussion of this tale that I know of, there was also a HN thread but I cannot find it on my phone.

https://www.google.com/amp/s/amp.reddit.com/r/talesfromtechs...


So, to some extent, that was a PEBKAC issue, no? ;)


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.

What do you know? I google "snopes car allergic to ice cream" and find that it's an urban legend: http://www.snopes.com/autos/techno/icecream.asp


It's not that far fetched though.

I had a an old motorcycle years ago that was the same way as this guy's car. If I stopped to grab a snack, my bike would not start again. If I stopped for lunch, then it would fire back up no problem. Sure enough the problem was vapor lock. However the time needed for the bike to cool enough was about 15-20 minutes, not the couple minutes mentioned in this story.


It's definitely a thing that can happen, just not in the time frames mentioned here. 5 minutes for a snack vs 30 minutes for dinner sounds plausible, 3 minutes for vanilla vs 4 minutes for chocolate does not.


We used a two stroke atv. My father would go to the store (2km) and come back, no problem. I would go to get water from a spring (7km) and the engine would just die after about 4km. It turns out that the gas mixture was too light and the engine was overheating, but only after 4km of continuous run.


Ok how about: had the car detailed, cleaned and new floor mats. Filters and fluids replaced. Tires rotated. In a super-service place. Paid and went to the parking lot - car wouldn't start. Not even a click. Just nothing.

What could it be? Nothing that was done was related to ignition or electrical systems at all. Yet it wouldn't start.

<spoiler> the new floor mats were too thick. Couldn't push the clutch down far enough, and this manual car you had to have the clutch in to enable the ignition. Just nudged the new mat back, problem solved.


Yeah, I doubted the veractiy as well. Fortunately this is a story that still works even if taken non-literally.


Pretty sure it's just meant to be a parable.


In addition to that, there's no way the engineer waited until subsequent nights to try other flavors.


What? You wouldn't want to get paid to eat ice cream?


I would. But why not today?


Eh, that's just your assumption. It's a guy in a fine neighborhood going to the store after dinner. For all we know the store is (excuse the pun) deserted at that point.


Also, he's not always getting only Ice Cream I'm sure, he's going to be grabbing other stuff, which depending on what he needs to get is going to create variable times (not to mention the length of the queue).

Driving to the store every night for Ice Cream seems like a waste of time, unless he really needs to get out of the house.


The only urban legend here is the fact that Snopes is somehow running Active Server Pages.


the OP is a page from an ice cream fan site, not a journalism organization

http://www.cgl.uwaterloo.ca/smann/IceCream/


That's really missing the point of the s/story/parable.


"Moral of the story: even insane-looking problems are sometimes real."

Isn't it relevant to note that this problem was not real? It seems to kind of undermine the point if the author did not know of any insane-looking problem that was actually real, and had to make one up...


No, it really doesn't.

If you're hung up on the fact that the story isn't real, it means you aren't thinking about the moral of the story. You're focusing on the wrong thing despite the fact that the insight is being spoon-fed to you...

Incidentally (though respectfully... really!), this is a textbook example of pedantry, and it's the bane of our profession.

More to the point, fiction often points to truth in ways non-fiction cannot.


It's not insightful if insane problems never actually happen!

It's fine if the author uses a fictional story because it flows better. It not fine if the author uses a fictional story because they can't source a single real one.


I call them misplaced pattern diagnosis. They are real and I see them frequently.

There's no reason to make things up. Just listen to the old car talk shows - you hear one almost every episode.


see emails not going out more than 500 miles story



So koans, proverbs and parables are not insightful by nature. Fiction is insight-free entertainment.

Got it.


You have to be deliberately misreading me to get that interpretation. I said fiction could be fine.

Stories can be insightful or not-insightful based on what they teach.

Some kinds of thought patterns are useful to consider even if there is no basis in reality. Some aren't.

This story is in the latter group. If insane problems never happened, then this story would not be insightful.


Same thing with the bible...


I love you.


Like most urban legends it's not only bullshit it has a evil side.

Re read the story, it has a lot of darkness to it.

It also teaches a bad idea. No, more often than not things have simple solutions. Not the highly complicated version here of sending out an employee.

Just get the car serviced.


I've seen and read lots of parables that end with the phrase "moral of the story" when distilling down the core lesson behind the tail for the convenience of the audience. Moreover, the term "story" doesn't necessitate factual content - it's generally used more to convey an entertainment piece of which the content could either be factual or entirely fictional.


This isn't an incorrect comment, but I'm not sure it's a good one.


Reminds me of one of my all-time favorites -

The 500 mile email

https://www.ibiblio.org/harris/500milemail.html


Don't forget the magic switch:

http://catb.org/esr/jargon/html/magic-story.html

(Also mildly upset that units on OS X only has 586 units and 56 prefixes, fortunately brew install gnu-units to the rescue!)


This is my favorite way of explaining why being a sysadmin is hard and requires more than just knowledge of computers.


Fun read!

If you're interested in computer stupidities this website (lynx friendly) is one of my favs: http://www.rinkworks.com/stupid/

Most of them aren't related to engineering; rather computer helpdesk stories from the previous century.


Haha, this was indeed posted with that all-time great in mind.


Seconded... great lesson in sleuthing technical problems.

There was another that amused me about the server rebooting in a haunted data center:

http://www.greendatacenternews.org/articles/763167/the-haunt...



Another (real) story of my own:

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.

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.

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.


I had a similar story from just a few weeks ago. One of my colleagues was having trouble logging into his test instance, but he was the only one having this problem. Tried on my machine and it worked fine, made sure we were both using the exact same version of the code, etc. and he continued to have the problem while I didn't... Eventually we realized that he only had this problem on firefox and not chrome, and then we finally realized that the problem was in Firefox he had his credentials saved and was hitting the 'Login' button, whereas on Chrome he was typing them in and hitting enter, which is apparently what I and the rest of my colleagues also do, but luckily he found that bug with a slight difference in the logic between the two paths before it went to production.


And the solution for brian was to click OK instead of doubleclicking? :D


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.

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.

Please isolate the problem when reporting bugs!

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=677633


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.

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.

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.

> 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."

> Knight turned the machine off and on.

> The machine worked.

http://www.catb.org/jargon/html/koans.html#id3141171


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.

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.

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...

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.

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 think thats the same reason why you can still do a SSH connection to a server with a wrong MTU setting. This helped me fixing a Synology NAS (couldnt access the web interface anymore)


SSH over wrong size MTU killed a lot of my time one day too. It took me so long to figure out what was wrong, when a few of the connections would be working fine while others would just show me a dead screen after a while. In the end i decreased the MTU on my machine and it stopped happening mostly, but would still do it every now and then.


Yes, "interactive SSH works but I can't scp files" is also a common diagnostic for broken MTU setting/discovery.


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.

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.


I had the same problem. After unsuccessfully trying several garages to fix it, I learned how to fix cars myself (read lots of blogs, watched video on YouTube, read a couple of books) and redid the whole brake system: disassembled the caliper, cleaned everything thoroughly, changed brake pistons, changed sealing rubbers and dust covers, installed new brake disc and brake pads, new brake pin (greased it with the appropriate grease). Problem went away.

It was a rusty/incorrectly installed brake pin. Sometimes brake pads wouldn't return after you stop pressing the brake pedal. After brake system rebuild everything moves smoothly and brake pads always return to the initial position - no more weird sounds.

Also, when changing the brake pads, I've noticed that one of the pads (that was failing to return) was much thinner than the others.

Problem is: when they change the brake pads in the dealership/garage, they don't rebuild the whole system or grease the pins properly. You will not notice and they're not paid for the extra quality work. So things like this happen quite often.

The only way to do everything properly is to do it yourself. In case of a brake rebuild it's not very difficult but very time-consuming. Most difficult part was to insert the new piston back in the caliper.


Without hearing it I can't say for sure, but do you brake intermittently or continuously while going downhill?

If the latter, it'll likely be a caliper & disk getting hot and expanding, and rubbing, which can make an almighty racket - and then when they cool again they contract, meaning that a cold inspection would reveal little.

Alternately it's a wheel bearing on its way out, but that's unlikely on a new vehicle.

Does it get any better or worse when you apply steering, or not change at all?


Yeah check noise response to steering. I suspect CV joint problems. Very commmon, but often not disabling.

https://en.wikipedia.org/wiki/Constant-velocity_joint


I purposely brake intermittently. But, the brakes are definitely very hot when I've checked them.

I had wheel bearing issues with a previous older car, under similar circumstances. I checked steering, it doesn't seem to make much difference. The dealership dismissed wheel bearings as a possibility and said they checked the CV joint.

Their only theory the first time around was a small rock or something getting stuck in there and working its way out. The old "mud in your tires" sort of thing I guess (Joe Pesci reference). That's a mighty devilish rock.


when reading this, and from my own experience, I think it are the brakes. But only that it also happens when you don't break continuously. Could it be a CVT geared car has a lot less resistance on the engine, even in the L position, compared to manually geared cars?


Disclaimer: I know little about the technical details of cars.

I don't know if it is the same noise, but I had a loud, fast paced, 'whoom, whoom, whoom' sound on my Honda Civic Hybrid from 2008 when going downhill a lot.

Living in the Netherlands (mostly flat) I only had this during holidays in less flat parts of Europe. Never thought much of it and when asking the dealership they never heard about the problem, but also could not see anything wrong with the car. And it only was reproducable in mountain areas, and took a while to surface...

Then after about 3,5 years, after a holiday, the sound was almost always present. Drove to the dealership and the brake discs needed te be replaced, they were 'square'.

I was not allowed to drive another mile (kilometer in my case ;) with the car.

I always brake as less as possible going downhill, and always use the L (low) gear position, but can't prevent it. The roads in the Swiss Alps are so steep, only low gearing does not help, at least not with a Civic Hybrid. I don't drive with my foot on the brake all the time, but pump the brakes when really needed.

(in comparison, the Seat Ibiza Diesel car I had before could slow down a lot better in low gear, almost no braking was needed, but when going downhill with the Civic in low gear, it goes faster and faster, until you just must brake. Also the Ibiza was manual gear, like most cars in Europe, the Civic had a CVT)

The dealership thought it could be a result of the brakes getting hot when going downhill (cannot be prevented) and then keeping the foot on the brakes when standing still deforms the braking discs.

Using neutral gear position and if needed the handbrake when stopped, could be prevent it from happening again.

After replacing the discs I drove the car another 1,5 years until October 2013 and never heard the sound again.


You should use a lower gear going downhill


I always use low gearing when going downhill, updated the story.


The word is"brake"...


Oops, you're right, corrected above. (I am not a native speaker)


Depending on the hill gradient and if it's safe, you could try going downhill on the commute using just engine-braking (use a low gear) rather than riding the brakes. This could help determine if the problem is brake-related or not.


Unfortunately it takes long enough to reproduce and is unreliable enough that I'm not willing to do enough trials relying on just engine-braking that I would be able to draw any firm conclusions. I have tried relying on gearing and I suspect it has something to do with the brakes but I don't know.

The last stretch where it goes down to 40 and then 30 is steep enough that engine braking without any brake pressure at all is not going to happen safely. And there are lights too, I almost always (but not always) hit at least a couple of them coming into town, so stopping is kind of mandatory there (and unpredictable).

I don't have a habit of riding the brakes though, I'm either gently depressing them or my foot is off. But without gearing down there's going to be a significant amount of intermittent braking; just not continuous.


List of software folklore, including this, the 500 mile email, and the rest:

http://beza1e1.tuxen.de/lore/


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.

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.

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!"

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.

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.


My first car was a Chevy Corsica and I had a very similar problem, finally donated the car and got a different one. I wonder if my air filter was bad as well...


Reminds me of Ubuntu Bug 255161: Openoffice can't print on Tuesdays (https://news.ycombinator.com/item?id=8171956)


I think this is the first time ever I can provide at least some amount of verification to a story published on the Internet.

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.

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.

Edit: So its an urban legend. At least this one predates the Internet


Snopes, already mentioned on this page, notes that it is an urban legend, and that it has reversed sense over 30 years, with vanilla/pistachio originally being the flavour(s) where the car would start.


This is why I take every bug report seriously, no matter how implausible.

I might not always be able to figure it out, but I at least try.


Ok this is a true story, and i still cannot explain it. But i will tell you anyhow.

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.

One night it stopped ticking.

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.

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.

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.

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.

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.

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.

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.

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.

One second passed. I was afraid of what was going to happen. Two seconds passed. Lord please... Three ... Tick.


Perhaps the clock runs on solar power when it can't run on battery power? There might be an issue with the connections or wiring that prevents battery power from working, which would explain why replacing the battery didn't help.

I'm sure that's not the only possible explanation.


I have a clock, which I brought overseas with me, that usually runs backwards. Every once in a while, it'll tick louder than other times. Every once in a while, it'll start running forwards.

It is just an alarm clock that runs on batteries. I'm unsure if the alarm function still works or if it keeps time, even though it runs the wrong way. It is weirdly one of my favorite possessions - in fact, "The Clock which keeps Untime" is generally the only visible clock in the house save for computer monitors.


Maybe the vibration of the closet door made something contact correctly?


I like how the traditional 'five whys' approach wouldn't work here... the answer was in a 'how'.


Perhaps a "why is there a timeout?" would have lead to a "why is this traceroure so long?" then "why is there a loop?" and "why is my test router in the list?"


> 'five whys' approach

Can you explain this a bit more?



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


Haha, this has already been debunked mostly due to the time difference being negligible, but I like your "rational capitalist" approach.


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.


Dear deity...


Another Parable:

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:

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.

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.

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.

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.

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.

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!”

http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.ht...


Slight nitpick, but if someone got tired walking over every time the bell rang, then surely the bell must have rung several times, in which case the scales must have picked up several defects, not zero.

You do also need to factor in the electricity costs for the desk fan, although it probably still is a lot more economical than the $8 million solution.


I read it as "after three weeks in production, they noticed that the daily defect rate was now 0 instead of the dozen or so that they expected".

Natural languages are ambiguous...


I thought the moral of the story would be "correlation does not prove causation."


How many times I've skipped checking something because... There's no way it could be that!

Only to spend 3+ hours troubleshooting other things, discovering in fact, it was the simple dumb thing.


> How many times I've skipped checking something because... There's no way it could be that!

I TA'd a course in college that (among other things) was the first introduction that CS students at my school had to C programming. Since most students had no prior experience with anything besides Java (and a little OCaml, because one of the intro courses was half Java and half OCaml), they often would be at a complete loss of how to debug errors with pointers, string handling, etc. Whenever I tried to help students debug something in office hours, they would try to steer me away from looking in certain parts of their code because they "knew that was correct", and quite often the error would be in one of those parts of the code. The lesson I tried to teach them was that if you thought you wrote all your code correctly but it still doesn't work correctly, then you must have been wrong about something, so you have to be ready to challenge your assumptions about what's working and what isn't.


Occasionally, the fault isn't even really in the code! I remember some years ago spending a very long time debugging some code for my school coursework with my teacher. The code looked perfectly fine, but it didn't work. The usual process of commenting parts out didn't work. We finally realised the code editor was inserting a byte order mark into the file which caused the problem.


This is a great story. I have run into plenty of obscure problems like this in software development with "not reproducible bugs".


Guy should have called Click and Clack



For those too young or unlucky to pick up the reference, parent is referring to Car Talk, a radio show featuring Tom and Ray Magliozzi and their live solutions to automotive problems (also, existential life questions).

After running for decades, it was finally retired in 2012. The archives remain, in my opinion, some of the finest exercises in logical problem solving.

http://www​.cartalk.com/


For better or worse the show is still airing "best of" episodes. I hear the end of it every Saturday morning when I switch to my local NPR station to hear the show that comes on after it.


Hope this doesn't ruin it for you, but I knew someone who had a problem presented on the show. She called in and reached an answering machine. Someone called her and qualified the problem. Then one of the brothers called and talked to her for a while. Then a few weeks later (there might have been some more calls, I don't know) both brothers called her and talked to her for a while. Her parts of that last call was edited into the radio show so it sounded like she had called and they just figured out the answer on the spot.


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.

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.


Usually that sort of request is made in tech support not because the action is more useful, but because users are clueless or will outright lie about power cycling. Asking something unusual like this gives you better odds that they will actually do it, rather than, say, power cycling their monitor, or pretending to power cycle because they're terminally lazy.


Of course. But apparently once in N times it does something.


Right. I didn't mean to imply it would always be useless, just explain why someone who works tech support might not follow their own troubleshooting steps to the letter in this case.



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?

fun story though.


Sounds fake. Engineer would have tested it multiple times on same day, not wait stay 3+ days just to test once per day.


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.

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.

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.

It still does it ocasionally but it seems age and wear are helping diminish the occurrences.


They eat ice cream every day??


Even crazier, they don't buy more than one nights worth.. so they make a trip to the supermarket just for ice cream every night. (It's just a myth)


If you go back to the fifties or sixties it's quite possible a family might have a car but not a freezer.


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.


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.



And this is why I miss car talk...


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 why they're right. [ or often, unnecessary, as CC practices usually are ].

[1] https://en.wikipedia.org/wiki/Cargo_cult_science


I read this story 15 years ago and always cite it.

Pleased to see it again




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: