The problem is we don't understand the problem

http://www.azarask.in/blog/post/the-wrong-problem/#

by cynusx • 15 years ago

172 19 15 years ago

wccrawford• 15 years ago

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.

tintin• 15 years ago

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• 15 years ago

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.

mayukh• 15 years ago

Got the same impression. The goal was X, realized that you first needed to do A,B,C before reaching X. Isn't that something we all do intuitively or intentionally all the time?

ivanmaeder• 15 years ago

I agree with tintin - it's not that the wrong problem was being attacked, it's just that the methods of solving the problem weren't very good. It's another example of protopying, and iterative and agile development beating BDUF.

Here's a great video on that:

http://www.ted.com/talks/tom_wujec_build_a_tower.html

bad_user• 15 years ago

     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• 15 years ago

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

stcredzero3• 15 years ago

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.

rvkennedy• 15 years ago

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.

stcredzero3• 15 years ago

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• 15 years ago

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.

skarayan• 15 years ago

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.

ChuckMcM• 15 years ago

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.

mikecane• 15 years ago

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

johnrob• 15 years ago

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

ChuckFrank• 15 years ago

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• 15 years ago

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.

est• 15 years ago

The X-Y problem

http://www.reddit.com/r/programming/comments/gmdkb/the_xy_pr...

The problem is we don't understand the problem

Related Stories