You're solving the wrong problem

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

by coderholic • 14 years ago

192 38 14 years ago

sun123• 14 years ago

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

melling2• 14 years ago

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

HSO• 14 years ago

> medicines, cancer...

http://www.forksoverknives.com

melling2• 14 years ago

You're kidding right? Steve Jobs delayed his cancer treatment because he believed this sort of stuff. We do not know how to cure cancer by changing your diet.

shantanubala• 14 years ago

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

kisielk• 14 years ago

It's true that this is the problem, but it's not like people have not been trying to find a way to make the process quicker. It's not recently that we've been able to effectively start applying computational techniques to aid in drug development, before that it was mostly wet lab work.

Of course that's only going to help address the first stage of the pipeline, eventually you still need to do a bunch of research in to manufacturability of the drugs, clinical trials, etc. Those all take time. Maybe they could be sped up as well but I can't say that's an aspect of it I know much about :)

revorad2• 14 years ago

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

http://paulbuchheit.blogspot.com/2007/04/secret-to-making-th...

euroclydon• 14 years ago

He has a rather robust automatic weapon in that profile picture. It gives his grin a slight maniacal quality.

mekoka3• 14 years ago

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

evincarofautumn2• 14 years ago

A message from Guido van Rossum on the Python-Dev mailing list confirms this (http://mail.python.org/pipermail/python-dev/2006-December/07...). YouTube was launched in 2005 and the message is from 2006, so it’s a safe bet they’ve been Python-based right along.

“Quotes about Python” (http://www.python.org/about/quotes/) also has an entry for YouTube:

> “Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers”—Cuong Do, Software Architect, YouTube.com

revorad2• 14 years ago

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

teejae• 14 years ago

Yes, it was originally in PHP, but not for very long.

hythloday• 14 years ago

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

setrofim_• 14 years ago

"but other alternatives (for example, hiring a thousand engineers and building a thousand planes a year) would have found the same answer"

Before MacCready came along, there were a thousand (well, a large number) of engineers building a thousand planes a year. But because these attempts were disjoint, there were all making the same mistakes and were slow to learn from them.

The point of the article (as I understood it) is that when you're working towards a goal, you usually don't fully understand why that goal may be difficult to achieve -- what the real problems are. This is why is import to get early feedback about whether or not you're on the right track, and to adjust your attempts accordingly.

AlexBucataru2• 14 years ago

You are right: the problem was not the problem, but the available tools, namely the inability to "fail fast and cheap". However, I am not sure what alternative to building better tools first would be viable - throwing more resources into broken processes rarely, if ever, leads to results.

dstorrs• 14 years ago

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

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.

quietness• 14 years ago

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

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

mekoka3• 14 years ago

Improvements over small iterations. I think nowadays they'd call it Agile.

alextingle• 14 years ago

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?

evincarofautumn2• 14 years ago

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

drumdance• 14 years ago

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

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.

coffeeaddicted2• 14 years ago

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

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.

coffeeaddicted2• 14 years ago

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.

ColinDabritz• 14 years ago

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

oz• 14 years ago

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

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

sopooneo• 14 years ago

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.

ISeemToBeAVerb• 14 years ago

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.

dfragnito• 14 years ago

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.

RodgerTheGreat• 14 years ago

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

locacorten• 14 years ago

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

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.

semanticist• 14 years ago

Iterate rapidly to test environments, have more controlled releases to production.

You can also use techniques like feature switches to roll out experimental features to only part of your userbase, although even then you'd ensure basic reliability first.

To be honest, it sounds like you've confused 'iterate faster' with 'write crap code'. That's not what it means at all. It's HARDER to iterate faster with crap (presumably untested/untestable) code since you're piling technical debt upon technical debt.

Clean, tested, maintainable code is essential for quick iterations to succeed.

malkia• 14 years ago

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

You're solving the wrong problem

Related Stories