The irony is that this is still going on at Google, and presumably everywhere else in the industry as well. Some new strong-willed engineer joins, takes a look at the code, declares "This is amateurish. We should be doing so much better," and then gets a whole bunch of people to rewrite it, usually in a different language, with a different style of coding.

I'll credit this with a major shift in my thinking about what constitutes "good" programming. From the outside, I looked at Google and thought "wow, they're accomplishing amazing things, they must have amazing engineering practices". And yeah, things are pretty rigorous...but what I found was that the people who were, by and large, responsible for all those amazing things didn't care. Most of them had fairly loose preferences for favorite programming languages, and favorite development methodologies, and basically ignored the fad du jour. What they did have was an obsessive focus on the user, and on getting things done so they could move on to get other things done. Navel-gazing about what language was best or whether we should be using OOP or how stupid the previous engineers were was generally reserved for the B-players. The As were thinking about how we could return results as you type, or how we could process real-time microblog feeds, or how we could expose new and potentially groundbreaking new features without losing millions of dollars from UI tweaks.

Basically, the code quality of the initial version was "good enough", as was the code quality of every subsequent version of Google (except when it wasn't, which is when it got rewritten), and that's all that mattered. As long as you can do useful things for the user, it doesn't matter whether your coworker thinks you're a 1337 hacker.