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

And Furthermore, Comma

One of the problems I have in looking for technology jobs is that I don’t actually care for or about technology in any traditional sense. I might not be a fan of a particular platform (or, well, several) but I also don’t go evangelizing for the platforms I develop with the most (use Perl;).  I’m also perfectly happy to drop skills and let them bounce around on the floor when they’re no longer useful to me (e.g. just about anything to do with Windows), knowing that if I have to deal with them I can just go pick them right up again.

My motto for jobs has long been, “anything you can fake for two weeks you can do professionally.” With a lot of this stuff I’ve had so much exposure to it that even if it’s not something I’ve recently been paid to do, I know enough of the fundamentals that I can pick up the details pretty quickly. I might be a bit too honest about this, actually, since if people are looking for somebody with experience with, say, Solaris, I’ll mention that my experience dates back to the Solaris 7/8 days and that as a Linux user I’ll find myself trying to remember command line options for non-GNU tools.  But I did build Solaris machines, and I compiled GCC on them because the standard compiler sucked, and and and. I did all that crap before, and I could do it again if I had to.  But I’m also not going to lie to somebody and say that I’ve run Solaris 10 or Windows Advanced Server 2008 or whatever, because I’d be caught in that lie. I can pick up the skills again pretty quickly, and I’m happier telling the truth and relying on my ability to learn or relearn on the fly.

But when you’ve been doing this for long enough — especially if you actually think about the work you’re doing — you become less mired in the technology and more interested in the problem and the technique of solving it. Except for the issues I’d have getting back up to speed on Java, if somebody desperately wanted to pay me to write in it I’d sit down with a decent book and IDE and get over it.  I’m more interested in delving into the business issue that has presented the software problem, so that the solution actually aids or fixes the business process. This is less about code than it is about understanding the real problem, and this is a hard skill to get across in an interview.

So what happens is that I’ll get into an interview and they’ll start trying to nail me down on specific buzzwords, and all I can do at that point is push back.  I’ve forgotten more skills than the average new hire has learned in the first place, because I’ve learned to optimize my memory for the tasks at hand.  I know that for certain tasks I’m going to be getting out an O’Reilly or The Book of Postfix or trolling the web for compiler options, because it doesn’t pay to commit that stuff to long-term memory. Maybe that places me behind the single-task guy who commits it all to memory, but I like to think it makes me a more rounded candidate and employee.

But I also often get a repeated question along the line of, “but what do you do?” Some recruiters and hiring managers can’t make sense of a resume that illustrates a willingness to forget how to do something. That’s not familiar to people, even though I’ve found it to be common among experienced programmers. If a skill isn’t immediately useful, keeping it on the stack doesn’t make much sense. To use a software analogy, a skill is like a module: load it in, use it, and let the garbage collector get rid of it when it’s not being used anymore.

What do I do? I use technology to solve problems. What technology? Well, that depends on the problem. What do I prefer? Whatever works under the given constraints. Is this too slippery an answer? It’s the truth. That’s the best answer I can give.