
You're solving the wrong problem - coderholic
http://www.azarask.in/blog/post/the-wrong-problem/
======
coffeeaddicted
Slightly similar lesson I learned when developing games (and other 3d apps).
Make sure your debug-output is so good that you don't have to start the
debugger before you already have an idea what's going on. Simple stuff like -
your 2d and 3d cursor positions can be printed on screen always. You can add
lines and polygons which are visible for debugging in your code with a single
line (and you only comment them out afterward and don't remove them as you
will need them again). When developing things like A* - make sure you can
print every value on screen easily. Adding all those kind of easy debug-
outputs is usually worth it over and over again and still it often only gets
added to a project after people get stuck on the algorithms for too long. So
right problem in 3D-development: debug output first.

~~~
Drbble
If/then guards are better than commenting out code, so you can toggle debug at
runtime, or hardcode a constant to get an optimized production build that
skips the if-check.

~~~
coffeeaddicted
You need both. The thing with easy debug-output is that you start using it so
much that you simply get too much stuff on the screen at the same time if you
keep it all enabled.

------
hythloday
"The problem was the problem. Paul realized that what we needed to be solved
was not, in fact, human powered flight. That was a red-herring. The problem
was the process itself, and along with it the blind pursuit of a goal without
a deeper understanding how to tackle deeply difficult challenges."

I think this is untrue: people were solving the right problem, but doing so
with insufficient tools. MacCready's solution was to improve the tools, but
other alternatives (for example, hiring a thousand engineers and building a
thousand planes a year) would have found the same answer. Of course that
answer would have come at a much higher cost and for this problem it would
have been uneconomical, but there are plenty of domains where MacCready's
approach would have been suboptimal.

"Iterate faster" is a good lesson that I think is probably applicable for all
of us, but the temptation to solve tangential problems is a hard one to resist
and often unnecessary.

~~~
dstorrs
Check out _The Mythical Man-Month_ for a refutation of this.

Quoting from memory:

\- Nine women cannot have a baby in one month.

\- Adding more developers to a late project makes it later.

The problem is that in order for throwing a thousand engineers at the problem
to be time-effective, each one must communicate what he has learned to all of
the others. That takes time and adds friction.

~~~
baddox
Your examples are only true because gestation and many software projects are
not easily parallelizable. It's a rule of thumb that applies to many
scenarios, but obviously not all. If it takes 2 hours for one person to mow
his lawn, then 2 people could mow it in about 1 hour. 100 people really can
lift 100 times the weight of one person. Not to mention that nine women _can_
have nine babies in nine months.

Making many different aircraft prototypes simultaneously is certainly
parallelizable, although it obviously would be enormously expensive.

~~~
AlexBucataru
In experimental tasks, parallelizing does not provide the same gain in success
probability as accelerating the process of prototyping.

Building prototypes in parallel does not provide the benefit of a feedback
loop, as the iterative process does.

Let's say you have a 10% probability of success on the first attempt, which
improves by 40% after each experiment (to 14%, 19.6%...), and you have
resources for 5 attempts. The chance of getting at least one successful
solution is: parallel ~ 40.95%; iterative ~ 72.19%

------
revorad
"The secret to making things easy: avoid hard problems"

[http://paulbuchheit.blogspot.com/2007/04/secret-to-making-
th...](http://paulbuchheit.blogspot.com/2007/04/secret-to-making-things-easy-
avoid-hard.html)

~~~
mekoka
_[...]while YouTube built a product that people actually used (using PHP and
MySQL, I think, which is not at all technically impressive)_

Just some fact checking. Could someone confirm this? I've been told in the
past that Youtube was originally built with Python.

~~~
revorad
That's why he qualified it with "I think". Facebook was built with PHP. You
get the point.

~~~
mekoka
I did get the point, but next thing you know, in some random discussion, here
I am telling people that Youtube was actually developed with PHP/MySQL.

------
ColinDabritz
Wonderful ideas, and I love the discussion. Taking a step back and managing
the meta-process are very helpful skills if used at the right time.

I found the previous discussion interesting as well:

"The problem is we don't understand the problem" (April 2011)
<http://news.ycombinator.com/item?id=2591367>

------
drumdance
In this case, the problem domain is still very well understood and success is
easily defined in concrete terms: human powered flight across a distance.

In startups, you often start with one problem in mind but stumble on another
(and another, and another...). And even when you solve the technical problem,
you still have to solve the business model problem.

Yes, you may solve the problem of finding the cheapest flight through search,
but can it make money? And how long will it take to break even? etc etc

~~~
JohnnyBrown
So redefine the problem as "Use my software skills to address an unmet need in
a sufficiently large market" or "find a scalable business model" or something
else along those lines.

------
melling
Yep, this seems to be a problem with developing modern medicines, trying to
cure cancer, etc. The pipeline is a decade long.

~~~
HSO
> medicines, cancer...

<http://www.forksoverknives.com>

~~~
shantanubala
I know you have good intentions, but that documentary wasn't very realistic --
it wasn't really well-grounded in science.

For example, they keep presenting an argument about how milk protein is
harmful because lab rodents developed liver cancer when fed with a diet of 20%
milk protein, as opposed to rats fed with a diet of 5% milk protein. What they
don't mention is that many of the rats fed 5% milk protein died.

In terms of meat, they don't make a logically sound argument against eating
lean white meat or fish. Fish can be extremely healthy and nutritious. Every
argument presented in that movie applies mainly to red meats or unhealthily-
cooked white meats. They just use red meats as an example, and then make
generalizations.

And like most documentaries, they include anecdotes to keep your attention.

It's a movie with good intentions (it's a lot easier for the average American
to be healthy just by cutting down on meat consumption), but exaggerated
claims (meat -- especially fish and lean white meats -- and milk protein isn't
going to kill you, and can actually be very nutritious).

------
ISeemToBeAVerb
I agree with hythloday's observation that, in this instance, the problem
stayed consistent, it was the process that needed fixing.

While the prize hopefuls were only focused on the outcome, MacCready realized
that the process was equally important.

You can observe this in many industries. Find the biggest bottleneck in the
process, solve that problem, develop faster, rinse and repeat.

All in all, a very valuable lesson I think.

------
locacorten
Can someone explain to me how one can use the "iterate faster" method to build
highly reliable systems?

How would Google look like if they were to release GMail using an "iterate
faster" mentality? Your INBOX just got accidentally erased because of our UI
bug. Oops sorry, we'll release a fix in 5 minutes.

How about Windows? or a generic OS driver? Oops, your machine is just blue-
screening now. Don't worry, we'll just release an update in an hour. It'll
certainly make your OS drivers _very_ reliable.

Don't confuse the Web 2.0 "iterate faster" era with "the right way". Building
"iterate faster" systems is easy. Building systems "the right way" is hard.

~~~
scintill76
From the article:

> Find a faster way to fail, recover, and try again. If the problem you are
> trying to solve involves creating a magnum opus, you are solving the wrong
> problem.

I bet GMail and Windows do iterate and fail fast, internally. They probably
often do fix bugs within 5 minutes, and have continuous integration tests
running at least hourly. This is "the right way", and yes, it's hard. You
don't see the fast iterations in the final product, but that doesn't meant
they're not there.

------
sopooneo
Disney's seminal film was not Sleeping Beauty and it was not in 1959. It was
Snow White and The Seven Dwarves, twenty-two years earlier, in 1937.

------
quietness
"Find a faster way to fail, recover, and try again."

I think this line best summarizes the article, and applies in problems beyond
engineering.

------
evincarofautumn
> If the problem you are trying to solve involves creating a magnum opus, you
> are solving the wrong problem.

I disagree. If your goal is to create something great, you aren’t necessarily
so misguided—how you go about realising that goal is what’s relevant. The
Gossamer Condor was no less a masterpiece for having been created iteratively.

------
dfragnito
In solving the "right" problem more constraints were added to solving the
"wrong" problem. These constraints helped in solving the wrong problem. Often
constraints, self imposed or not(ie limited resources, etc..), produce
innovative solutions.

------
mekoka
Improvements over small iterations. I think nowadays they'd call it _Agile_.

~~~
alextingle
I think it's time for a new word to describe that concept. The word "agile"
has been co-opted by process dweebs for their latest bureaucratic nightmare.

"Fleet-footed" perhaps?

------
oz
This reminds me of Fred Brooks' concept of essential complexity and accidental
complexity:

<http://en.wikipedia.org/wiki/No_Silver_Bullet>

------
RodgerTheGreat
The core of this seems to be a different way of looking at the "XY Problem":
<http://mywiki.wooledge.org/XyProblem>

------
malkia
That's like taking your favourite language REPL and putting it to work in real
life :)

------
sun123
A lot of time is spent before we realise that we are solving the wrong
problem.

