

The problem is we don't understand the problem - cynusx
http://www.azarask.in/blog/post/the-wrong-problem/#

======
ChuckMcM
Its axiomatic that every proposal should start with a statement of the
problem.

MacCready's insight was that building a human-powered aircraft was 'easy' if
you knew how to build such a craft. (And in fact today you can take his work
and build your own Gossamer creation) So the challenge was this was a search
for a new airplane design methodology to explore the airplane design space,
and that this 'meta' problem had a much different form of solution than the
stated problem of 'build an airplane that does this.'

The applicable insight for entrepreneurs is that if someone thinks solving
problem 'x' in a cost effective (i.e. monetizable way) is "impossible", then
the search is for new and different ways to solve 'x' which are more efficient
than the well known ways. Too meta I know, sorry.

------
tintin
In my eyes a very misleading title.

The conclusion is: to solve a problem you need a tool with which you can
iterate fast.

The author states that we don't understand we need such tool...

~~~
mentat
It wasn't that by the end they didn't understand the problem, but rather that
by just attacking "build a human powered plane that can do <x>" they were not
making progress. Realizing that in order to "make a human powered plane that
can do <x>" they needed a lot more data and their development method wasn't
getting them that, they changed to "make a human power plane in such a way
that I can get a lot more data quickly". I'd assert that realizing that the
problem is getting data too slow as opposed to "working" too slow is not one
that's immediately apparent to most humans.

------
rvkennedy
This article summarizes my approach to just about every technical challenge
I've encountered since school. In grad school in particular, I could never get
my head around the approach of uploading code to a Unix server and running it
blind overnight. Instead, I would write it in Windows, but with a graphical
display of results coming out in minutes rather than hours. The errors would
then stand out glaringly. This is not to argue Windows v Unix as of course you
can do it either way on both platforms. But calculations you can see working
are priceless.

~~~
stcredzero
_with a graphical display of results coming out in minutes rather than hours.
The errors would then stand out glaringly...calculations you can see working
are priceless._

Back in the 90's in the workstation lab, I tried again and again to get fellow
1st year CS students to use the debugger. They'd always say, "I'm too busy for
that now!" Then, around 3am, they'd be desperate enough to let me show them
how to recompile with the debug option, and we'd take 60 seconds to find the
pointer bug they'd been pulling their hair out over for hours.

This is also why I love Smalltalk. Your objects and your code execution become
palpable, handleable things. You can even collect examples and put them aside
in groups for further categorization and pondering. Yes, not only do I
sometimes have little clusters of Object Inspectors on my screen, I have
sometimes had little groups of debuggers with alternate executions. This is
not the normal condition, but if you ever get into a situation where you are
making lots of comparisons, it's nice to know you can do this as easily as you
could for real-life objects on an actual tabletop.

EDIT: Yes, sometimes I will play around with little stacks of execution
stacks.

~~~
true_religion
The best part of small talk is all those inspected objects can come with live
execution stacks wrapped around them, so if you fix your code bug you can re-
invoke from a test example easily.

~~~
stcredzero
_if you fix your code bug you can re-invoke from a test example easily_

The best part is that you can re-invoke practically _always_!

------
bad_user

         He came to the startling realization that people 
         were solving the wrong problem. “The problem is,” he
         said, “that we don’t understand the problem.”
    

I don't see how the title follows from what MacCready said or did.

Not understanding the problem and solving the wrong problem are 2 very
distinct things.

~~~
hexis
Thinking that "problem X" is "problem Y" is one way to not understand "problem
X".

~~~
stcredzero
His insight was that the problem wasn't on level 1, it was on level 2.
MacCready realized that the iteration cycle was the problem.

Aerodynamics of conventional prop planes is by now a done deal. With anything
from a Piper-Cub to a 747, there are tons of similar craft already existing
you can imitate and a market from which you can draw funding to build near-
production functionality prototypes.

This was not true for the extremely low power region of the design space,
however. For that region of the design space, he returned to the "tinkering"
paradigm of the Wright Brothers.

There is a clear and clearly useful analogy for startups here.

------
ChuckFrank
Thank you. That was a fantastic story. The key here was to design a better --
design/build/test/verify/iterate -- system.

Once MacCready figured that out, creating the mylar + aluminum place becomes
almost intuitive. However the best part of the story for me was the fact that
this took place a full 18 years after the challenge had been issued. And we
worry about missing an opportunity to address the challenges by weeks or
months. Instead, let's remember that a solution twice as good will catch any
front runner.

------
zipdog
I saw the Gossamer Condor at the Smithsonian and was struck by how flimsy it
looked. But now understanding that the plane was designed primarily to iterate
quickly, that 'weak' design makes a lot more sense. It makes me wonder how
many projects are too concerned about the ultimate appearance before they get
the functionality complete, when appearance should flow from functionality.

------
wccrawford
I just wrote a comment yesterday about how I remove pain-points so I can work
more efficiently... This is pretty close. Nice to know the concept has been
around for so long.

Wish more people would think about it.

------
skarayan
Great article. As developers, many of us fall into the trap of build build
build. As smarter developers (and businessmen), we should create a cycle where
we fail quickly, learn, and get up.

------
johnrob
A very relevant application of this concept: the lean startup!

------
mikecane
Sounds like a tale Edward de Bono would tell!
<http://en.wikipedia.org/wiki/Edward_de_bono>

------
est
The X-Y problem

[http://www.reddit.com/r/programming/comments/gmdkb/the_xy_pr...](http://www.reddit.com/r/programming/comments/gmdkb/the_xy_problem_as_it_is_sometimes_called_is_a/)

