[fdsfsaa]

It's funny that you mention Microsoft. A friend (he has ~100 reports, transitively) at Microsoft tells me that at least on his team, the old-fashioned three-specification (design, dev, test) document triplet, each with a multi-page checklist-laden Word template, has been supplanted by a lightweight scheme that boils down to one or two paragraphs. That's real progress. Microsoft even runs successful open source projects these days and takes external contributions.

Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google.

> PII and other security implication

When your developers are both smart and invested in the product's success, they learn about these things on their own. Sure, they can make mistakes, but so can some damned review committee.

It's interesting to see how people rise to challenges. If there's a security committee tasked with reviewing the security implications of various changes, developers won't take security as seriously. "That's the security committee's job", they might think. But if you entrust developers with their own security, and they're high quality developers, they'll take the responsibility seriously and do a better job.

(I know I'm making a "no true Scotsman" argument, but I think there's a real qualitative difference between developers you can trust with this sort of responsibility and developers who aren't as invested.)

I don't think you can look at security/PII/whatever problems that a committee catches and conclude that those problems would have made it to production absent the committee.

> That is correct, but based on advancements on technology and materials, what's your point?

The Brooklyn Bridge was designed to be six times stronger than it needed to be for its design load. Modern bridges are only about two times stronger than they need to be. The Brooklyn Bridge needed its large safety factor because suspension bridges were not well understood at the time. With modern technology and design tools, we don't need to pay for a safety factor of six.

Imposing Google-style process in 2016 is like building every modern suspension bridges like the Brooklyn Bridge because the Brooklyn Bridge is still standing. "That's evidence that it works, and the process is roughly where it needs to be."

> For instance, the average east asian phrase is shorter (graphically) than the same phrase in a western language, and that all has to be translated and dealt with.

Pseudolocalization and dogfooding help. I'd argue that rapid iteration helps most on UIs. A/B testing and metrics beat heavyweight up-front design any day of the week.

> Design culture evolves. Google wrote all of its own integration systems, code review tools, and many static analysis tools. Even though they have top class systems, they still stick to the same way of doing things. That's evidence that it works, and the process is roughly where it needs to be.

There's an ever-increasing morale cost. How do you expect developers who have experience in process-light environments to come to Google and be happy? "Yes", nobody says, "I want to go from experimenting rapidly on my ideas to writing internal documents to convince people to maybe let me try something."

> If you actually implement [checklists] correctly, they do eliminate many common mistakes.

It's a lot easier to back out a problem diff than to remove the staph you accidentally introduced into a patient's bloodstream.

Process should be proportional to the difficulty of undoing a mistake. If a mistake is easy to undo, it should be easy to do. If a mistake is very costly to undo, it's worth investing in not making the mistake in the first place.

The vast majority of programming errors are of the "easy to undo" variety.

And by the way:

> [Uber's self-driving cars is] a false comparison. Right now, Uber still has to have drivers behind the wheel, whereas Google self-driving cars strive for a higher level of autonomy. Also, Google has not wanted to get into a directly customer facing role, instead looking for partners to manufacture the cars.

Uber recently delivered beer fully autonomously. In a truck. They're definitely planning for L5 autonomy.

[jon-wood]

> Process should be proportional to the difficulty of undoing a mistake. If a mistake is easy to undo, it should be easy to do. If a mistake is very costly to undo, it's worth investing in not making the mistake in the first place. > The vast majority of programming errors are of the "easy to undo" variety.

At Google's scale even small issues will have widespread impact on real people. Let's say you break the ability to reply to email in GMail for ten minutes - cumulatively that could result in hundreds of hours of lost work across all their users.

[fdsfsaa]

What about all the hundreds of decades of work lost because extreme risk aversion makes it impossible to add productivity features to GMail for fear of breaking what works already?

Some people like to cower behind "Google scale" as a reason never to change anything. Not me.

[binoct]

Uber's cars and Otto's trucks are different platforms I believe (for now at least.) The beer delivery was a publicity stunt, but definitely impressive. However it was largely made possible by a team who had spent years at Google figuring out how to do it :)

It's definitely possible for a team to come along and catch up/overtake the Google (now Waymo) project, but I agree with jimmywanger it's not a valid comparison for the sake of this discussion. Uber is following a different path than Google focused on, and is hugely benefitting (as is the whole industry) from the work done at Google.

[jimmywanger]

> Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google.

I don't know what you think of Google's process. A design doc is needed for any large user facing change or large infrastructure change, and it goes through sections and you skip the ones that are not applicable.

For instance, if you're not storing user information, you skip the PII section and so forth. If you're just making a change to adwords billing, you skip the entire I18N section.

Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integrations. You can play fast and loose with those, as opposed to Google, which doesn't really have any legacy code and has to support all existing users.

> When your developers are both smart and invested in the product's success, they learn about these things on their own. Sure, they can make mistakes, but so can some damned review committee.

The review committee does this for hours a day, and they see far more cases. That's like saying that it's better for you to assess the condition of the transmission of your car, because you care more and are more invested. I'd rather have the guy who rebuilds transmissions for a living, who has seen dozens of transmissions, and is familiar with common failure modes and pitfalls.

Specialized labor does help.

> The Brooklyn Bridge was designed to be six times stronger than it needed to be for its design load.

Well, heavier than air flight was impossible before the 1890's without investment in materials, engines, and construction techniques. Is it easier to build an airplane now? I still fail to see your point. We're talking about something where you have to invent the tools to make the tools to make what you want to make, vs. already having the tools available.

> Pseudolocalization and dogfooding help. I'd argue that rapid iteration helps most on UIs.

AB testing on wireframes helps and gets most of the edge cases. After you roll out to production things get hairy.

> It's a lot easier to back out a problem diff than to remove the staph you accidentally introduced into a patient's bloodstream.... The vast majority of programming errors are of the "easy to undo" variety.

Not really, when you're working on fundamental libraries that many products depend on. That can cause issues all up and down the product stack, and you're going to cause issues for developers who rely on your code who now have to throw away months of work.

> Uber recently delivered beer fully autonomously. In a truck. They're definitely planning for L5 autonomy.

That's a publicity stunt, and it's unknown whether or not they got paid or not. Also, Otto was based from Google expats, one from Google maps and one from the Google self driving car company. Your point is?

[fdsfsaa]

> Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integration

The example I have in mind is in a big legacy product. I can't get more specific without outing myself, but it's very far from greenfield.

> Specialized labor does help.

Specialization of labor can also hurt. I've found myself frustrated with security people in the past because they spend so much time thinking about security threats that they start to veto massively useful functionality on very flimsy security grounds. Broad exposure helps too.

> AB testing on wireframes helps and gets most of the edge cases. After you roll out to production things get hairy.

Why? There's no rule that says that everyone needs to see the same UI in production.

> Otto was based from Google expats, one from Google maps and one from the Google self driving car company. Your point is?

It's telling that Google autonomous drivers experts had to leave the company in order to get their work into a real live product.

[jimmywanger]

> Broad exposure helps too.

It seems as though you haven't really encountered Google process in person, you've just heard stories. Security people do have a day job, they just do security on the side because they've expressed interest/aptitude.

My point remains. I'd rather have a plumber fix my plumbing or check over plumbing designs rather than an enthusiastic amateur.

> Why? There's no rule that says that everyone needs to see the same UI in production.

They don't. Google constantly runs A/B testing. Once you get it to production you've already invested the time in productionizing it.

> It's telling that Google autonomous drivers experts had to leave the company in order to get their work into a real live product.

Or that it's be far more lucrative to be acquired than continue working on Google X. You can't ascribe motives to their actions.

[braveo]

> The review committee does this for hours a day, and they see far more cases. That's like saying that it's better for you to assess the condition of the transmission of your car, because you care more and are more invested. I'd rather have the guy who rebuilds transmissions for a living, who has seen dozens of transmissions, and is familiar with common failure modes and pitfalls.

That's a really bad analogy, borderline dishonest.

In this case it's a mechanic taking his vehicle to another mechanic for service, you better believe that first mechanic is both more invested and more familiar with the transmission.