fedward, tumbling

How Being Stateful Would Improve Starbucks

As a followup to the REST rant the other day, here’s a digression that occurred to me:

Imagine that instead of buying a Coke at 7-Eleven (simple object acquisition with no preparation required), picture buying a coffee at Starbucks.

Now, I don’t actually hate Starbucks qua Starbucks, but I do hate two things about Starbucks.  One of them is the coffee itself (over-roasted, excessively astringent), and the other is the order delivery process.  (If you’re asking what that leaves, it leaves the ubiquity — bully for them! — and the cafe environment outside all the shouting, which generally involves non-awful music, comfortable chairs, and available power and wifi, all good things in my book).

There’s an interesting article about Starbucks that says their process is actually a good thing.  The experience described in that article, however, is not the experience I have on those occasions when Starbucks is my only option.  The article refers specifically to a correlation identifier.  In my (admittedly small) sample of Starbucks experiences, the number of times my name has been written on my cup (or even asked for) is exactly zero.  Without any correlation identifier, how do customers know whose (ugh) Venti® nonfat latte is whose?

In software terms, what Starbucks is doing is really just a half-assed version of asynchronous processing.  When you do this in software, you (the client) register a callback.  A software callback is the equivalent of giving the barista not your name, but your phone number.  Many restaurants have those pagers for tables, which are essentially the same thing — when you register your callback, you’re given a handle, which is unique to you.  You get the actual call (or the pager vibrates) when your coffee (or table) is ready.

The brute force software alternative to this is scheduled polling.  You’ve probably had this experience at a poorly run Starbucks, actually, when the shouty person is inadequately shouty, and you have to keep returning to the counter to find out if your drink is done yet.  The canonical example of polling in real life is “are we there yet?”  But I digress even more.

The Starbucks problem is that they don’t have a proper callback, they just shout “Venti® nonfat latte!”  In practice there’s no queue management.  Everybody who ordered a Venti® nonfat latte (and I’ve never seen the number be less than two) has to figure out who’s where in the queue, with somebody invariably feeling like they’ve gotten their drink stolen.  I’m not sure there even is a term for what sort of queue “management” that is.  It’s just a mess.

But (and this is where this ties in to the previous rant) not only is the Starbucks model a callback done wrong, it’s a broken hybrid of REST and stateful services.  They treat the part where they take your money like a REST transaction, queue the process of making your beverage, and then forget who you are.  In a true stateful model, each cup would have a serial number (not a name), and they’d have to record the completion of the process to get the name that associates with that serial number.  That way they’d have not only a 1:1 correlation of processes to customers, they’d actually know how long each process took in the real world and be able to see where processes could be improved and beverages could be repriced or eliminated from the menu based on actual data.

They could do this without writing anything or wasting paper, too.  They could just have a hundred plastic coasters (forty would probably do it, actually) with numbers on them, so that a number (handle) could be reused endlessly.  Put a cup on the numbered coaster and put the number into the POS terminal, along with the customer’s name (or hand the customer a pager tied to that same number).  When the order is done, the shouty person keys the number in, the system records completion, and the shouty person can then thank the customer by name.  Add the pager and they don’t even have to shout, making the environment for everybody else that much more pleasant.

Then they just have to start making better coffee.

Do You Have the Time?

When you’re a developer you read a lot of documentation.  When you’re a technical point person for an organization, you read a lot of proposals. When you’re looking for work you read a lot of job listings.  What this means for me is that I see a lot of buzzwords, and they drive me crazy (hint: there is no one Software Development Life Cycle, so referring to it with the definite article is a great way to indicate that you don’t know what on earth you’re talking about).  I have many such complaints.  Today’s is the description of a web application as being RESTful.

And now if you’re not a programmer, you probably are going to ask, “What’s restful about the web?  Why is the REST part in all caps?”  So I will now rewind.

REST is a design model for applications, generally (but not necessarily) on the web.  It stands for REpresentational State Transfer.  Here’s a real life example of a RESTful exchange:

“Do you have the time?”

“It’s 10:44 AM.”

In REST architectures, you (the client) ask for the state of something (a bit of data, the answer to a question), and the server answers you.  Its answer is the representation of the current state of things.  There is no implication that the information you have been given will stay true, but at the moment you ask the question (plus the amount of time it takes the server to process it) the answer is guaranteed to be true.  If you ask again:

“Do you have the time?”

“It’s 10:44 AM.”

You might get the same answer again, depending on how quickly you ask.  But you might not:

“Do you have the time?”

“It’s 10:45 AM.”

REST as a design model is two things: (1) completely obvious, and (2) somewhat revelatory in the software world.

Wait.  Asking and answering is revelatory?

Uh huh.  Before somebody actually described REST, the general assumption in client-server interactions was that the server would keep track of YOUR state, not just its own.  Let’s expand our real-world interaction:

“Do you have the time?”

“Yes, sir, it’s 10:54 AM.  Sorry about the wait; I’ll bring you a fresh cup of coffee and check with the kitchen.”

So part of that interaction is just a standard representational state transfer, but the other part demonstrates that the server is aware of your state (hungry, impatient, undercaffeinated) too.  In software terms, this would be considered stateful.  Until somewhat recently, this was the norm.  It was assumed that the server needed to know the state of every client, because the client wouldn’t be keeping track.  The client in this case placed an order for something (say, coffee and a cheese danish, warmed up), and the server’s job was not only to serve up the request but to keep track of it for as long as the transaction took to complete.

In software terms, though, this assumption doesn’t need to be true.  A lot of software is designed around the assumption that the server should keep track of things that, really, it needn’t bother.  The server doesn’t need to remember that it told the client what time it was, because that information is expected to change.  If the client asks for something that requires no preparation, the server can just hand it off and be done, with the client, the transaction, everything.  Somebody• finally sat down and said, “you know, this is actually a practical way of doing things, and not just a lazy one.”  And then other people who had already been doing things that way saw that there was now a name for the thing they’d been doing all along (because it made sense), and it became a buzzword.

• The somebody in question was an author of the HTTP specification and is generally a Very Smart Guy. REST was documented in his doctoral dissertation. 

Here’s the thing, though: most of what happens on the web is RESTful, whether somebody thought to attach the buzzword to it or not.  The things that maintain state are the outliers.  Amazon remembers what you’ve bought, but 7-Eleven doesn’t know who you are when you pay cash for a 20-ounce Coke.  They probably don’t even know who you are if you use a debit card to buy that Coke, because they only hold onto that information for long enough to process the transaction.  You can keep returning to 7-Eleven for more Cokes, and the transaction will always be a RESTful one, even though the actual shopping experience at 7-Eleven isn’t particularly relaxing.  But that doesn’t stop people from describing their applications as RESTful.

Again:  REST means that the client asks for something, the server hands it over, and that’s it.  If the client wants something else, that’s a whole new interaction.

But since most of the interactions on the web are RESTful by definition, saying that your web application is RESTful is like saying that dinner is SATISFYing (Scheduled, Aromatic, Tasty Intake of Sustaining Food, Yum: backronym subject to change by the time my doctoral dissertation is published).  You’ve written a web app.  Of COURSE it’s RESTful. Tell me something I don’t already know. Tell me when it’s something else. If you insist on telling me it’s RESTful, I’m not going to hear anything else you say over the voice in my head shouting about how you’re an idiot spouting buzzwords without knowing what they mean.

And I will now leave you with a line from the Simpsons, in the Itchy & Scratchy (& Poochie) writers’ room: “Excuse me, but ‘proactive,’ and ‘paradigm?’ Aren’t those just buzzwords dumb people use to sound important? … I’m fired, aren’t I?”