If the poster is referring to the comic, the geotagging is the chair, the bird identification is the toilet, and the act of "moving" is the effort involved.

An analogy that could more closely fit could be something like: You have a new kubernetes cluster and some servers running code. You're migrating some services over (moving rooms). If you have a simple webapp that has no persistent storage and is containerized, the move would be simple (like moving a chair between rooms). However, if you were to try to move a webapp with login info and databases, there's a lot more "plumbing" not apparent to an outsider that would take a lot more work.

I think the analogy best captures "some things are easy, some things are hard". For instance, if I were the stakeholder and this analogy was used to convince me that moving a web app that uses a database is hard, I would still wonder what you really mean (and I have lots of experience with Kubernetes). Probably better just to say what is actually hard instead of reaching for an analogy unless you just want to get past the stakeholder's "BS firewall" easily so you can get back to work. If that is your goal, absolutely use any persuasion tactic at your disposal. However, this scenario has a massive bug: the non-technical stakeholder didn't delegate decision making to someone that they can trust.

The analogies shouldn't be needed at work for sure, but they work well for people who aren't industry and don't especially care. Eyes glaze over at anything beyond "database" but people know about moving toilets so they appreciate the analogy when you're at a family reunion or something.

Perhaps, but those people are the bug in this hypothetical. They should instead delegate decisions to someone who is competent. Obviously the real world is filled with bugs of this nature, but helpful to at least recognize where the problem stems from.

I give you this:

Yesterday, I delivered a long-asked for feature - optimistic updates for a UI screen after a button click on Screen #1. It took only one day because the server-side logic is entirely under engineering control and the only edge cases are "their account was concurrently drained" or "the person who clicked the button is trying to hack us". Both of which will be handled when the server responds with a non-successful response. There is little to no likelihood of this behavior changing any time in the next 10 years so I ensured coupling between these components was respected with a simple comment in both places.

Today, you are asking me to provide an optimist update for a button click on Screen #2. However, that button runs business logic that is specified by multiple other users in a scripting language based on a variety of inputs, some of which are dependent on the responses of external systems over which engineering has no control. The response's fields are known in advance, but those fields' values are not.

Of course, anything is _possible_ and if we build a feature where users can specify the likely result of the external systems and build a heuristic-based analyzer for common patterns in the scripting language we could eventually get to the point where simple screens driven by this monstrosity could optimistically update. However, it will take a lot of development work and the testing effort will be high, both for the initial design of the feature and to add sufficient integration / system tests to ensure that future updates to any of these systems do not break common assumptions between them.

Honestly, I think the bottom line is decision makers need to be technical. If you are responsible for an area and are non-technical you must find someone who 1)you can trust and 2)has the requisite background such that you can fully delegate to them. Anything else is essentially irresponsible. The only thing analogies help with is essentially to convince non-technical people who do not trust you that you aren't lying to them.