
Parallelized Decision Making (2019) - yarapavan
https://arkwright.github.io/parallelized-decision-making.html
======
haggy
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
>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
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
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.

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

