Comment by AnthonyMouse | Hacker News Reader

Comment by AnthonyMouse | Hacker News Reader

Parent Full thread

> If instead of queues we had stacks (last in, first out), we would no doubt see people organize themselves into the stack in such ways that other time-wasting externalities would arise.

The purpose of a line is that you have an inconsistent flow rate. If you always had less than one person arriving per minute and it took less than one minute to process one person then there would be no need for ordering the people waiting because there would be no people waiting.

The trouble arises when that isn't what happens. At 10AM there is no line at the lunch counter but by 11AM or noon there are more people looking for food than there is serving capacity, so a line forms and remains until 1PM or 2PM when the rate of new customers has fallen back below serving capacity for long enough to process the backlog.

A queue is inefficient because it causes everyone to wait e.g. 15 minutes during the busy period. If you use a stack instead of a queue then a person who arrived at 11AM and sees the number of people in line in front of them continue to increase will correctly deduce that continuing to wait is futile. They won't be served until ~1PM when the entire backlog is filled, so assuming they aren't allowed to reposition themselves in line immediately, they might as well just leave and come back later. And maybe resolve to get there by 10:45 next time, when demand is lower and everyone is still being served immediately. Which is where the efficiency comes from -- more people arrive either before or after the rush to avoid getting stuck at the bottom of the stack, so the wait time goes down.

The trouble with it is that it lowers the average wait time but it makes the wait time for any particular individual completely unpredictable. You could end up being second to the top of the stack for several hours while everyone else is served immediately.

I'm sorry, but none of this is making sense to me.

>A queue is inefficient because it causes everyone to wait e.g. 15 minutes during the busy period. If you use a stack instead of a queue then a person who arrived at 11AM and sees the number of people in line in front of them continue to increase will correctly deduce that continuing to wait is futile. They won't be served until ~1PM when the entire backlog is filled, so assuming they aren't allowed to reposition themselves in line immediately, they might as well just leave and come back later.

Which is a big assumption.

That's exactly what the GP was warning about: people will just go into a different "meta-queue" in which they vie for being the technically-"last" person to enter the real (LIFO) queue [1], with all the externalities that involves. People are still spending time waiting, they just have to do it in a more roundabout way. No free lunch (in money or time).

>And maybe resolve to get there by 10:45 next time, when demand is lower and everyone is still being served immediately. Which is where the efficiency comes from -- more people arrive either before or after the rush to avoid getting stuck at the bottom of the stack, so the wait time goes down.

So ... the entire counterintuitive result is just an artifact of how this method makes it more expensive (in time spent, assuming away the meta-queueing problem above) at peak times? But then it's no different from the case for peak-hour pricing (or the opposite in the case of happy hours and early bird specials).

So it's not that this is somehow more efficient, it's apparently just another way to make peak hour service more miserable. But worse, it does it in a very convoluted way that shifts the entire problem over to "how to game the official record of when I entered the stack".

This whole study seems to confuse a lot more than it clarifies.

[1] which, I know, would no longer be a queue but a stack

> That's exactly what the GP was warning about: people will just go into a different "meta-queue" in which they vie for being the technically-"last" person to enter the real (LIFO) queue [1], with all the externalities that involves. People are still spending time waiting, they just have to do it in a more roundabout way. No free lunch (in money or time).

The ability of someone to "cut in line" by leaving and then coming back is obviously a critical failing of the system if doing that is cheaper than doing the thing you're desired to do. But you can imagine rules to address it, like if you leave and come back then you get the same position in the stack as if you had never left. (And if this is being implemented in a computer then maybe you get a message on your phone once you're at the top of the stack.)

> So ... the entire counterintuitive result is just an artifact of how this method makes it more expensive (in time spent, assuming away the meta-queueing problem above) at peak times? But then it's no different from the case for peak-hour pricing (or the opposite in the case of happy hours and early bird specials).

It doesn't make it more expensive at peak times. The total cost is exactly the same, but it is imposed highly disproportionately, so that instead of 120 people each waiting 15 minutes, you have 105 people who are served immediately and 15 people who would each have to wait two hours. The theory being that at least some of those 15 people will then give up and leave because they can go do something productive with two hours when they couldn't have with only 15 minutes.

You get essentially the same result by putting a small hard limit on the length of a queue and then banning anyone who showed up when the queue is full from entering the queue until it is completely empty.

>they might as well just leave and come back later

Which means you haven't improved the efficiency, you've just shifted it into a different category.

You could do the same by having a bouncer that randomly doesn't let people in. It's not what people think of when they hear "reduced waiting times".

Reply on news.ycombinator.com