[erlang-questions] Erlang Intro/Evangelism Presentation -- Starbucks!

[Michael Turner]

"... I started to think about how Starbucks processes drink orders.
Starbucks, like most other businesses is primarily interested in maximizing
throughput of orders. More orders equals more revenue. As a result they use
asynchronous processing ..."

Starbucks might actually be an interesting metaphor here, instructive for
thinking about how to write Erlang apps, but I beg to differ about what's
being optimized.

Starbucks is NOT optimizing throughput.  It's optimizing replicability.

I must explain: I come from Berkeley, a town that lives on espresso.  At
certain cafes, I could routinely see two people behind the counter
delivering twice as much espresso per minute as Starbucks does with five or
six people behind the counter.

What Starbucks is optimizing is how to rapidly deploy relatively slow,
lower-skill employees to provide a consistent experience of a relatively
even flow of order processing, a sense (for the customer) that inexorable
progress is being made.  So long as this continues to attract a flow of
customers who've never known better, it will work.  And I have to admit,
I've gotten used to finally getting to the Starbucks counter, ordering a
capuccino, and having two other employees echo my order, even though it's
rarely under three minutes before I actually get the drink.  But at first I
couldn't stand it. In some of the cafes I got used to in Berkeley, someone
at the counter would often be taking my order before I even got to the cash
register, and putting the drink in front of me by the time I had my wallet
out to pay the cashier.  THAT was some real throughput.  Not to mention that
watching these people furiously take orders, crank out drinks and collect
money was like being at a martial arts performance.

Sometimes the way to speed something up is to parallelize it.  Sometimes the
way to speed it up is with a fast uni-processor running highly optimized
procedures.  But sometimes what you're trying to optimize isn't speed of
operations, really, but growth.  Starbucks was in fact doing that last.
 It's optimizing for blanketing cityscapes with its storefronts, as it has
in Tokyo.  Optimizing throughput -- which requires optimizing employees --
would only have slowed that growth process. Those cafes in Berkeley I
worshipped for their ferociously pirouetting baristas were wonderful, but
they would never scale.  Starbucks scaled.  A good process structure in
Erlang also scales.  That's the real lesson in any such analogy, I think.

-michael turner



On Fri, Dec 17, 2010 at 9:48 PM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

> MESSAGE-PASSING @ STARBUCKS
>
> "... I started to think about how Starbucks processes drink orders.
> Starbucks, like most other businesses is primarily interested in maximizing
> throughput of orders. More orders equals more revenue. As a result they use
> asynchronous processing ..."
>
> "... we can see that the real world is often asynchronous. Our daily lives
> consists of many coordinated, but asynchronous interactions... asynchronous
> messaging architecture can often be a natural way to model these types of
> interactions... also means that often we can look at daily life to help
> design successful messaging solutions ..."*
>
> http://www.eaipatterns.com/ramblings/18_starbucks.html
>
> I hope I'm not too late with this, but I really liked this old article by
> Google's Gregor Hohpe on asynchronous message passing. He wasn't talking
> explicitly about Erlang but the content should resonate instantaneously with
> Erlang programmers while at the same time being insightful for
> non-Erlangers. You might want to reference a few of his well-worded
> analogies for evangelising some of the core ideas built into Erlang.
>
> *Joe Armstrong made a similar compelling argument at the beginning of his
> book. As a relatively new Erlang programmer myself, _THIS_ is the main line
> of argument that convinced me to try out the Erlang environment.
> Particularly the implications on concurrency which I had struggled with in
> other environments (in retrospect, it was because those environments didn't
> have these ideas built-in or actively encouraged -- I've found Erlang does a
> lot of hand-holding to make sure you do the sane thing in order to avoid
> painting yourself into a corner -- something you could emphasise in your
> presentation.)
>
> - Edmond -
>
>
> On Sat, 04 Dec 2010 05:43:34 +1100, Ryan Zezeski <rzezeski@REDACTED>
> wrote:
>
>  I've been tasked with giving an introductory level presentation on Erlang
>> at
>> work.  The focus is on why you would use Erlang and what does it look like
>> on the surface level.  We have a lot of your standard Java/C#/C developers
>> and this will act as a potential launching pad to introducing Erlang to
>> the
>> company.  There is the potential for a large number of people to video
>> conference into this possibly spanning several countries so I really want
>> to
>> knock this out of the park.
>>
>> I'm writing as an inquiry for links to any prior art that I may use for
>> inspiration or even steal and use as my own.  Anything that you think
>> might
>> be helpful is appreciated, even input on possible approaches.  I'd really
>> like to hear from people who have done this sort of thing before, i.e.
>> pubic
>> speaking on Erlang.
>>
>> Thanks,
>> -Ryan
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>