The XY Problem (2014)
The most amusing variant of the XY problem is when you want a seemingly ridiculous Y, and then, when people inevitably ask why, you tell them about your entirely-novel X, which they still don’t understand the use for, so you have to explain the entirely-novel W that motivates X, and so on... and by the time you’re done, you’ve explained your whole business model, written a ten-page journal paper, and completely killed the conversation—because they don’t feel they have the prerequisite knowledge to talk about A-through-X, so you just get a “good luck with that, buddy.”Even though Y was a concrete problem that they do have domain experience in solving!I call this “going up the rabbit hole.”——Example (deliberately shortened from its real depth):• I’m trying to invent a novel algorithm for inter-procedural data-flow analysis, because none of the existing ones work for me.• Why? Because I’m trying to reverse a stack machine bytecode with only indirect jumps and no reified CALL/RET opcodes, into a structured inter-procedural control-flow-graph.• Why? Because I want to do program-slicing to recover HLL representations of key-value-store writes that the program does.• Why? Because I want to use them as hints for my runtime execution tracer for said bytecode, so it can emit better traces.• Why? Because I want to put those traces into an OLAP database and I want the data in the DB to be typed.• Why? Because these traces are the only canonical representation of the state of the system, and our business model is allowing auditors to figure out what’s going on with the system.