3 ms·

Parallelized Decision Making (2019)

37 points by yarapavan 7y ago

haggy 7y ago
Going to play devil's advocate here. This is one of those "strategies" that looks great in retrospect but doing this up front will be nearly impossible within the confines of a non-fictional organization. This is so highly dependent on multiple critical factors such as resource availability (do you even have enough devs to allocate to this parallel strategy?) and business buy-in (good luck telling the business that you are going to divert all these tech resources in order to throw out all but one of these experiments many months from now). Unfortunately I can't even get companies I work at to agree to 20% time let alone telling them we can't make decisions so we're going to burn huge amounts of cash trying to reach one in parallel. Like the article said, people are much more cost averse. People includes leadership and product. Both of which will almost always decline this strategy.
- medlyyy 7y ago
  >Like the article said, people are much more cost averse. People includes leadership and product. Both of which will almost always decline this strategy. If you're saying this, then call it like it is: you're calling leadership and product stupid. Because unless you substantively disagree with the logic in the article, you're agreeing that the parallel experimentation strategy does all of: reach a solution faster, cost substantially less, and result in greater wealth generation later. Later here meaning only "within 5 years," so not even that much later. If you're a business, what else do you care about than wealth generation? I thought the article was very, very good.
  - haggy 7y ago
    The logic in this article is way too cut and dry in almost every way. For example the article exclaims that "parallel is always faster than serial". That assertion does not hold up in software engineering and it doesn't hold up with teams either.
Scene_Cast2 7y ago
Some counter points: I'm not sure that parallelizing the experiments would keep the same 4 month implementation time frame. It would also fragment the knowledge base, as fewer people would have been working on the one version that gets pushed. I also have my doubts about what happens when two of the experiments seem equally promising. Interesting idea nonetheless.
mrtweetyhack 7y ago
Author suggests to do all the experiments in parallel yet neglects to take in account limited resources
say_it_as_it_is 7y ago
GraphQL hype train stopped already. The only people who talk about it seem to be those trying to monetize it.

37 points by yarapavan 7y ago

Going to play devil's advocate here. This is one of those "strategies" that looks great in retrospect but doing this up front will be nearly impossible within the confines of a non-fictional organization. This is so highly dependent on multiple critical factors such as resource availability (do you even have enough devs to allocate to this parallel strategy?) and business buy-in (good luck telling the business that you are going to divert all these tech resources in order to throw out all but one of these experiments many months from now). Unfortunately I can't even get companies I work at to agree to 20% time let alone telling them we can't make decisions so we're going to burn huge amounts of cash trying to reach one in parallel. Like the article said, people are much more cost averse. People includes leadership and product. Both of which will almost always decline this strategy.

medlyyy 7y ago
>Like the article said, people are much more cost averse. People includes leadership and product. Both of which will almost always decline this strategy. If you're saying this, then call it like it is: you're calling leadership and product stupid. Because unless you substantively disagree with the logic in the article, you're agreeing that the parallel experimentation strategy does all of: reach a solution faster, cost substantially less, and result in greater wealth generation later. Later here meaning only "within 5 years," so not even that much later. If you're a business, what else do you care about than wealth generation? I thought the article was very, very good.
- haggy 7y ago
  The logic in this article is way too cut and dry in almost every way. For example the article exclaims that "parallel is always faster than serial". That assertion does not hold up in software engineering and it doesn't hold up with teams either.

Scene_Cast2 7y ago

Some counter points: I'm not sure that parallelizing the experiments would keep the same 4 month implementation time frame. It would also fragment the knowledge base, as fewer people would have been working on the one version that gets pushed. I also have my doubts about what happens when two of the experiments seem equally promising. Interesting idea nonetheless.

mrtweetyhack 7y ago

Author suggests to do all the experiments in parallel yet neglects to take in account limited resources

say_it_as_it_is 7y ago

GraphQL hype train stopped already. The only people who talk about it seem to be those trying to monetize it.