A single line to 3 cashiers is ~3x faster than a separate line for each cashier • Hacker News Board

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#41

Post by ScottBurson » Thu, Dec 08, 2011, 5:38 PM UTC

kenjackson wrote: post #17

hrabago wrote: post #10

Earlier quoted context omitted.

No, because the cashiers handling smaller transactions finish quicker and can process more people. If you're stuck behind a guy which takes 2 minutes to check out, people in other lanes will be in their cars before you even begin checking out.

Here's a concrete example to make harabago's point clearer (since I think it is a little tricky). Imagine 9 people in line. Each person takes 1m to checkout except the first guy takes 10m. With three lines it looks like this (these are their wait times before being serviced): 0 0 0 (first person in each line has no wait time) 10 1 1 11 2 2 If you sum up the total wait times you get: 27m Now do this with a single file…

The problem with your first example is that in real life the queues will rebalance. The two people behind the first guy won't just stand there for 10 minutes with the other two checkouts empty; they'll switch lines.

If they do that, they'll each wait for 3 minutes, giving the same distribution as in the single line.

Ah, you say, but what if other people have entered those lines already? Then you have to count their wait times too, which will be shorter in the three-line case than the one-line case.

Using one line doesn't reduce the mean wait time; it's always the number of people waiting divided by the throughput. What it reduces is the variance in wait times, making the system more fair.

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#42

Post by ssharp » Thu, Dec 08, 2011, 5:38 PM UTC

smackfu wrote: post #8

Wouldn't it be 3x the velocity, but the line is 3x longer, so your total wait time is the same? The article is mainly saying that people like moving faster, but is that really a phenomenon?

Even if the overall mean time ends up being the same, you are reducing variance, making wait times more predictable.

There is a good amount of psychological research on waiting, and people in lines are much happier if certain things can be relied on. One of these things is fairness, as in, my wait time should be as long as everyone else's. Another thing is knowing how long the wait will be, which reduces anxiety over the wait. Single queue feeders enable those two things to happen much better than multiple queues. So even if the math ends up being the same either way, the customer will likely be happier with the single queue.

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#43

Post by rdtsc » Thu, Dec 08, 2011, 5:42 PM UTC

pnathan wrote: post #27

FYI: This is an example of the branch of mathematics called queueing theory. http://en.wikipedia.org/wiki/Queueing_theory It's a fascinating study requiring a good knowledge of probability to use beyond the simplified models. It turns out from the math that throughput using a single queue is better than using multiple queues.

Not trying to be condescending but doesn't it surprise anyone here that this is _not_ obvious? At least on this site, there are still people doubting or debating this.

So I am wondering why don't stores do this already. And I believe it is because of perceptions. They understand that time will be saved, however, they realize that most people will be scared by a long line.

One long line that moves fast will still appear terrible compared to a bunch of small lines that crawl. Because people don't look long enough to estimate the rate of movement. They see both lines as static (not moving).

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#44

Post by NyxWulf » Thu, Dec 08, 2011, 5:42 PM UTC

pnathan wrote: post #27

FYI: This is an example of the branch of mathematics called queueing theory. http://en.wikipedia.org/wiki/Queueing_theory It's a fascinating study requiring a good knowledge of probability to use beyond the simplified models. It turns out from the math that throughput using a single queue is better than using multiple queues.

Queueing theory is a prominent topic in Operations Research. If you want to read a detailed book on it, Fundamentals of Queueing theory by Thompson et al is the bible.

A couple of additional thoughts, pooling queues like this only works if the changeover time to process different types of things is low. So in the case of a grocery store where there is no separate changeover or batch setup time it works well. If you are pooling work to people though it breaks down if only certain people can do certain types of work or the change over time to switch to a different task exceeds a certain threshold.

The other thing is the title of this post is almost certainly incorrect. Switching to a single queue reduces average queue time, but it does not reduce work time. In order to be 3x faster you would have to reduce both. The other factor at play is that people continuously rebalance from slow lines to fast lines, which also helps mitigate some of the problems.

* some grammatical edits

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#45

Post by jff » Thu, Dec 08, 2011, 5:42 PM UTC

smackfu wrote: post #34

jff wrote: post #25

Earlier quoted context omitted.

Ah, but you see, anyone who writes checks (hellooooo, slowdown!) and anyone who is scared of technology (I think the two groups overlap a lot) will go wait in another line. So at least at my store, the self-checkout lanes have a lot of young people buying one or two items and paying with credit cards, which works out to a pretty good speed. Occasionally you get somebody who sits and stares at each screen of instructi…

I guess it depends on the quality of the self-checkout system. At my Stop & Shop, there are four or six self-checkout lanes staffed by a single person (Go go union job elimination!) If you get through a purchase without running into "wait for attendant", sure it's fast. But if you do have to wait, because their fundamental distrust of the customers makes the system get many false positives for stealing, now you are i…

Wow, that sucks. My local store only ever does "wait for assistance" when you buy booze... and half the time the attendant will just gleefully press "ok" on his terminal without even checking my ID, so it goes even faster :)

Implementation details matter, I guess. (Pretend I made some interesting reference to Steve Jobs' managing style here)

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#46

Post by ScottBurson » Thu, Dec 08, 2011, 5:43 PM UTC

smackfu wrote: post #28

What I didn't see in this article is why retailers don't do this today. I see a lot of positives listed and no negatives, so it seems like a no-brainer, right? Yet the biggest retailers like Walmart and Target have tons of lanes, and even do staggered front/back lanes which are terrible for the customers. Is it because there are negative feelings to seeing a long line, and that people do not expect it to be fast so t…

Some places do this. Fry's Electronics, for example. It works fine. Some supermarkets I've been in do this for their express lines ("10 items or less").

Oh, and airline ticket counters are routinely run this way.

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#47

Post by nkoren » Thu, Dec 08, 2011, 5:46 PM UTC

kenjackson wrote: post #17

hrabago wrote: post #10

Earlier quoted context omitted.

No, because the cashiers handling smaller transactions finish quicker and can process more people. If you're stuck behind a guy which takes 2 minutes to check out, people in other lanes will be in their cars before you even begin checking out.

Here's a concrete example to make harabago's point clearer (since I think it is a little tricky). Imagine 9 people in line. Each person takes 1m to checkout except the first guy takes 10m. With three lines it looks like this (these are their wait times before being serviced): 0 0 0 (first person in each line has no wait time) 10 1 1 11 2 2 If you sum up the total wait times you get: 27m Now do this with a single file…

Good point, well made. In reality, the situation in your example of a multi-line queue is not usually as dire as your example portrays, because the delayed people in queue #1 are likely to jump ship sometime after the other two queues. have cleared. Nonetheless, this queue-jumping behaviour confuses the circulation pattern and causes congestion in the vicinity of the tills, which itself slows down the throughput. There's no doubt that a single-file call-forward queue is more efficient for both the customers and the shop.

One point I didn't see made in the article: single-file queues are also a fair amount more space-efficient, which has value to retailer that is separate from the issue of throughput. This spatial opportunity cost is something that also needs to be considered when designing a queuing system.

I've seen subtle & sophisticated studies which do say that customers prefer multi-line queues to single-line queues, but I rarely see any that bring the other factors into play. Retailers really should base their decisions on the following formula:

average revenue per customer * (% improved customer throuhgput - % of customers you'll lose because of multi-line queues) + extra retail m^2 * average revenue per m^2

In most cases, you'll find that that the value of a single-line queue is a good deal greater than the value of a multi-line queue. So this is one of those cases where it's likely a good idea to not cater to customer preferences.

(I'll also note that single-line queues are much more common here in the UK than in the US; I've become quite accustomed to them and in fact dread multi-line queues and the inevitable idiots that I get stuck behind in them. It seems likely to me that a large part of the American aversion to them is simply a bias against the unfamiliar; this is likely to subside as they become more accustomed to it.)

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#48

Post by missing_cipher » Thu, Dec 08, 2011, 5:48 PM UTC

bryanh wrote: post #4

An excellent video on the phenomenon from the "Engineer Guy" series: http://www.youtube.com/watch?v=F5Ri_HhziI0 And just in case you feel like killing about 20 minutes of your day, check out the rest of his videos. They are excellent.

I love his videos. I wish he would make more. The harddrive one was interesting.

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#49

Post by kenjackson » Thu, Dec 08, 2011, 5:49 PM UTC

ScottBurson wrote: post #41

kenjackson wrote: post #17

Earlier quoted context omitted.

Here's a concrete example to make harabago's point clearer (since I think it is a little tricky). Imagine 9 people in line. Each person takes 1m to checkout except the first guy takes 10m. With three lines it looks like this (these are their wait times before being serviced): 0 0 0 (first person in each line has no wait time) 10 1 1 11 2 2 If you sum up the total wait times you get: 27m Now do this with a single file…

The problem with your first example is that in real life the queues will rebalance. The two people behind the first guy won't just stand there for 10 minutes with the other two checkouts empty; they'll switch lines. If they do that, they'll each wait for 3 minutes, giving the same distribution as in the single line. Ah, you say, but what if other people have entered those lines already? Then you have to count their w…

Sure, if the line perfectly rebalances then three lines is almost identical to the single line.

BUT as I'm sure you know, it's sometimes hard to know when to move. Is it after you've waited one minute, then hop to the back of another line?

Let me give you a concrete example: Imagine you enter a line with 15 people in it. Your line moves 14 people through perfectly. You're next, but the guy in front of you takes longer -- maybe he can't make up his mind about wanting some bubble gum. Do you hop to the back of another line and wait 15 more minutes (because the average queue length is 15m) or do you wait it out while this guy in front of you goes? How long will this guy take? 1 more minute or 30 minutes?

And of course, once you hop to the back of another line, the guy from your previous line finishes, and there's someone else in your new line who takes forever. Then you're even more upset that you switched lines!! :-)

With a single line you remove the need for an oracle, which you need for the n-line scenario.

Re: A single line to 3 cashiers is ~3x faster than a separate line for each cashier

#50

Post by rdtsc » Thu, Dec 08, 2011, 5:49 PM UTC

JoshTriplett wrote: post #12

It becomes even more obvious if you think of it like scheduling processes on a CPU. Why needlessly set CPU affinity and only run on a single CPU when you could just take the next available timeslice on any CPU?

> Why needlessly set CPU affinity

There are practical reasons to do that. That is common in realtime systems. Trying to isolate the cpu for a particular process. So that is available faster when that process needs it. You could also have n-realtime processes. You don't want them competing for the same CPU if you know ahead of time you can allocate a CPU for each one of them.

Another reason is caching. For example you can assign a CPU to process network interrupt requests from a particular network device. Then you might or might not want to also assign the process that consumes that data to that CPU.