By Colleen Frye, News Writer
01 Oct 2008 | SearchSoftwareQuality.com
Google's Darin Fisher, a software engineer on the Chrome project,
talks about how the Web browser was developed and tested. As you might
suspect, agility, speed, and testing were all critical.
Tell me about the development process you followed for Chrome?
Darin Fisher: 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?
Fisher:
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?
Fisher:
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 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?
Fisher:
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?
Fisher:
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?
Fisher: 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?
Fisher:
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?
Fisher: 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.