13 ms·

> I have always started on the solution to an ambitious problem by asking "what would have to be true for this to be solvable?" and from each of those things wo

by npalli 11y ago

> I have always started on the solution to an ambitious problem by asking "what would have to be true for this to be solvable?" and from each of those things working backward until you get to things Can you give an example of an ambitious problem you solved backward this way.

hderms 11y ago
You could see a (perhaps incorrect or ultimately misleading) example of it: 1. What would have to be true for us to have reliable transmission of messages over an inherently lossy network? 1a. some kind of method to ensure that a message got to its intended destination 2. what would have to be true to ensure that a message got to its intended destination? 2a. some kind of method of ensuring that failures don't occur, or if that is impossible, some kind of method of making intermittent failures not prevent the system from eventually functioning. 3. what would need to be true to make intermittent failures not prevent the system from functioning ... etc... Slightly misleading because I'm obviously working back from a familiar example, but I think the technique is applicable in some cases. At the very least your solution is born out of trying to make the impossible just barely possible rather than seeking to build layer by layer to achieve something possible. However, with TCP/IP you can also see how using traditional methods also work.
ChuckMcM 11y ago
Perhaps one of the more practical uses was figuring out how to scale storage performance when I was at NetApp. Since processors had stopped scaling like they had been in 2001 their CTO challenged me to scale storage performance in terms of IOs per second and total available capacity, without improving the speed of the processors. The challenge there ended up localized around a couple of really hard sub-problems. One was that Netapp's storage model was file based (rather than block based) and so part of the problem was scaling the operation of a file state machine, and the other serious sub-problem was the creating a reliable way to keeping protocol/process state that was in "flight" in order to recover from failures. Working backwards led to what I ended up calling the "three layer cake" model which split the storage stack into parts that were loosely coherent and tightly coherent.

by npalli 11y ago

hderms 11y ago

You could see a (perhaps incorrect or ultimately misleading) example of it: 1. What would have to be true for us to have reliable transmission of messages over an inherently lossy network? 1a. some kind of method to ensure that a message got to its intended destination 2. what would have to be true to ensure that a message got to its intended destination? 2a. some kind of method of ensuring that failures don't occur, or if that is impossible, some kind of method of making intermittent failures not prevent the system from eventually functioning. 3. what would need to be true to make intermittent failures not prevent the system from functioning ... etc... Slightly misleading because I'm obviously working back from a familiar example, but I think the technique is applicable in some cases. At the very least your solution is born out of trying to make the impossible just barely possible rather than seeking to build layer by layer to achieve something possible. However, with TCP/IP you can also see how using traditional methods also work.

ChuckMcM 11y ago

Perhaps one of the more practical uses was figuring out how to scale storage performance when I was at NetApp. Since processors had stopped scaling like they had been in 2001 their CTO challenged me to scale storage performance in terms of IOs per second and total available capacity, without improving the speed of the processors. The challenge there ended up localized around a couple of really hard sub-problems. One was that Netapp's storage model was file based (rather than block based) and so part of the problem was scaling the operation of a file state machine, and the other serious sub-problem was the creating a reliable way to keeping protocol/process state that was in "flight" in order to recover from failures. Working backwards led to what I ended up calling the "three layer cake" model which split the storage stack into parts that were loosely coherent and tightly coherent.