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

[Edmond Begumisa]

On Sat, 08 Jan 2011 00:42:54 +1100, Michael Turner  
<michael.eugene.turner@REDACTED> wrote:

> "... 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.

Food for thought: What do you do when your highly optimised procedures  
have to run on slower sequential processors? (i.e when your program has to  
run on newer hardware)

If your procedures are already optimised to death, your only option is to  
_try_ and parellise. I think that's what's getting peoples knickers in  
knots regarding multi-core.

> 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.
>

Interesting observation -- I hadn't thought of the replication angle or  
process structure.

In terms of "Optimizing throughput": I think the point of the article  
though was to illustrate an alternative to two-phase commit. Specifically,  
the use of async message-passing techniques to avoid blocking transactions  
improving throughput in the process. I think async message-passing +  
non-blocking operations and the impact this has on responsiveness is an  
important lesson for Erlang newcomers and/or can be used as a "pitch" to  
sell the environment to those thinking about dipping their feet and  
needing a reason to jump in. Well, at least it was for me :)

- Edmond -

> -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
>>
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/