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.
That's not how I read the article. It sounded like Page's original version didn't work so he hired an RA to fix it. The RA spent more time debugging the (then very immature) Java than he did debugging Page's code so he rewrote it in Python.
Once they started getting traffic, the Python script that the RA had written couldn't stand up anymore, so they hired engineers to fix it again, who did so by rewriting it in C++.
Page's choice of Java originally was probably a faddish choice, given that Java was being hyped into the stratosphere by Sun at the time, even though neither the language nor its implementation were ready for prime time. The RA's choice of python was more reasonable, but Python was a highly esoteric research language at the point and did not have the ecosystem around it yet for writing scalable production code.
What they did have was an obsessive focus on the user
I'm surprised to read this. Google's products never seem to me to be the result of an obsessive focus on the user. Rather they seem to be the by-product of an elegant engineering concept, with the interface something of an afterthought.
I disagree. Google gained popularity not just for search results, but because their clean search page was a breath of fresh air compared to the busy portal sites of the day. Gmail became popular because its UI was so much more refined than the other email sites of the day. Likewise for Google Calendar.
I think they've taken people's attention seriously from day one.
I started using Google in 2001, after seeing it on the screen of another computer in an Internet Cafe. I was trying to search something, and Altavista was returning shit filled with all kinds of commercials.
Opened Google, typed my search query in that lovely text input, hit Enter, and WOW, the first 10 results were all relevant. And no commercials. I was so impressed that I instantly switched.
Even when they added commercials, they were marked as such, while being clean and non-intrusive (well, that changed in the meantime -- I find their search page a little cluttered with commercials nowadays).
Good UI design is invisible - if your UX designer is doing their job, you will never even think about them. For things like Search, GMail, and Maps, the user need's definitely come first, and then the elegant engineering is a byproduct as people try to figure how the hell to implement the product they have in mind.
The notable flops have been the ones that have been driven by an elegant engineering concept; in particular, one of the major differences between Wave and GMail is that Wave seemed to ask "What can we do, and how should we expose that to the user?" while GMail (pre-Labs) largely asked "What should we do, and how can we figure out how to implement that?"
> if your UX designer is doing their job, you will never even think about them.
UX is not something you can stitch on afterwards. Good UX is deeply ingrained in engineering and an omnipresent, pervasive focus of the team. I think that's what parent is referring to in regards to what Google is lacking.
That depends on the product. A 50/50 UX back end split is fairly common. But, some products need a simple interface and a ridiculously complex back end. EX: Weather map's.
A big part of it is that the page loads FFFFFAST. They never went for clutter. They engineered the pages, so you can do what you want to do quickly. Do not underestimate the importance Google places on page-load times.
They don't consistently fix it if it's slow, though. It takes about four seconds to search for a term you haven't previously searched for in Gmail (which I think requires having 10k+ emails, but I'm not sure), and it has for a long time.
I haven't heard many people express dismay or annoyance with the UX in their software. Certainly their software doesn't "look" great and I think that's what a lot of people are referring to when they talk about Google's terrible UIs.
But the fact is, most of the UIs do what you expect and get out of the way without making a bug fuss.
It's not just how it looks. To pick on my favorite tool, Google AdWords: you select a campaign, then you select the keyword tab, then you click on "add keywords", then it asks you which campaign you want to select... Didn't I just tell you that 3 clicks ago? Why do I have a choice again? That's an example of poor UX design.
The irony is that this is still going on at Google, and presumably everywhere else in the industry as well.
The article describes how Google constantly improved and rewrote their codebase to make it better. I wish this was going on everywhere else in the industry. Unfortunately, in many cases the very first version of some application is deemed perfect, so no one is allowed to replace it, until it's too late.
Love it, I never went to school for cs, founded a company that did very well, and reached a point where I needed to move on. I was the chief geek, so the board wanted to replace me with someone credentialed, and all I heard from him during my transition was what a mess everything was. Not long after leaving they lost what I considered to be the best coders, because it is fun to code something up and deploy it, everything else can be labeled as work too easily.
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.