[A transcript of the SIGCSE 2008 conference: Table of Contents]
The second day of the conference opened with the keynote
address by Google's VP of Search Products and User
Experience, Marissa Mayer. She was one of the early
hires as the company expanded beyond the founders, and
from her talk it's clear that she has been involved with
a lot of different products in her time there. She is
also something the discipline of computer science could
use more of, a young woman in a highly-visible technical
and leadership and roles. Mayer is a great ambassador
for CS as it seeks to expand the number of female
high-school and college students.
This talk was called
Innovation, Design, and Simplicity at Google
and illustrated some of the ways that Google encourages
creativity in its employees and gets leverage from their
ideas and energy. I'll drop some of her themes into this
report, though I imagine that the stories I relate in
between may not always sync up. Such is the price of
a fast-moving talk and five days of receding memory.
Creativity loves constraint.
I have written on this topic a few times, notably in the
context of patterns,
and it is a mantra for Google, whose home page remains
among the least adorned on the web. Mayer said that she
likes to protect its minimalist feel even when others
would like to jazz it up. The constraints of a simple
page force the company to be more creative in how it
presents results. I suspect it also played a role in
Google developing its cute practice of customizing the
company logo in honor of holidays and other special
events. Mayer said that minimalism may be a guide now,
but it was not necessarily a reason for simplicity in
the beginning. Co-founder Sergey Brin created the first
Google home page, and he famously said, "I don't do HTML."
Mayer has a strong background both in CS and in CS
education, having worked with the undergrad education
folks at Stanford as a TA while an undergrad. (She said
that it was Eric Roberts who first recommended Google
to her, though at the time he could not remember the
company's name!) One of her first acts as an employee
was to run a user study on doing search from the Google
homepage. She said that when users first sat down and
brought up the page, they just sat there. And sat there.
They were "waiting for the rest of it"! Already, users
of the web were already accustomed to fancy pages and
lots of graphics and text. She said Google added its
copyright tag line at the bottom of the page to serve
as punctutation, to tell the user that that's all there
was.
Search is a fixed focus at Google, not a fancy user
interface. Having a simple UI helps to harness the
company's creativity.
Work on big problems, things users do every day.
Work on things that are easy to explain and understand.
Mayer described in some detail the path that a user's
query follows from her browser to Google and back again
with search results. Much of that story was as expected,
though I was surprised by the fact that there are load
balancers to balance the load on the load balancers that
hand off queries to processors! Though I might have
thought that another level of indirection would slow the
process it down, indeed it is necessary in order to ensure
that the system doesn't slow down. Even with the web
server and the ad server and the mixers, users generally
see their results in about 0.2 seconds. How is that for
a real-time constraint to encourage technical creativity?
Search is the #2 task performed on the web. E-mail is
(still) #1. Though some talking heads have begun to
say that search is a mature business in need of
consolidation, Google believes that search is just getting
started. We know so little about how to do it well, how
to meet the user's needs, and how to uncover untapped
needs. Mayer mentioned a problem familiar to this old
AI guy: determining the meaning of the words
used in a query so that they can serve pages that match
the user's conceptual intent. She used a nice example
that I'll probably borrow the next time I teach AI. When
a user asks for an "overhead view", he almost always
wants to see a picture!
This points in the direction of another open research
area, universal search. The age in which users want to
search for text pages, images, videos, etc., as separate
entities has likely passed. That partitioning is a
technical issue, not a user's issue. The search companies
will have to find a way to mix in links to all kinds of
media when they serve results. For Google, this also
means figuring out how to maintain or boost ad revenue
when doing so.
Ideas come from everywhere.
Mayer gave a few examples. One possible source is office
hours, which are usually thought of as an academic
concept but which she has found useful in the corporate
world. She said that the idea for Froogle walked through
her office door one day with the scientist who had it.
Another source is experiments. Mayer told a longer story
about Gmail. The company was testing it in-house and
began to discuss how they could make many from it. She
suggested the industry-standard model of giving a small
amount of storage for free and then charging for more.
This might well have worked, because Google's cost
structure would allow it to offer much larger amounts
at both pricing levels. But a guy named Paul -- he may
be famous, but I don't know his last name -- suggested
advertising. Mayer pulled back much as she expected
users to do; do people really want Google to read their
e-mail and serve ads? Won't that creep them out?
She left the office late that night believing that the
discussion was on hold. She came back to work the next
morning to find that Paul had implemented an experimental
version in a few hours. She was skeptical, but the idea
won her over when the system began to serve ads that
were perfectly on-spot. Some folks still prefer to read
e-mail without ads, but the history of Gmail has shown
just how successful the ad model can be.
The insight here goes beyond e-mail. The search ad data
base can be used on any paged on the
web. This is huge... Search pages account for about
5% of the pages served on the web. Now Google knew that
they could reach the other 95%. How's that for a business
model?
To me, the intellectual lesson is this:
If you have an idea, try it out.
This is a power that computer programmers have. It is
one of the reasons that I want everyone to be able to
program, if only a little bit. If you have an idea, you
ought to be able to try it out.
Not every idea will lead to a Google, but you never
know which ones will.
Google Books started as a simple idea, too. A person,
a scanner, and a book. Oh, and a metronome -- Mayer
said that when she was scanning pages she would get out
of rhythm with the scanner and end up photocopying her
thumbs. Adding a metronome to the system smoothed the
process out.
... "You're smart. We're hiring." worked remarkably
well attracting job candidates. We programmers have
big egos! Google is one of the companies that has
made it okay again to talk about hiring smart people,
not just an army of competent folks armed with a
software development process, and giving them the
resources they need to do big things.
Innovation, not instant perfection.
Google is also famous for not buying into the hype of
agile software development. But that doesn't mean that
Google doesn't encourage a lot of agile practices. For
example, at the product level, it has long practiced a
"start simple, then grow" philosophy.
Mayer contrasted two kinds of programmers, castle builders
and nightly builders. Companies are like that, too.
Apple -- at least to outside appearances -- is a
castle-building company. Every once in a while, Steve
Jobs et al. go off for a few years, and then come back
with an
iPod
or an iPhone. This is great if you can do it, but only
a few companies can make it work. Google is more of a
nightly builder. Mayer offered Google News as a prime
example -- it went through 64 iterations before it
reached its current state. Building nightly and
learning from each iteration is often a safer approach,
and even companies that are "only good" can make it work.
Sometimes, great companies are the result.
Data is a-political.
Mayer didn't mean Republican versus Democrat here, rather
that well-collected data provide a more objective basis
for making decisions than the preferences of a manager
or the guesses of a designer or programmer. Designing an
experiment that will distinguish the characteristics you
are in interested, running it, and analyzing the data
dispassionately are a reliable way to make good decisions.
Especially when a leader's intuition is wrong, such as
Mayer's was on Gmail advertising.
She gave a small plug for using Google Trends as a way
to observe patterns in search behavior when they might
give an idea about a question of interest. Query volume
may not not change much, but the content of the queries
does.
Users, users, users.
What if some users want more than the minimalist white
front page offered by Google? In response to requests
from a relatively small minority of users -- and the
insistent voices of a few Google designers -- iGoogle
is an experiment in offering a more feature-filled
portal experience. How well will it play? As is often
the case, the data will tell the story.
Give license to dream.
Mayer spent some time talking about the fruits of
Google's well-known policy of 20% Time, whereby every
employee is expected to spend 1/5 of his or her time
working on projects of personal interest. While
Google is most famous for this policy these days, like
most other ideas it isn't new. At ChiliPLoP this week,
Richard Gabriel reported that Eric Schmidt took this
idea to Google with him when he left Sun, and Pam Rostal
reported that 3M had a similar policy many years ago.
But Google has rightly earned its reputation for the
fruits of 20% Time. Google News. Google Scholar.
Google Alerts. Orkut. Froogle Wireless. Much of
Google Labs. Mayer said that 50% of Google's new
products come from these projects, which sounds like
a big gain in productivity, not the loss of
productivity that skeptics expect.
I have to think that the success Google has had with
this policy is tied pretty strongly with the quality
of its employees, though. This is not meant to diss
the rest of us regular guys, but you have to have good
ideas and the talent to carry them out in order for this
to work well. That said, these projects all resulted
from the passions of individual developers, and we
all have passions. We just need the confidence to
believe in our passions, and a willingness to do the
work necessary to implement them.
Most of the rest of Mayer's talk was a litany of these
projects, which one wag in the audience called a long
ad for the goodness of Google. I wasn't so cynical,
but I did eventually tire of the list. One fact that
stuck with me was the description of just how physical
the bits of Google Earth are. She described how each
image of the Earth's surface needs to be photographed
at three or four different elevations, which requires
three or four planes passing over every region. Then
there are the cars driving around taking surface-level
shots, and cameras mounted to take fixed-location shots.
A lot of physical equipment is at work -- and a lot of
money.
Share the data.
This was the last thematic slogan Mayer showed, though
based on the rest of the talk I might rephrase it as
the less pithy "Share everything you can, especially
the data." Much of Google's success seems based in a
pervasive corporate culture of sharing. This extends
beyond data to ideas. It also extends beyond Google
campus walls to include users.
The data-sharing talk led Mayer to an Easter Egg she
could leave us. If you check Google's
Language Tools
page, you will see Bork, Bork, Bork, a language spoken
(only?) by the Swedish chef on the Muppets. Nonetheless,
the Bork, Bork, Bork page gets a million hits a year
(or was it a day?). Google programmers aren't the only
ones having fun, I guess.
Mayer closed with suggestions for computer science
educators. How might we prepare students better to
work in the current world of computing? Most of her
recommendations are things we have heard before:
build and use applications, work on large projects
and in teams, work with legacy code, understand and
test at a large scale, and finally pay more attention
to reliability and robustness. Two of her suggestions,
though, are ones we don't hear as often and link back
to key points in her talk: work with and understand
messy data, and understand how to
use statistics to analyze the data
you collect.
After the talk, folks in the audience asked a few
questions. One asked how Google conducts user studies.
Mayer described how they can analyze data of live users
by modding the key in user cookies to select 1/10 or
1/1000 of the user population, give those users a
different experience, and then look at characteristics
such as click rate and time spent on page by these
users compared to the control group.
The best question was in fact a suggestion for Google.
Throughout her talk, Mayer referred repeatedly to
"Google engineers", the folks who come up with neat
ideas, implement them in code, test them, and then
play a big role in selling them to the public. The
questioner pointed out that most of those "engineers"
are graduates of computer science programs,
including herself, Sergey Brin, and Larry Page. He
then offered that Google could do a lot to improve the
public perception of our discipline if it referred to
its employees as computer scientists.
I think this suggestion caught Mayer a little off-guard,
which surprised me. But I hope that she and the rest
of Google's leadership will take it to heart. In a time
when it is true both that we need more computer science
students and that public perception of CS as a discipline
is down, we should be trumpeting the very cool stuff that
computer scientists are doing at places like
Google.
All in all, I enjoyed Mayer's talk quite a bit. We should
try to create a similarly creativity-friendly environment
for our students and ourselves. (And maybe work at a place
like Google every so often!)
-----