Saturday, January 24, 2009

Programmer's View of Self Checkout

Jeff Atwood has a blog post up comparing the open source software model with self-service check out lines at the supermarket.

But as a developer, that is not what I think about when I use the self-service lines (which I almost always do).

I think about how farking awful the software is.

I shop at one of several local Super Stop and Shop stores that have mobile scanners. You scan your Stop and Shop card at the entrance on a rack of mobile scanners. This presumably identifies you as a trusted (or at least registered) customer. A mobile bar code scanner lights up, you pull it off the rack, and away you go to do your shopping.

This is great (even with the software complaints) because I can bag my groceries into sturdy reusable bags as I go and push my whole cart through at checkout. In effect this lets me parallelize bagging/checkout with my shopping, which saves me huge chunks of time. When you are usually shopping with a tired 3-year old, you seriously want to spend the minimum time possible in the store. This process is made even more attractive by the fact that they have let go almost all of their dedicated baggers, so normal checkout is now considerably slower than it used to be.

Every once in a while you get "audited" by a clerk who enters a special code and scans several items to make sure that you didn't slip anything in to your bags. Even this doesn't take too long if the clerk wasn't halfway across the store when they get the page to audit you.

I have three major problems with the software:
  1. The scales are slow
  2. The checkout is slow
  3. There is huge disparity between stores
First the scales. The way the store deals with the problem of having to weigh produce is you weigh it at a special scale, then print a bar code, attach it to your bag of broccoli, scan the bar code, then drop it in your bag. Elegant and simple.

OK, but how do you look up "broccoli"? Well, there is a search screen and you can start typing "b-r-o" and as you type a set of icons will appear that match your input. This is a nice UI design. But you have to wait 4-5 seconds between each letter typed. It does not cache your typing so it won't catch up, and there is no feedback that your typing is pointless.

Think about this problem space for a moment. There are at most a few hundred items in the produce section. Even on most embedded systems you should be able to fit the whole searchable database in RAM. Even if you store it in a horribly inefficient way. How on earth can this be so slow? I am reasonably confident that I could write a vastly superior search implementation on my 2002 era java enabled phone. My blackberry and iPhone could both do this without breaking a sweat.

Fortunately there is a shortcut. If you know the PLU code you can enter that. I occasionally skip purchases if I can't easily find the PLU code, though. It's just not worth the pain.

OK, on to the checkout. When you are done shopping you go to one of several special lines and scan a special barcode that signals that you are done shopping. This triggers the unit to start downloading data (or notifies the central system if the downloading happens as you shop - whatever). You place the scanner in a holder by the checkout stand and scan your Stop and Shop card at the register.

The register then starts ringing up your order. One. Item. At. A. Time. At about a second or a second and a half per item. What? They have all this data for what you purchased at their finger tips and it has to go this slow? Think about this problem space for a moment. Is this a different problem from recalculating a spreadsheet? No, it isn't. How would you feel if your spreadsheet took 1-1.5 seconds per line to recalculate? You would throw your computer through the window - that's how you would feel.

OK, now my last problem - disparity between stores. A little over a year ago I went to a different local Stop and Shop and used the same system. It isn't as close to me, but it is near a favorite liquor store and a Starbucks so I find myself in the neighborhood from time to time needing to do some shopping.

Well, imagine my surprise and delight when I got to the register and my entire shopping cart rang up instantly. Not. One. Item. At. A. Time. Sweet! They fixed the bug.

It has been over a year and my store still hasn't updated their system. What? Who does Stop and Shop hire to do IT project management? What are they thinking? If you have a known bug that is likely to drive people nuts and you have fixed it, for goodness sake put it out there for your users. You look like a total idiot if you don't.

David

No comments: