From my brief foray at Google, I can say that the code review process can be used to ruthlessly enforce orthodoxy. I would not say that this results in "clean code" as I would use the term. On the other hand the JavaScript code I saw was very, very uniform. It was also a bloated pig in my professional estimation. The JavaScript project I worked on had something like 15k lines of code and I rewrote maybe half of it (most of the UI) in 1200-1500 lines of code, and I still think I could have done the whole thing in around 3000. That particular 20 percent project didn't win me any friends it seems, or even convince anybody that I knew what I was doing.
When I was there (2005-2006, so, ancient history maybe), Google had a cultural problem with languages like Javascript. All their coding standards were developed for languages like C++ and Java and the typical Google engineer had the most experience in such languages. Projects that promised to relieve the programmer from having to write in nasty Javascript (such as GWT) had a lot of support. There are islands of Javascripters in Google, but many of them are working on the browser initiatives.
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.
> 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.
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.
I think the point was that you can't say "Oh! So-and-so wrote this section, because all of the code blocks are like:
if () {
}
instead of
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.
That may be what neilk meant, I can't say. It's not what I meant. Even given the same style guide, you could probably tell the difference between my code and someone else's because I tend to write shorter functions, longer function names, and I use temporaries aggressively, especially to avoid linebreaks at inconvenient spots. I also write a lot of one or two-line block comments.
I partially agree with you that authorship is still visible, even when writing to a very strict coding standard. I'm thinking of a colleague who wrote a little mini-templating system to solve a particular issue. That style of solution was very characteristic of him.
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.
Both this and the parent (and even the OP, controlling for Cringely) give a fascinating perspective on Google's culture of peer review. Just out of curiosity, can you give some examples of how coding standards developed for C++ and Java wouldn't translate well to JS? (I'm a little surprised to hear about an anti-JS bias there, actually, though it does explain GWT.)
A classic case I can think of involved a JavaScript class (or "class" for the purists out there) that was just used for data interchange. Basically it was just a collection of properties. However, for each property "foo", there was a trivial accessor method called "getFoo()". And because the coding standards said that everything must be JsDoc'd (JavaDoc for JavaScript, basically), the property initialization in the constructor had a JsDoc comment, something to the effect of "This is the Foo.". Then the accessor function, getFoo() had a JsDoc comment to the effect "Gets the Foo".
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.
Well, to be fair to GWT -- I know the guys who developed GWT, and they are really smart people who just didn't like having the client/server language distinction, and who believed that type-unsafe languages suck for programming, and who wanted to use Java IDE tools to debug client-side issues, etc. etc. They were and are very smart JS developers, for obvious reasons -- they write the infrastructure that supports GWT in raw JS, at least initially.
However, internally, at least at my project, they liked GWT because they thought it would liberate them from Javascript. Slightly different focus there.
Here is the most commonly accepted coding standard for JavaScript.
http://javascript.crockford.com/code.html
If you're familiar with C++ and Java coding standards you can see the JS one is substantially different.
While working as a software consultant for the federal government here in DC, I noticed something very strange ... consulting firms don't have any idea what Peer Review is. Actually, they don't even care, all they want to do is complete a project with as little money, and as fast as possible so they can move onto the next contract while billing the government millions.
The fact that it works so well (makes so much money) comes down to the realization I had that Google isn’t a software company at all. It’s an advertising company.
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.
Maybe "advertising" is the wrong, but both Google and NBC are in the business of selling eyeballs to companies selling products. They choose different media, and one can't really call a TV network cool, but it's the same revenue stream(s).
Oh no! No marketing! Communism! It must be stopped! Shudder.
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.
My manager at Google probably had about 15 direct reports while I was there. But he also had 4 or 5 dev leads working for him. I tended to think of him as my second-level manager, although in hind-sight, that was probably a mistake, since I don't think he saw it that way.
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.
