Easy Magic and Hard Magic

Published 2 Comments on Easy Magic and Hard Magic

A conversation with Merlin:

Me:  Hey, can you conjure up a cow?
Merlin: Sure [POOF].  Easy.
Me: Cool!  How about a purple cow?
Merlin: Oh, hmm.  That’s hard.  Yes, but it will take a while.

A conversation with an engineer:

Me: Hey, can you make the data come back in date order?
Engineer: Sure [clicky clickity].  Easy.
Me: Awesome!  How about in order of relevance to the search?
Engineer: Oh.  hmm.  That’s hard.  Yes, but it will take a while.

A conversation with me:

You: Hey, can you design the IA of this website?
Me: Sure, [sketch, sketch].  Easy.
You: How about this other website?
Me: Oh, hmm.  That’s hard.  Yes, but it will take a while.

To someone who doesn’t know how it works, it is absolutely impossible to understand if something will take 30 seconds or 30 days.  Even if you ask for what seems to be the same thing, the differences may be enormous to the practitioner.  (Example:  Brown Cow, Purple Cow)

This problem exists throughout the world.  I experience it nearly every day.  People need to schedule projects and they need estimates from the different participants to help make the project go smoothly.

What makes this most difficult is that small differences are often arbitrary.  Often a decision maker asks for something in such a way that it takes a long time to produce.  However, a slightly different, yet equally valuable thing might take just 10 minutes.  How do we communicate with each other to get the 10 minute version?

The missing ingredient is usually asking the craftsman for options.  It never happens this way.  You ask Merlin for a cow, but what if you really just want milk?  What if conjuring a cow is hard, but a glass of milk is easy.  The key is to talk to Merlin about your problems and ask for solutions, not to come pre-baked with a solution.  The more specific you get, the more likely you are to trip over some unknown difficulty.

Lesson: When you ask for things from a magician, be aware that little differences to you are big differences to them.



  1. You’re right that “asking for options” is often missed, but instead of just giving an answer, you should ask back for context. That usually helps understand what the asker really wants, and also usually makes it way easier to provide an answer. Of course thereare cases where the asker really just wants a plain answer, eg. to forward your estimate in that meeting he attends in the next minute. The trick then is to find out quickly if you should ask back or not.

  2. One technique is “The 5 Whys”: keep asking–tactfully–why they need the solution until you can get to the root problem. It will take several rounds of “why do we do this?”, or “why does it have to be that way” but in the end you’ll have a much wider field of options for solving the problem.

    Understand where the users are coming from: as a user I feel like I’m saving time and doing my due diligence if I can research my own problem and come to a solution-provider (e.g. electrician, mechanic, etc.) with what I feel is the right solution; however, as a developer I feel like the user should rely on my experience and “expertise” (I’m using that loosely) to suggest the appropriate solution.

    I think I’ll make a mental note to watch how experts in other areas handle this dilemma with me, e.g. the mechanic with the humorous sign about charging more when I insist on offering suggestions.

Whatya think?