Hacker News new | past | comments | ask | show | jobs | submit login
The problem is we don't understand the problem (azarask.in)
172 points by cynusx on May 27, 2011 | hide | past | web | favorite | 19 comments

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.

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...

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.

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?

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:


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.

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.

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.

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!

     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.

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

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.

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.

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.

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.

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.

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

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

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact