When something that was working, suddenly doesn't work when demoing to others | Hacker News Reader

When something that was working, suddenly doesn't work when demoing to others

en.wiktionary.org

52 pointsatarian50 comments

This is part of a constellation of symptoms that I attribute to the Senior Engineer Field Effect. Other symptoms may include being unable to demonstrate misbehavior, losing the requirements out of your head, and solving a bug that has been bugging you for hours.

All by the mere proximity of a Senior Engineer.

Losing the capability to type while she watches.

> The phenomenon that something which was previously working correctly, suddenly does not work correctly when one tries to demonstrate the operation to others.

the same word is also used for the reverse situation, i.e. if something that did not work suddenly works when trying to demonstrate the failure.

think bug reporting e.g. at the car mechanic, warranty claims, etc. if you try to show a reproducible bug to others, it suddenly vanishes...

Is the word only for unpleasant surprises, or for all such situations, even when the surprising outcome is also a good one?

i've never seen it used for pleasant surprises. its basically if you want to show something (even something that does not work, like the engine-not-starting) and the demonstration does not work as expected.

They only have to be "unpleasant" in some aspect, for example because you now annoyed/bothered you team lead. The unexpected behavior itself can still be desired, with the unpleasantness restricted to the demonstration itself.

What's the word for this:

* My code doesn't work and I can't find the bug even after over an hour

* I add a few lines of <whatever code>. Now it works!

* Now, just for comparison, I remove all the code I just added (or, at least I think I reverted back to previous state). But now it still works.

???

Choose an editor with autosave to fix this one.

Now you have two problems.

I get that a lot, just have to restart that Docker desktop to push the saved changes to volume.

Clock skew?

Makefile (or a similar build system which uses timestamps) + a problem with wall clock -> stale files.

That could probably be called a Heisenbug[0]: A bug that disappears or alters its behavior when one attempts to probe or isolate it.

Though it depends on the cause - as others in this comment chain said, if it's just that the file isn't actually being updated between tests, but adding a new line forces an update/recompile/etc., I'm not sure what you'd call it.

[0] http://www.catb.org/~esr/jargon/html/H/heisenbug.html

DevOps

There's the alternative:

* The program works flawlessly

* Somebody finds a bug on the code that is executed in a test

* The relevant test now fails consistently

Both are probably because you changed something on the environment when you looked at the code.

Another common cause is that the code you were looking at wasn't actually the code you were running. Between "I added this line and then I removed this same line, and now it works", the executable might have been recompiled.

hot reloading can cause weird behaviors like this in particular

Once I added a comment and my bug went away. That was when I went home for the day.

cache?

The English-language term "demo effect" means the same thing.

https://quentin.delcourt.be/blog/2020-01-22_demo-effect/

https://www.urbandictionary.com/define.php?term=demo%20effec...

One should note: In contrast to other such composites, this is often used in everyday life.

What's the equivalent word for "Your computer suddenly becomes slow and unresponsive, you try to open Task Manager (or run `top` in a terminal) to see what's bogging down your resources, but the resource monitor itself refuses to respond for a few seconds until the lag vanishes, at which point the utility finally renders and everything under the CPU/Memory utilization appears normal" ?

That's a temporary system stall when some critical part of the system is overloaded or blocked, usually the disk.

Or an out-of-memory condition, the system recovers when the OOM killer has killed a random process. If you were lucky that process was your game hogging ressources and when it went away the system recovered.

And for impressive German words? "Systemaufstauung mit urplötzlicher Lösung" (system bottleneck with sudden resolving), "Speicherüberlastung" (memory overload) or "Prozessabmurkser" (process terminator).

Note that I invented these words (oder auf gut Deutsch, ich habe mir diese Wörter aus den Fingern gesaugt).

If you anticipate that this will happen when you open task manager, possibly because it has happened before, you start chanting in German “watch me, I’m about to pull a trick 17!” before opening task manager, having ensured that the whole room is paying attention whether you succeed. When people ask how you knew or why it worked you just shrug smugly to hide the fact that you don’t actually now, and let everybody bask in your aura.

I wrote this prayer to appease the Demo Gods [1]. Though one might pray, the demo can fail.

O Lambda the Ultimate, bless we who are in this demo...

    That our core be functional,
      and our functions be pure.
    That our data be immutable,
      so we may know the value of values.
    That our systems be composable,
      so they may scale with grace.
    That their States only mutate
      in pleasantly surprising ways.
    That the networks and servers stay up.
      Well, at least through this demo.

    For otherwise, nothing lives, nothing evolves.

    In the name of the \alpha and the \beta and the \eta...
      \(\lambda x.x x\) \(\lambda x.x x\) ; eternally

[1] Slide no. 5 here: https://github.com/adityaathalye/slideware/blob/master/n-way...

(edit: formatting)

A related thing that happens a lot is when the demo is way slower than it was when you were testing it. But at least this one can be explained by screen sharing applications adding latency to your refresh rate. It really is slower when you share your screen!

Whats the antipode to this, where, as a programmer going to investigate a user bug, my mere presences makes the bug disappear, and the user frustrated at trying to reproduce it for me?

Because this happens a lot to me these days, no kidding. The bug happens, some user delights in calling me over, I take a look, they simply can't reproduce it, I walk away - they get the bug again - and, yeah, I kind of have to race ahead of things to understand the nature of the users situation.

Happen to anyone else? I don't think its quite like Vorführeffekt, and is maybe a bit more like Daseinsvermögung oder etwas ..

It's fascinating to me how German composite words encapsulate an idea like "[failure attributed to] demonstration effect" in a way that just saying "demonstration effect" in English often fails to accomplish.

I also love how German often has useful opposites - schadenfreude vs fremdschamen, for example.

On that note, is there an opposite to this, where someone observes that something's not working, they call in the expert to diagnose the problem, and it functions perfectly under demonstration?

We sometimes use the term Houdini in my field for difficult-to-reproduce problems, but not exactly as an antonym to Vorführeffekt.

German dev here, we frequently filed this just as well under Vorführeffekt, probably even more frequently than the "standard" variant.

AKA "The Wrath of the Demo Gods."

Now, I have a word for it...

I believe the English translation for this is “uhhhh”

For presentations, always have a backup video.

In my company we call these "Show & Fail".

They often occur because we'll say "I just want to fix this one thing before we build the demo". We call this type of commit to the source control system a "break-in" instead of a "check-in".

Back in university, my compsci security project didn't work on the university wifi for some reason, if we used google chrome. Firefox worked fine. Some kind of weird proxy broke the website. But to this day I don't know exactly what happened.

Previous discussion: https://news.ycombinator.com/item?id=21170732

I don't think this one is going to make it into English. Vorführeffekt is a bit hard to pronounce.

Doesnt seem that hard to mangle into english:

Vore-fyur-effect

Fohr-fyur-effect [ˈfoːɐ̯fyːɐ̯ʔɛˌfɛkt]

Letter 'v' is called "fow" in German and is pronounced as sound "f".

The "v" is pronounced as an "f" in German. So, "fore-fyur-effect." English speakers could say "forfeit effect" a few times and then change the middle syllable.

I call it Singing Frog syndrome.

I'd have more use of a term with the inverse meaning.

Self-fulfilling prophecy?

I mean attempting to demonstrate something broken, only for it to work properly.

Wouldn't this term still apply? If the goal of your demonstration is to show failure, and then that succeeds, that makes your demonstration a failure.

That term definitely applies to any demo that behaves differently than previously observed - subtly implying that the demo setting has something to do with it.

I don't how it's used in German, but based on other comments, it does sound like it can be used either way!

As already said: Vorführeffekt is neutral and could mean both: success and failure. But the opposite of „a performance with an opposite than expected outcome“ is something that comes out exactly as it’s supposed to be without intervention, right? ;)

I always heard this called "The Law of Demo".

Definitely a thing!

What would it translate to? Inspection effect?

Edit: demo effect?

Was this word invented by google

Reply on news.ycombinator.com