The XY Problem (2014)
The most amusing variant of the XY problem is when you want a <i>seemingly</i> 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 <i>that</i>, buddy.”<p>Even though Y was a concrete problem that they <i>do</i> have domain experience in solving!<p>I call this “going <i>up</i> the rabbit hole.”<p>——<p>Example (deliberately shortened from its real depth):<p>• I’m trying to invent a novel algorithm for inter-procedural data-flow analysis, because none of the existing ones work for me.<p>• 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.<p>• Why? Because I want to do program-slicing to recover HLL representations of key-value-store writes that the program does.<p>• Why? Because I want to use them as hints for my runtime execution tracer for said bytecode, so it can emit better traces.<p>• Why? Because I want to put those traces into an OLAP database and I want the data in the DB to be typed.<p>• 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.