| > 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? |
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.