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

Yes, I Think Your Project Sucks

I am a software/systems architect in a very large corporation for which software and IT are not core business. In this role and previous roles I have frequently been called upon to participate in project code reviews.

When I perform these reviews I usually generate pages of notes and constructive criticisms that I share with the project team. I don't pull punches in these reviews. If I spot some code that is smelly I will highlight it and explain why it is wrong. I will call out shoddy code organization and poorly thought out build scripts and stupid package naming and bad error handling and crappy unit tests and useless comments and other details ad nauseum.

But all of these details are the trees. What makes me like or dislike a project is the overview of the forest. To be sure, one element is the sheer number of details that I have to call out. An overgrown forest stands no chance. Here are some other higher level things that I look for:

• Evidence of a professional developer attitude
• Evidence that the end goals are understood
• Evidence of higher order design/architecture

Evidence of a professional developer attitude

Show me that you have a process. That you care about the quality of the project and the code. That you care what other developers think. That you are trying to set a good example. Some indicators:

• Clean, well organized repository
• Repository is up to date and has regular check-ins (with comments!)
• Clear build scripts that serve as documentation for the build process and dependencies
  
• Unit tests and TDD thinking (even if you don't do TDD)
  
• Continuous build (or at least nightly)
• A single central build environment (NOT your IDE, doofus!)

Evidence that the end goals are understood

Show me that you understand the user. That you aren't going to show the user error messages like, "Database Error: Code 5387". That the user interface doesn't freeze or time out. That you have processes in place so that you can quickly debug problems in production. If this is an API, show me that it is clear and understandable and that the contract utterly explicit. Some indicators:

• A system for handling errors/exceptions that is logical, that logs details, that presents the user with a message that is clear and simple.
• Asynchronous UI processes
• Sensible timeout logic where appropriate
• Integration/unit tests that monitor task time and alert when changes to the code may have slowed something down
• For APIs do the error messages contain the extra details that a developer would need?
• Do you eat your own dog food?
• Are you logging in such a way and at an appropriate level of verbosity such that you can troubleshoot unexpected problems?
• Documentation for any APIs. Yes, documentation. If you can't clearly explain in a document how to use your API, then what good are you (or it)?
  

Evidence of higher order design/architecture

Show me that you have thought about reusability. That you understand the value of layered abstractions. That you understand what an object is and what a process is. Every time you look for a library to do X for you and don't find it, do you then write a decent library to do X? Or do you just hack some code to do X into the middle of some poor unsuspecting class? Some indicators:

• If you are writing a service that does Y, do you have a well orchestrated class/library that does Y, upon which you have layered a service? (as opposed to building the functionality directly into the service classes/methods)
• Are complex tasks broken down into small logical slices? (as opposed to long confusing methods)
• Are things that could/should be reusable actually reusable? (as opposed to having unnecessary interdependencies with the rest of the project)
• Are your objects named like (and function like) nouns?
• Are your method and object names indicative of actual behavior?
• Is the project an assembly of small pieces that fit neatly into a bigger picture? (as opposed to a monolithic beast)
  

It isn't shocking to me that I have never seen a project that scores perfect on all of these indicators. Perfection should be rare. But it is shocking to me how many projects I have seen that score zero.

David

Jumper Cables

I am not normally a political activist, but I'm going to make a rare exception.

Let's see if we can bring the 4th amendment back to life and send a message to our elected representatives that we do not want to live in a police state.

Pledge here if you agree. I'll forgive you if you don't.

Charities Suck

OK, that's a terrible thing to say and I don't really mean it, but GOD they can be annoying.

About 12 or 13 years ago I joined PBS. We lived in Chicago at the time and I joined with a largish donation that entitled me to a Jacques Pepin book. I mean I love the programming (Jacques, Dr. Who, Monty Python, etc) and I felt good about contributing to make the programming possible. I was very happy to contribute and I would have happily renewed my membership year after year, occasionally taking advantage of interesting offers and making larger donations.

But then they started to call and ask for money. Mind you, when I first signed up they asked me if it was OK for them to call me and I said, "No." Every time they called I asked them to remove me from their call list. After a while I started asking for supervisors. Nothing helped. It will be a cold day in hell before I ever give my contact information to a PBS station again.

They can have my money, but they absolutely can NOT have my digits.

What reminded me of this? Yet another friggin' message from the Red Cross about another blood drive that I can't possibly go to. I have donated gallons of blood over the years and I am happy to do it when I can, but I seriously do not want their stupid machine to talk to my machine twice a week about a blood drive happening in the middle of the work day close to home, but 35 miles from where I work. It will be a cold day in hell before I ever give my contact information to the Red Cross again.

The only difference is that I have long since learned never to answer my phone. If you call my home phone I absolutely guarantee that you will not talk to me.

Just because charities have legal immunity from ignoring Do Not Call registries, does not mean that there are no consequences for seriously pissing people off - how can they possibly not understand this?

And yes, all of my numbers are on every possible Do Not Call registry.

David

Digital Scales and Accuracy in Baking

If you read my review of Artisan Bread in 5 Minutes a Day, then you know I have been baking.

Since I am a bona fide nerd, that means that I have been reading a lot about baking from all kinds of different sources.

And that my friends, means that I have repeatedly run across the completely ridiculous assertion that weighing things in grams is somehow intrinsically more accurate than weighing things in ounces.

So here is a little primer, let's call it "Balance 101".

• A balance is what scientists call a scale.


• Units of weight measure are ways of describing how much of something you are weighing.


• Units of measure for weight are always convertible to any other unit of measure for weight (1g = 0.03527oz). They have nothing to do with either precision or accuracy.


• Precision is the number of significant digits used for the representation (1.000g = 0.03527oz), or the degree to which fractional units of measure in different units can be considered to be the same, within the constraints of accuracy.
  


• Accuracy is the degree to which the displayed precision reflects reality. (My balance reads 1g, but I know that really means 1g, plus or minus 1g, so there is somewhere between 0g and 2g of stuff being weighed).

So where does this annoying assertion come from? Why do so many sources claim it?

Well, let's look at the specific case of my kitchen balance. It has a precision when weighing in grams of 1g (that is, it displays no fractional grams), but a precision of 0.1oz when weighing in ounces. As long as the accuracy of the balance reflects the least precise of these measures (0.1oz is less precise because it is 2.8g), then it doesn't matter which unit of measure you use to weigh. That is, if the accuracy of the scale is plus or minus 3g, then it doesn't matter at all whether you weigh in grams or ounces.

However if the actual accuracy of the balance is plus or minus 2g (or less) then it actually is better (more accurate) to weigh in grams.

Notice that this has nothing to do with the fact that grams are more precise than ounces. It has to do with the fact that the firmware in the balance fails to represent the values in ounces with sufficient precision to reflect the actual accuracy.

David

Why I Hate Livejournal

(cross-posted to my Livejournal page)

Pretty inflammatory subject for a first post, isn't it? They'll probably ban me.

But I absolutely HATE that I can't get RSS feeds from friends private journals. Do the developers at Livejournal pay any attention at all to Web 2.0 trends?

Listen up people! If I can't read it in Google Reader, then it doesn't exist.

David

No. No. No. Do not even THINK of doing that.

Over on Coding Horror Jeff Atwood has a post up about a post that Raymond Chen had up. And I am going to comment on Jeff's post here, making this a meta meta blog, I guess.

The whole thing is talking about how dialog boxes confuse clueless users and they tend not to do the right things when they see them. OK, fine, I agree that that happens and that it is a very real problem with computer usability.

But then he (Jeff) makes this comment:

If you need to update, do so. if you need to download and apply security patches in the background, do so. If you need to send crash data, do so. Silently. And do it in the background, when the PC is idle-- without bothering the user.

AAAAAAAHHHHHH! NO, NO, NO.

I never want my computer to install anything unless I know that it is happening. I never want anything sent out of my computer unless I know that it is happening.

I run software to notify me when malicious software (and anything that does something on my computer that I am unaware of is malicious, even if Microsoft wrote it) tries to access the internet.

And I disable all automatic updates. Of course I want to have the latest security patches (and I do), but any install, no matter how innocent, can break my system and I at least want to be able to identify the culprit. If I install an IE patch and all of a sudden Firefox stops working or something, then at least I know what to blame and where to look for a fix.

That kind of automagical maintainance logic belongs in an appliance, not a general purpose computer. Only when all of the variables can be fully controlled does it make sense in my opinion. If it does exist in a general purpose computer, it should be something I can opt into, not opt out of.