The GOOG-MSFT Exodus: Working at Google vs. Working at Microsoft

Well, that is kinda sorta the point he was making - it is a big company now.

So at what point would it be legit to form an opinion?

I also think that Dare is suffering from a bit of confirmation bias. Without mentioning the net exchange of people between Microsoft and Google, there is no way to gauge which company is "best" to work for. Dare only provides anecdotal evidence - "at least 8 people I know personally have rejoined".

Considering the possibility that most Microsofties have returned or will return to Microsoft is however still not proof that Microsoft is unconditionally better than Google (and vice-versa, if most ex-Microsofties stay at Google, we don't have unconditional proof that Google is better). Many Microsofties might have grown used to the MS environment and might - if only through force of habit - prefer the MS environment.

I'm not sure whether Dare wants to correct the perception that there is a debilitating exodus of people from MS to Google; I can understand such a motivation, since Yahoo's recent woes prove how a little bad news can cause massive demoralization. But still, I can't agree with his relaxed anecdotal method.

He addesses this very point in his post:

"As all organizations mature they tend to add PROCESS. These processes exist to insulate the companies from the mistakes that occur after a company gets to a certain size and can no longer trust its employees to always do the right thing. Requiring code reviews, design specifications, black box & whitebox & unit testing, usability studies, threat models, etc are all the kinds of overhead that differentiate a mature software development shop from a “fly by the seat of your pants” startup. However once you’ve been through enough fire drills, some of those processes don’t sound as bad as they once did. This is why senior developers value them while junior developers don’t since the latter haven’t been around the block enough."

Sounds to me like he thinks Google is in need of some "process" (in fact, he specifically uses random breakage in Google apps to illustrate why this might be so).

I'm not saying he's right (wouldn't know, I've always worked for small companies where there was little need for a lot of "process") but the argument he puts forth is that everything at Google is not, in fact, going fine.

I agree. To criticize Google still working like a start-up is a big complement.

Since most of Google's applications are web-based, releases can happen just about any time and can happen frequently as well. This is not the same thing as shipping code fast -- the delta between any two consecutive releases might be quite small, much smaller than what a startup might do in the same period of time.

Speaking as a newly-minted ex-Googler myself, I can say that for some projects, development is not what anyone would consider "fast".

Actually, Google does have one major challenge -- how to motivate its people. I'm not talking about fresh college graduates, but rather people who are high up in the organization because they happened to join early on. Many of these people are worth a lot of money, and presumably see day to day work at Google as a way to spend their time, socialize, and to flex their political muscle.

In such a place, bringing in new hungry blood is very difficult to do, especially since the old crowd will try very hard to protect their power structure. In the long term, this does cause problems in the ranks, since success within the company starts to become a measure of how well you can navigate politically, vs. the quality of work produced.

So you think Google ships code fast? How do you know?

There are a lot of services Google tries to build that never see the light of day. And there are yet others that took a year or more to be released even as beta. There are some projects that seem to have gone from concept to launch in a few months, but I'd say those are usually the exception.

Also: there is a lot of necessary process that comes with launching a Google service. Version 0.1 for a startup can be buggy, embarassing, ugly, contain security bugs, or be non-scalable. In fact, you might go all the way to acquisition and still have all these problems. Pretty much anything on *.google.com has to be ready for Digg on day one.

I will say that there are many teams at Google that deliver quality, polished software faster than almost any other company. But that's more like winning marathons rather than sprints.