Hacker News Reader

Comment by travisgriggs | Hacker News Reader

It's funny. I saw the headline, and my immediate association was "employees" rather than computation tasks. And I was thinking "not even!" It's been my experience that scaling up employee count, has diminishing returns, with even some net negatives with some adds.

I'm not sure I buy the quadratic gains, but the general gst is that if done correctly, two processes/tasks/workers/etc is better than one.

So why is this? Why does it work in computing, but not with people? Is it the nature of the tasks (one is problem solving, the other is grinding out computations?). Is it differences in configuration?

View on HN

It works for employees, but only when you care about latency and the employees are interchangeable. A classic queueing example is tellers at a bank. One teller and the line is awful because of one complex transaction. Two and you are in and out in a minute.

https://ryanhcom.files.wordpress.com/2017/07/index.png

bank with one queue and two tellers. two queues and two tellers can introduce frustrations, when one queue advances but the other doesn't and social pressure forbids head-of-line queue jumping.

My local grocery store is like this.

They never seem to have enough cashiers, and instead of having a single line served by many cashiers like most stores in the area, you just have to pick your line and hope it works out. They normally only have two registers open, too. So it is abundantly clear when someone has managed to get ahead of you.

No idea why this in particular drives me so nuts

I think we situationally judge "fair queue" by two rules.

  1) did my queue block? if so, its "unfair" your queue moves but I was ahead of you
  2) if somebody jumps ahead of me, even if I am aware they were in another queue before me, I feel like I've been cheated

There's also some subconscious effect - you rarely remember when queues are fair to you, but you always remember when you get 'queue-screwed'.

I'm the same way, and I'll tell you why. Because people are greedy assholes. There have been multiple times I've been in a place where there was one line, and then someone, coming in, seeing that one line, feeding into two or more registers/whatever, decides to go create a new line. The employees don't care who walks up to their register, and no one initially cares to make a big deal about it...but then you get a few more people who show up, think there's two lines, and voila, now there -are- two lines.

Unless the store makes it impossible for more than one line to form, you'll end up with one line per register/whatever.

Seems like the places that make it work have a long aisle fenced by store shelves so it's very obvious.

This works for sure. Is this what techies call "head of line blocking" being solved?

Yep; but for some reason there are still stores being laid out where that isn't happening. Nearly every grocery store, Target, Costco, etc, that I've seen has per register lines. Even the relatively newly built that I've seen, they still set up per register lines.

Everywhere around here has one line per register. At the beginning of social distancing one large local store built a barricade and enforced a single line so people weren't standing so close together. I went there once during that time and the line wrapped a quarter of the way around the store, ending over in the freezer department. It went faster than it looked, but that store also tends to have enough checkouts open and staffed with efficient, motivated workers.

> doesn't and social pressure forbids head-of-line

This is a horrid implementation of a work queue or any queuing in general. You have a multiple workers (tellers) and a single queue - the rest is a dumb design. The other option is work stealing but the example would not work so well with a bank and tellers.

Virtually all banks around here use ticketing system with different queue, effectively a priority queue with multiple workers.

> two queues and two tellers can introduce frustrations, when one queue advances but the other doesn't

That's not the main problem. If each teller has their own queue, you just have the one teller / one queue problem twice. Instead of having nearly no queue time, you'll have lots of queue time in each queue.

It works with humans when they don’t need to constantly run a consensus algorithm (like agreeing on a problem or understanding the team’s relationship with externals.)

An assembly line of 3 people will probably be >3 times faster than a single factory worker.

Interestingly this talk by Casey Muratori [1] makes a reasonable rhetorical case that Amdahl’s law (about process parallelization), Brooks’ law (about team network communication) and Conway’s Law (about how organization communication shapes software structure) might all be variants on the same basic principle of trade off between parallelizable and unparallelizable work…

[1] https://m.youtube.com/watch?v=5IUj1EZwpJY

>So why is this?

Probably because you're not modeling the same thing. The workers in the article are independent tasks. No communication between the two needs to be done. Employees have to communicate as a team. It worsens as you add more employees. 2 employees, 1 line of communication between them, but 3 employees and it becomes 3 lines. 4 becomes 6 lines. 5 employees becomes 10 lines. At this point you're having meetings, which everyone knows is the opposite of doing work.

> And I was thinking "not even!" It's been my experience that scaling up employee count, has diminishing returns, with even some net negatives with some adds.

That's fair, but I don't think you're going to hit that from 1 -> 2. It's been my experience that 4-5 is where the diminishing returns start really happening and a complete loss of gain at around 4-8.

> So why is this? Why does it work in computing, but not with people? Is it the nature of the tasks (one is problem solving, the other is grinding out computations?).

With a worker (computer) the task has generally been completely defined before the task starts. Tasks done by human workers generally require a portion of "deciding how to do the thing". Assuming that requires full team meetings, on a team of 8, it requires 8 times as many meetings for 8 people and each meeting taking up 8 times the number of people's time (~64x time loss).

this is compared to a hypothetical "1 person meeting", which would probably just be someone sitting around thinking about the best way to do something

> Assuming that requires full team meetings, on a team of 8, it requires 8 times as many meetings for 8 people and each meeting taking up 8 times the number of people's time (~64x time loss).

Wait, I don't think that's how work and meetings work. At least, I really hope not. It hasn't been in my experience, thank goodness!

> Wait, I don't think that's how work and meetings work.

I'm not including all of the things that come up that don't require a team meeting.

But if we're assuming that something is discovered that requires a full team meeting by each employee roughly once a week (number pulled straight out of my ass, feel free to sub in your own, the math doesn't depend on this), that's 8 meetings a week for the 8 person team (totaling roughly 64 hours), and only 4/4 for the team of 4.

This is, of course, assuming the rate of discovery of things discovered requiring a meeting remain constant as the team increases. In my experience, this is not the case, and it usually tends to increase as people lose track of what everyone else is doing, there's an increased need to "re-sync". I believe this increased need is what drives it from exponential (in my naive answer) to the combinatorial (in practice) increase people usually quote when throwing around Brooks' Law.

When I was young I heard a saying in reference to kids helping with farm work. "Two boys are worth half a boy. Three boys are worth no boy at all."

I think the key difference is that computers are computers and people are people. Computer workers can be programmed to know what each other are thinking and be able to efficiently divide a task into pieces that will fit together to form a solution. People can't do that as efficiently, and without motivation are just as likely to distract each other from doing their own work.

    one boy, one brain
    two boys, half a brain
    three boys, no brains

But twice the eyes, and that's worth a lot at times

My first thought was "pair programming", in which I like to say that you get half as much done in a quarter of the time. Doesn't scale beyond two, though.

My take: it’s because with humans, communication is lossy and slow and winds up being the majority of the bottleneck for all collaboration.

I agree. Plus, politics (internal) will inevitably start taking up more and more of your employees time.

I think the ideal org size for technical efficiency per person is 3. More than 3 and now you probably need some management bandwidth. Which is ok, but that is less efficient. But so many (most) things worth building you just need more than 3 and of course for dollar efficiency you can be the tech giants with thousands of people!

Because you don't usually pair two factory identical employees over dedicated message buses?

Nevertheles considering that a single person is entirely unable to do heavy lifting, there is no well defined increase in productivity.

Reply on news.ycombinator.com