9 ms·

Solving the Wrong Problem (2011)

142 points by dedalus 7y ago

muglug 7y ago
Needs a (2011) tag
- dang 7y ago
  Added now. Thanks!
personjerry 7y ago
Similarly, startups are in the business of iteratively failing and learning about their problem. By reframing the problem, he effectively "startupify'd" the problem.
a_c 7y ago
Identifying the right problem is indeed the golden nugget. Teams chasing after arbitrarily defined KPI, with no feedback loop in place, or the feedback is 1 year later. Implementing features based on feedback from 1 customer, then find out the customer wasn't articulating the problem at all. Projects eager to adopt the latest technology, using every bit of service AWS provide, jumping onto the jargon bandwagon (e.g. blockchain) to solve non-existent problem. To name a few
- sah2ed 7y ago
  > Implementing features based on feedback from 1 customer, then find out the customer wasn't articulating the problem at all. What about, ahem, Google Self-Driving Cars :)? Unpopular opinion around here but here goes: I feel the dimensions on which actual people (i.e. customers) will evaluate Google's SDCs, when they become generally available, is very different from the dimensions Google is optimizing for, based on what they think people will need in the future once the technology is ready§. How a person determines the utility of a product or service can be markedly different from how the same person evaluates the utility of that product or service when s/he is confronted with what all potential customers must confront before making a purchase decision: a price tag. As subtle as the distinction between a person and a customer is, it is an important dose of reality that I think is missing from a lot of arguments that happen here on HN where the title of market leader is undisputedly ceded to Google Waymo when compared to a competitor like Tesla with far far lower-tech (but cheaper) autonomous capabilities. § IMHO, I don’t think their current approach to SDC technology using expensive LIDARs fits the problem at hand. Use of high fidelity tech like LIDAR also causes another tendency, it lures engineers into thinking that it will somehow make tractable, a hard problem like the trolley problem [0]. An additional issue is that the designations: L0-L5 are arbitrary constraints themselves, they are not based on problems customers are confronted with. 0: https://en.wikipedia.org/wiki/Trolley_problem https://en.wikipedia.org/wiki/Trolley_problem
fdsaasdf_999 7y ago
> 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. And that is the wrong problem that too many software engineering teams solve. Let's not solve a customer problem, let's solve the problem of solving customer problems and hopefully in year or so we'll get to that. Iteration speed is an issue for hardware. It becomes an issue for software teams when too much time is spent tooling, generalizing and reinventing wheels. I point that out because this sort of example pushes the wrong buttons for many software engineers, including myself. We don't need more time spent on meta-problem solving. Much less, in fact.
- ukj 7y ago
  That depends on whether you see technical debt accrual as a 'meta problem'. The faster you iterate without thinking long-term - the faster it accrues. 20/20 hindsight and all that.
  - thinkingkong 7y ago
    Its only debt if it sticks around long enough to need to be dealt with.
    - ukj 7y ago
      Short-term thinking is a form of technical debt. How important of a problem are you really solving if the solution is not meant to "stick around"? https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference
  - swatcoder 7y ago
    Technical debt is not any sort of problem in and of itself. It can be accrued naively, which is an antipattern, but when that isn’t the case technical debt is a vehicle for leverage. You get more value from less work. With all development efforts having a finite lifetime, and many having a particularly short one, wise exercise of technical debt becomes an essential skill for both project managers and developers. Vilifying technical debt, and even prematurely mitigating it, are just as naive as inadvertently introducing it.
uuilly 7y ago
I haven’t read your link bc your title is incredibly presumptuous. You don’t know who I am or what problem I’m solving.
- dang 7y ago
  Yes, linkbait 'you' is a perennial annoyance. At least this one has the good manners to leave a pretty nice title if we simply delete the offending pronoun.
dpc_pw 7y ago
https://dpc.pw/iteration-time-trumps-everything https://dpc.pw/iteration-time-trumps-everything
kthejoker2 7y ago
A favorite quote: > Far better an approximate answer to the right question, which is often vague, than an exact answer to the wrong question, which can always be made precise. John Tukey
- otoburb 7y ago
  Maynard Keyes might have been a Carveth Read fan: "It is better to be vaguely right, than precisely wrong." - Carveth Read, "Logic: Deductive & Inductive" 1898 (1920 4th Ed.) [1] http://www.gutenberg.org/files/18440/18440-h/18440-h.htm#Page_351 http://www.gutenberg.org/files/18440/18440-h/18440-h.htm#Pag...
dang 7y ago
A bit in 2016: https://news.ycombinator.com/item?id=10830690 https://news.ycombinator.com/item?id=10830690 A bit more in 2014: https://news.ycombinator.com/item?id=8524988 https://news.ycombinator.com/item?id=8524988 Quite a bit in 2012: https://news.ycombinator.com/item?id=3561397 https://news.ycombinator.com/item?id=3561397 Discussed at the time: https://news.ycombinator.com/item?id=2591367 https://news.ycombinator.com/item?id=2591367
boyadjian 7y ago
Solving the wrong problem is a very common thing in software development. That is why I always take time to think (sometimes during three days) before starting a development.
- trhway 7y ago
  >Solving the wrong problem is a very common thing in software development. there aren't much right problems in software development to go around, while there are so many people and money that can and have to be put to work, and as result we live in a kind of a golden age where instead of subsistence and survival of a typical stressed&oppressed office drone most of the people in the industry are in a position to work on wrong problems, and to try and to develop more and more of new tech, and the high failure rate of the projects isn't an issue. Which other engineering discipline can allow itself to have such a luxury?
joe_the_user 7y ago
I think the "Richard Feynman" algorithm is figuring out a way to get to the desired result for a specific challenge without having to past through all steps needed to solve the general problem. The example of Feynman cracking safes is perfect - he just used a bunch of special tricks rather than any general method - similarly with quick numeric calculations in his head.[1] That said, while most hard problems need to framed in a different way not all hard problems yield to the "clever detour into something simple" approach. A lot of math problems are solved by a detour into a bunch, difficult things and then a return to your original "seemingly simple" problem (see Fermat's Last Theorem etc). [1] See: Surely You're Joking Mr. Feynman https://en.wikipedia.org/wiki/Surely_You're_Joking%2C_Mr._Feynman https://en.wikipedia.org/wiki/Surely_You're_Joking%2C_Mr._Fe...!
mannykannot 7y ago
This was not the only problem-framing aspect of MacCready's success: while previous attempts built complex airframes intended to have a low drag coefficient, he recognized that the issue was power dissipation - if the speed was low enough, the drag coefficient was not so critical, and things like wire bracing were acceptable. His initial insight was that "if you triple the size of a hang-glider-size plane and triple its wingspan to 90 ft. while keeping its weight the same, the power needed to fly it goes down by a factor of 3, to about 0.4 horsepower." And that, he knew, was what a trained cyclist could pump out for several minutes at a stretch. http://content.time.com/time/magazine/article/0,9171,90512,00.html http://content.time.com/time/magazine/article/0,9171,90512,0...
- collyw 7y ago
  Did he find that out before or after the fast iteration conclusion?
  - mannykannot 7y ago
    I am not privy to Dr. MacCready's thoughts, but I think it is worth considering how the two inspirations differ. Anyone who has worked on developing something novel has probably realized that there are benefits in fast iteration, and I would guess that the other plane-builders realized how time-consuming their approach was, but could not see a way to achieve fast iteration, because they were locked into a particular notion of what the solution would require. MacCready's engineering insight, on the other hand, arose from an understanding of the practical implications of aerodynamics so thorough that it was almost instinctive (the same could be said for his invention of the glider speed ring; it is not that he knew something others did not, but he saw how that knowledge could be put to use. Also, in both cases, there's some significant engineering to be done between the idea and the implementation.) This aerodynamic insight happened to open the door to fast iteration, but, perhaps more importantly, it showed what sort of airplane to build (in fact, the latter was the key to the former, as well as the key to actually achieving the goal.) It is all very well to say that we're going to solve a problem through fast iteration, but that does not tell you what to do next. On the other hand, I imagine that as soon as Dr. MacCready had his aerodynamic insight, his mind was filled with ideas about how to go about it.
foobar1962 7y ago
> MacCready, decided to get involved. He looked at the problem, how the existing solutions failed, and how people iterated their airplanes. He came to the startling realization that people were solving the wrong problem. Being able to analyse existing solutions and previous attempts (successful or not) is a luxury that the first people to attempt a solution don't enjoy. It's much, much easier taking an existing solution and improving it than it is to develop the existing solution.
- simonh 7y ago
  The Everyday Astronaut had a great interview with Elon Musk after the Starship presentation a few days ago. They spent a bit of time talking about how much progress the team had made in very little time, and Musk's take was that it took them an awful long time to finally ask the right questions - years. Once they had formulated exactly what they were trying to do and what the actual relevant constraints were, finding the right solutions and making very rapid progress was actually not all that complicated. He talked about the tendency really good engineers have to spend a lot of effort optimising the design of things that shouldn't be there at all. Finally he banged on hard about always questioning your design constraints. He pointed out that if you get given some design constraints by another team, you should always consider their validity since it;s very unlikely they are optimal. The converse assumption would be that they are always perfect, so looking at it that way there's no reason you should assume they are right from the start. For anyone who worries about the sunk cost fallacy, bear in mind it was only about a year ago they decided to throw away all the investment they'd put into building a composite body, including a huge main body tool. https://www.youtube.com/watch?v=cIQ36Kt7UVg https://www.youtube.com/watch?v=cIQ36Kt7UVg
  - martyvis 7y ago
    I came here to write this same comment as well. I think Elon has great insight how to very quickly build from conception to reality, pruning off undesirable paths before they consume resources. In that one interview with Tim, he explored very deep concepts about cross team collaboration, engineering process and project management that extend well beyond the rocket science I was expecting to hear about
anotheryou 7y ago
Nitpicking: the image of the guy is labled wrong. He's not holding a speed ring, but a crossection of a wing spar https://en.wikipedia.org/wiki/Paul_MacCready#/media/File:Paul_maccready.jpg https://en.wikipedia.org/wiki/Paul_MacCready#/media/File:Pau...
mchan 7y ago
"A $500 a week cocaine habit is not a money problem" - a favourite quote I heard from somewhere, which I unfortunately cannot credit
mjcohen 7y ago
Reminds me of something I read many years ago: There are two ways of doing a Ph.D. thesis: (1) Finding a problem and solving it; (2) finding a method and then finding a problem it solves. The second is much more likely to be successful.
- collyw 7y ago
  Isn't a startup closer to the former. Potential customers have a problem and you can try to solve it.

142 points by dedalus 7y ago

muglug 7y ago

Needs a (2011) tag

dang 7y ago
Added now. Thanks!

personjerry 7y ago

Similarly, startups are in the business of iteratively failing and learning about their problem. By reframing the problem, he effectively "startupify'd" the problem.

a_c 7y ago

Identifying the right problem is indeed the golden nugget. Teams chasing after arbitrarily defined KPI, with no feedback loop in place, or the feedback is 1 year later. Implementing features based on feedback from 1 customer, then find out the customer wasn't articulating the problem at all. Projects eager to adopt the latest technology, using every bit of service AWS provide, jumping onto the jargon bandwagon (e.g. blockchain) to solve non-existent problem. To name a few

sah2ed 7y ago
> Implementing features based on feedback from 1 customer, then find out the customer wasn't articulating the problem at all. What about, ahem, Google Self-Driving Cars :)? Unpopular opinion around here but here goes: I feel the dimensions on which actual people (i.e. customers) will evaluate Google's SDCs, when they become generally available, is very different from the dimensions Google is optimizing for, based on what they think people will need in the future once the technology is ready§. How a person determines the utility of a product or service can be markedly different from how the same person evaluates the utility of that product or service when s/he is confronted with what all potential customers must confront before making a purchase decision: a price tag. As subtle as the distinction between a person and a customer is, it is an important dose of reality that I think is missing from a lot of arguments that happen here on HN where the title of market leader is undisputedly ceded to Google Waymo when compared to a competitor like Tesla with far far lower-tech (but cheaper) autonomous capabilities. § IMHO, I don’t think their current approach to SDC technology using expensive LIDARs fits the problem at hand. Use of high fidelity tech like LIDAR also causes another tendency, it lures engineers into thinking that it will somehow make tractable, a hard problem like the trolley problem [0]. An additional issue is that the designations: L0-L5 are arbitrary constraints themselves, they are not based on problems customers are confronted with. 0: https://en.wikipedia.org/wiki/Trolley_problem https://en.wikipedia.org/wiki/Trolley_problem

fdsaasdf_999 7y ago

> 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. And that is the wrong problem that too many software engineering teams solve. Let's not solve a customer problem, let's solve the problem of solving customer problems and hopefully in year or so we'll get to that. Iteration speed is an issue for hardware. It becomes an issue for software teams when too much time is spent tooling, generalizing and reinventing wheels. I point that out because this sort of example pushes the wrong buttons for many software engineers, including myself. We don't need more time spent on meta-problem solving. Much less, in fact.

ukj 7y ago
That depends on whether you see technical debt accrual as a 'meta problem'. The faster you iterate without thinking long-term - the faster it accrues. 20/20 hindsight and all that.
- thinkingkong 7y ago
  Its only debt if it sticks around long enough to need to be dealt with.
  - ukj 7y ago
    Short-term thinking is a form of technical debt. How important of a problem are you really solving if the solution is not meant to "stick around"? https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference
- swatcoder 7y ago
  Technical debt is not any sort of problem in and of itself. It can be accrued naively, which is an antipattern, but when that isn’t the case technical debt is a vehicle for leverage. You get more value from less work. With all development efforts having a finite lifetime, and many having a particularly short one, wise exercise of technical debt becomes an essential skill for both project managers and developers. Vilifying technical debt, and even prematurely mitigating it, are just as naive as inadvertently introducing it.

uuilly 7y ago

I haven’t read your link bc your title is incredibly presumptuous. You don’t know who I am or what problem I’m solving.

dang 7y ago
Yes, linkbait 'you' is a perennial annoyance. At least this one has the good manners to leave a pretty nice title if we simply delete the offending pronoun.

dpc_pw 7y ago

https://dpc.pw/iteration-time-trumps-everything https://dpc.pw/iteration-time-trumps-everything

kthejoker2 7y ago

A favorite quote: > Far better an approximate answer to the right question, which is often vague, than an exact answer to the wrong question, which can always be made precise. John Tukey

otoburb 7y ago
Maynard Keyes might have been a Carveth Read fan: "It is better to be vaguely right, than precisely wrong." - Carveth Read, "Logic: Deductive & Inductive" 1898 (1920 4th Ed.) [1] http://www.gutenberg.org/files/18440/18440-h/18440-h.htm#Page_351 http://www.gutenberg.org/files/18440/18440-h/18440-h.htm#Pag...

dang 7y ago

A bit in 2016: https://news.ycombinator.com/item?id=10830690 https://news.ycombinator.com/item?id=10830690 A bit more in 2014: https://news.ycombinator.com/item?id=8524988 https://news.ycombinator.com/item?id=8524988 Quite a bit in 2012: https://news.ycombinator.com/item?id=3561397 https://news.ycombinator.com/item?id=3561397 Discussed at the time: https://news.ycombinator.com/item?id=2591367 https://news.ycombinator.com/item?id=2591367

boyadjian 7y ago

Solving the wrong problem is a very common thing in software development. That is why I always take time to think (sometimes during three days) before starting a development.

trhway 7y ago
>Solving the wrong problem is a very common thing in software development. there aren't much right problems in software development to go around, while there are so many people and money that can and have to be put to work, and as result we live in a kind of a golden age where instead of subsistence and survival of a typical stressed&oppressed office drone most of the people in the industry are in a position to work on wrong problems, and to try and to develop more and more of new tech, and the high failure rate of the projects isn't an issue. Which other engineering discipline can allow itself to have such a luxury?

joe_the_user 7y ago

I think the "Richard Feynman" algorithm is figuring out a way to get to the desired result for a specific challenge without having to past through all steps needed to solve the general problem. The example of Feynman cracking safes is perfect - he just used a bunch of special tricks rather than any general method - similarly with quick numeric calculations in his head.[1] That said, while most hard problems need to framed in a different way not all hard problems yield to the "clever detour into something simple" approach. A lot of math problems are solved by a detour into a bunch, difficult things and then a return to your original "seemingly simple" problem (see Fermat's Last Theorem etc). [1] See: Surely You're Joking Mr. Feynman https://en.wikipedia.org/wiki/Surely_You're_Joking%2C_Mr._Feynman https://en.wikipedia.org/wiki/Surely_You're_Joking%2C_Mr._Fe...!

mannykannot 7y ago

This was not the only problem-framing aspect of MacCready's success: while previous attempts built complex airframes intended to have a low drag coefficient, he recognized that the issue was power dissipation - if the speed was low enough, the drag coefficient was not so critical, and things like wire bracing were acceptable. His initial insight was that "if you triple the size of a hang-glider-size plane and triple its wingspan to 90 ft. while keeping its weight the same, the power needed to fly it goes down by a factor of 3, to about 0.4 horsepower." And that, he knew, was what a trained cyclist could pump out for several minutes at a stretch. http://content.time.com/time/magazine/article/0,9171,90512,00.html http://content.time.com/time/magazine/article/0,9171,90512,0...

collyw 7y ago
Did he find that out before or after the fast iteration conclusion?
- mannykannot 7y ago
  I am not privy to Dr. MacCready's thoughts, but I think it is worth considering how the two inspirations differ. Anyone who has worked on developing something novel has probably realized that there are benefits in fast iteration, and I would guess that the other plane-builders realized how time-consuming their approach was, but could not see a way to achieve fast iteration, because they were locked into a particular notion of what the solution would require. MacCready's engineering insight, on the other hand, arose from an understanding of the practical implications of aerodynamics so thorough that it was almost instinctive (the same could be said for his invention of the glider speed ring; it is not that he knew something others did not, but he saw how that knowledge could be put to use. Also, in both cases, there's some significant engineering to be done between the idea and the implementation.) This aerodynamic insight happened to open the door to fast iteration, but, perhaps more importantly, it showed what sort of airplane to build (in fact, the latter was the key to the former, as well as the key to actually achieving the goal.) It is all very well to say that we're going to solve a problem through fast iteration, but that does not tell you what to do next. On the other hand, I imagine that as soon as Dr. MacCready had his aerodynamic insight, his mind was filled with ideas about how to go about it.

foobar1962 7y ago

> MacCready, decided to get involved. He looked at the problem, how the existing solutions failed, and how people iterated their airplanes. He came to the startling realization that people were solving the wrong problem. Being able to analyse existing solutions and previous attempts (successful or not) is a luxury that the first people to attempt a solution don't enjoy. It's much, much easier taking an existing solution and improving it than it is to develop the existing solution.

simonh 7y ago
The Everyday Astronaut had a great interview with Elon Musk after the Starship presentation a few days ago. They spent a bit of time talking about how much progress the team had made in very little time, and Musk's take was that it took them an awful long time to finally ask the right questions - years. Once they had formulated exactly what they were trying to do and what the actual relevant constraints were, finding the right solutions and making very rapid progress was actually not all that complicated. He talked about the tendency really good engineers have to spend a lot of effort optimising the design of things that shouldn't be there at all. Finally he banged on hard about always questioning your design constraints. He pointed out that if you get given some design constraints by another team, you should always consider their validity since it;s very unlikely they are optimal. The converse assumption would be that they are always perfect, so looking at it that way there's no reason you should assume they are right from the start. For anyone who worries about the sunk cost fallacy, bear in mind it was only about a year ago they decided to throw away all the investment they'd put into building a composite body, including a huge main body tool. https://www.youtube.com/watch?v=cIQ36Kt7UVg https://www.youtube.com/watch?v=cIQ36Kt7UVg
- martyvis 7y ago
  I came here to write this same comment as well. I think Elon has great insight how to very quickly build from conception to reality, pruning off undesirable paths before they consume resources. In that one interview with Tim, he explored very deep concepts about cross team collaboration, engineering process and project management that extend well beyond the rocket science I was expecting to hear about

anotheryou 7y ago

Nitpicking: the image of the guy is labled wrong. He's not holding a speed ring, but a crossection of a wing spar https://en.wikipedia.org/wiki/Paul_MacCready#/media/File:Paul_maccready.jpg https://en.wikipedia.org/wiki/Paul_MacCready#/media/File:Pau...

mchan 7y ago

"A $500 a week cocaine habit is not a money problem" - a favourite quote I heard from somewhere, which I unfortunately cannot credit

mjcohen 7y ago

Reminds me of something I read many years ago: There are two ways of doing a Ph.D. thesis: (1) Finding a problem and solving it; (2) finding a method and then finding a problem it solves. The second is much more likely to be successful.

collyw 7y ago
Isn't a startup closer to the former. Potential customers have a problem and you can try to solve it.