How to Solve Google’s Billion-Dollar Productivity Problem | Hacker News Reader

How to Solve Google’s Billion-Dollar Productivity Problem

gradle.com

28 pointsdont__panic19 comments

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.

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?

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.

> 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!

Google's interview process is an impersonal exercise in beating the system. There is an entire economy dedicated to interview prep. They have no desire to hire true "top talent." Their culture is based on looking good on paper, their success lies in former products and advertisement. You can't fix something that is irrecoverably broken.

You won the interview on this one.

Or Google could just learn: focus. Steve Jobs met with both founders a few years prior to his death and told them that very thing. It’s institutional and would require: contemplating what it means to be Google; learning to say “no” more often and a lot sooner; and the discipline to stick to decisions.

I, for one, don’t understand attacking this from a productivity standpoint. It’s actually a why (mission) problem.

I perfectly understand attacking this as a productivity standpoint because google is having a senior management problem that senior management is deflecting onto others.

How do you solve a senior management problem? They won’t fire themselves.

Hostile takeover

This article has nothing to do with Google nor ita non-exist "Billion dollar productivity problem" and just says that engineers engineering will magically fix everything.

Google is a well-known retirement home. But their earlier teams built money printing products. So it's fine. It's a little distribution of money from capital holders to workers (wealthy workers but workers nonetheless). That's all right.

Anyway, article mentioned that it could be things like slow dev tools etc. But ultimately it appears cultural.

Of all the major tech companies, Google is the one that invests the most in their development tools, so that's unlikely to be the cause.

It seems more that the article is trying to namedrop Google as a reason to read their blog post, since they don't even suggest a solution to Google's predicament; all they say is that one should invest in their developer productivity experience, and that Google already does.

Right, I agree. I don't think the article has the right of it.

Conway's Law [1] comes to mind.

[1] https://en.m.wikipedia.org/wiki/Conway%27s_law

Reply on news.ycombinator.com