The People’s Republic of Google
cringely.com
cringely.com
That said, the article is right about the importance of peer review at Google, although the headline is typical journalistic bait. Google's culture isn't so much engineering as it is science. Business is understood as an ongoing experiment. Opinions are worthless, only data counts.
The results are stunning and many cowboy developers have become converts. There are many parts of Google's codebase that are so beautiful they almost brought tears to my eyes. You don't know what it's like to see megabyte after megabyte of source code scroll by, and you can't tell who wrote it. The same conventions are used everywhere, "tricky" parts are at an absolute minimum, and good documentation is usually a given.
If there's one thing about Google culture that is worth preserving in all the startups now budding off, it's the peer review.
Now in all fairness, the JsDoc comments were used to pass type annotations to the JavaScript compiler/compressor/obfuscator. But still, what the hell is the point of not just writing useless comments, but writing them twice? Not to mention the fact that accessor functions aren't all that useful in JavaScript, and they're especially not useful for objects that are just a big bag of properties.
However, internally, at least at my project, they liked GWT because they thought it would liberate them from Javascript. Slightly different focus there.
Sounds like they have an inefficient meat-machine based code generator. Why not just use their considerable resources and automate that process?
I disagree with this statement. I think having uniformly good code is, indeed, a good thing. On the other hand, I don't believe that means you should take it so far that you can't tell who wrote the code. Good developers can, in fact, differ about how to write good code.
In fact my major general purpose complaint about Google is that they'd take a good idea and then take it way too far.
if () {
}
if ()
{Or "I know that so-and-so wrote this piece of code because there are goto's everywhere since he started off as a ASM programmer that eventually became a C programmer."
I've maintained a codebase that started in '89, and I'll tell you that there were some messy things in the code and lots of it was unmaintainable (well, 'maintenance' requires either 'major rewrite' or 'dirty dirty dirty hack'). I could go into code and see 3-4 different ways of accessing the database used within the same program. This is the kind of stuff that I'm assuming he's talking about. I've seen code where there are 'layers' like some sort of core-sample that allow you to tell when/who modified the code and what 'era' it was modified in.
But the point is, I could read through it almost at the same speed I could read my own code from a few months ago.
And, when I was modifying someone else's code, I didn't have to make any hard decisions. For example, if my predecessor had named functions inconsistently, I could make some lame attempt to follow what had been done, or try to carve out a chunk of code done "my" way. But at Google I never had that problem. And that's why people at Google can modify each other's codebases all the time.
Google is not an advertising company any more than NBC is an advertising company. The reason Google makes so much money comes down to the fact that they have built the (perceived) best and cleanest search product on the internet. A lot of that probably has to do with writing great peer-reviewed code.
Just because these engineers don't know what other responsibilities were being handled does not mean there were none.
BTW the reason Google's products are in perpetual beta is because they do not plan to charge the end user ever so they do not need a release version and they have figured out that if they keep saying their product is in beta, they do not have to do annoying things like providing customer service.
I've got a chip on my shoulder because we severely disappointed customers by shipping a product that lacked tons of features that marketing had hyped up beforehand. Most of their ideas to win back customers were good in spirit but were bogged down by banal details and deceitful trial terms / payment rules. I fully accept the idea that this is just an example of terrible marketing and not representative of marketing as a whole, but I haven't got a personal experience of marketing being a huge boon.
I can't say I'm a good example because the end users of my code are company employees, I make internal tools, but even then we try to set our own deadlines and keep them with no external dictation of when stuff must be done.