Tell me about
the development process you followed for Chrome?
Some might say certain elements seem like agile
programming, but we didn't specifically say let's use this methodology; we just said we'd do
what seems right.
My background is working on browsers; I had worked on Firefox. Aspects [of the process] derived
from what other Google teams do, like the policy of reviewing all patches before they're committed.
Also the approach of doing design documents for complex feature work; it's a great communications
tool and something Google does commonly. But by and large, we developed a lot of our own approach
to things. Google typically builds server applications or websites, so a Web browser is a different
beast. Was the development team distributed?
The new JavaScript engine [V8] was developed in Demark. There are some folks in other offices, but
[development] was largely centered here [in Mountain View, Calif.] for the browser. Did you
subdivide the development work?
We tried to not overly subdivide. For the core browser we wanted the approach that the engineers
should own the whole feature from top to bottom and be able to move around the project where they
were most interested in working. We had a flat structure, with subteam meetings. If what you were
working on aligned with that meeting, you could go. People
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
could self-select for things they were
interested in. We don't have layers of management at Google or on the Chrome project. It works
because people are keen to take on personal responsibility for the things they do.
 |
||||
|
|
|||
|
||||
How did the team determine which features to include?
When it came to requirements, a lot of the process involved brainstorming meetings with the team
and we talked about features. We also had an open mail list internally at Google where people said
what would be cool. Then a smaller team went through and generated a living document, a beta
roadmap, that said here's a set of features we know we've got to do. It included not only
requirements for the browser, but a few things that would make it a compelling beta product. We
tried to keep the features very focused and minimal. We're adverse to feature creep. Then we shared
the list with the whole team, and people would self-select for what they wanted to work on. Did you
set time frames or milestones?
We oriented things around quarters, so the living document was revised each quarter; say this
quarter we're focusing on this subset, etc. It was helpful to drive the product forward, and to
make sure the product very early on was usable by anybody at Google so we'd have continuous
feedback. They were getting a new build every week automatically. In the early days we may have
been missing features, but we had a browser users could use, which was essential to success. We had
a growing base of internal users, and as it became more feature rich we tried to maintain quality
and make sure it was always a stable, usable, dog-foodable product, which was a key element to our
methodology. How did the team go about testing Chrome?
We were very focused on automated
testing. The engineers write automated tests for all work. We have a variety of frameworks for
unit
testing; others are testing the whole systems and various things in between. The cool thing was
wide-scale testing. We'd take the build and run it against a large number of websites. Automated
test was essential to go fast. What does the new browser mean for Web application developers?
What's very important is we tried our best to not introduce a new rendering engine. We used WebKit
which is the same rendering engine inside Safari, so if you built Web applications with Safari they
will work in Chrome. We also wanted to make improvements, and we focused on performance. If you
could go faster, you can do more stuff. So for Web developers looking to find a faster JavaScript
engine, V8 is very impressive. The point of V8 is to show the great the potential in the space --
that JavaScript can be faster. So for Web app developers, if you have a faster JavaScript you could
depend on doing more in JavaScript, which is exciting to us because Google is building a lot of
applications. How did you address Web application security?
We have a security team at Google that's done a lot of work on Chrome. They use a host of scanning
tools, bug testers, etc. And Chrome has a sandbox technology to provide an extra layer of
protection. It was important that the sandbox was robust, so a lot of [Google] people focused on
trying to break out of the sandbox. There is way more to security than protecting against malware,
so we tried to do due diligence to exercise the product.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation