Hacker News Reader

Comment by PaulHoule | Hacker News Reader

This book is regular reading in business schools (they have a whole shelf of them on short-term loan at the B-school library across the street from me)

https://en.wikipedia.org/wiki/The_Goal_(novel)

but the concepts go against the intuition of everyone in business.

For instance imagine a business process where work arrives at a station in a random Poisson process and takes a certain time t to complete. If the station is busy the work gets added to a queue.

You might think this system has a capacity of 1/t (100% utilization) but if you actually try that you'd find that the length of the queue becomes infinite. Put enough steps like this in a system and the whole system throughput will go to zero.

Up to 60-70% utilization the length of the queue will not become excessive so an idle percentage of 30% is good to aim for. Try to get it much less than that and you will find the system as a whole becomes unproductive.

View on HN

Any productivity blog that starts with the flawed premise that you can have the average (or even above-average Googlers) developer pump out bugfixes and features 8hrs/day, doing focused work without tiring sets unrealistic expectations.

The reality is that a developer's day is a mix of meetings (for coordination they are not necessarily useless), training (it's a fast moving environment with self-actualization), code reviews, environment setup, helping colleagues, and finally, code writing are all necessary for a successful development endeavor.

If I need a full compile that takes 15 minutes it does break the flow, but so does all of the above. When Sundar Pichai said that productivity was too low, he's just preparing the press/people for layoffs and hiring freezes.

This is spot on. Code is simply a reflection of a very deep thought process.

Google spends all that money on "taking the everyday problems away" from its engineers so they can spend their time in the deep thought needed to really think about a problem before writing code to reflect their solution.

The fucking bullshit MBA approach of "look busy" is what Google and other tech companies have disrupted through the years.

You're absolutely right in the last statement that this is a hedge by the CEO to prep for uncertainty. I would take that argument a bit further and claim that this is also a hedge to insulate their recruiters and pretty much everyone with connections in the bay area from freely referring candidates from the other sinking ships such as Facebook, Snap and the rest that would dilute culture.

He seems to be giving cover to everyone with the hiring freeze so that they can more readily control the influx of job applications that is happening right now with these other large employers laying of talent very similar to the cohort working at Google.

> You might think this system has a capacity of 1/t (100% utilization) but if you actually try that you'd find that the length of the queue becomes infinite

I'm not following.

    1/t = Facilities's rate of work
    t = Time to process a unit

If you had an infinite queue of objects (with t time required) being processed at 1/t (rate), your workload/utilization is 100%, right? You seem to be saying otherwise.

Also, what do you mean by "the length of the queue becomes infinite"?

Is there some property of a random Poisson process that has a growth bias? Can I think of it like flipping heads/tails where you might go on a run, however, for a large number of outcomes, it should converge on a number of outcomes in the middle?

> length of the queue becomes infinite

If you simulated the queue forever and took a running average (for any finite length of time that's just an integral, and you take the limit as t->infinity) of the queue length, the result would "be infinite" -- for ever possible real number the result of such a limit of it existed would be greater.

> is poisson special

It's easiest to work out with elementary mathematical tools with a poisson process, but otherwise no.

There's a decent overview [0] that derives the expected length, and showing that it grows without bound up to 100% is suggestive of the result (combine that with the fact that the mean length is strictly monotonic increasing where it exists and is infinite at >100% utilization, and that shores up the mathematical loose ends).

For the poisson process in particular, the "balance principle" in that link I think will serve to provide the right intuition about the problem.

> should converge on the number of outcomes in the middle

That's the problem. We have infinite head and tail flips, but when the length is 0 only half of those matter. Adding up those one-sided differences still wouldn't have to be infinite per se, but 100% utilization is the threshold at which it gets pushed over the edge (large differences are "rare" to get to in the first place but you'll spend time inverse to that probability in their vicinity).

[0] https://www.win.tue.nl/~iadan/que/h4.pdf

> There's a decent overview [0] that derives the expected length, and showing that it grows without bound up to 100% is suggestive of the result (combine that with the fact that the mean length is strictly monotonic increasing where it exists and is infinite at >100% utilization, and that shores up the mathematical loose ends).

Ah! I can process this and it makes crude sense to me. Thank you!

What is being implied is that you start with a finite queue size and there is a random poisson process at the rate of t adding items to the queue. Intuitively, you would expect the queue size to be finite and stable. When you simulate this, more often than not, the queue tends to grow to infinity. In practice, it means that your team will burn out much faster.

Thank you. I figured this is one of those things where a simulation really proves the intuition.

Reply on news.ycombinator.com