Inside Google’s Code Culture: Unified Trunk, Feature Flags, and Strict Reviews

Collaboration and Division of Labor

At Google most product lines do not separate front‑end and back‑end engineers; a single developer often handles the full stack, although a few lines now list dedicated front‑end roles. Candidates are expected to know at least one of C++ or Java, which explains many internal workflow choices.

Code Management Practices

All source code is visible to every employee, and changes require peer review. Google primarily works on a single, continuously integrated trunk without traditional release branches or version numbers. New interfaces are added freely, but modifying existing ones demands notifying all consumers, which is easy because of the open code base.

Google maintains an internal code‑search engine that lets engineers locate usage examples quickly, reducing the need for separate documentation. Dependencies are managed globally in a way similar to Chromium’s GYP or npm, supporting multiple languages. Third‑party libraries are rarely used; instead, internal versions (e.g., a custom MySQL) are preferred, and any new external library undergoes a lengthy approval process.

The company uses Perforce for version control, with over 20 million changelists and a client handling millions of files. Review tooling is called Mondrian (the predecessor of Rietveld). Google reportedly bought Perforce and had a custom tool built for internal use. A 2011 performance‑optimization paper provides additional insight into these practices.

Feature Flags

Because there are no branches, new functionality is toggled via feature flags managed by the Borg system. Flags can target specific user cohorts for A/B testing. If a feature is abandoned, its code must be manually removed, and flag infrastructure can become a critical failure point.

Strict Code Checks

Engineers spend a large portion of time writing unit tests, which ensure UI‑independent code quality. Page‑level testing is limited, with Selenium rarely used. Submissions pass three mandatory stages: style checks (based on an internal style guide), unit‑test verification, and owner‑review. The process is highly disciplined because a faulty commit can affect many downstream projects.

Frontend Development Approach

Most Google front‑ends are generated from back‑end templates written in Java or C++. The open‑source Closure Templates and CTemplate are used for this purpose. Developers write both Java and JavaScript, while back‑end services are primarily C++ (with some Go adoption).

Google historically used GWT to generate cross‑browser JavaScript, valuing strong typing, IDE support, and early error detection. GWT has largely been superseded by Dart, which aims to replace it. The Closure library evolved from early Gmail code, growing from a few thousand lines in 2004 to hundreds of thousands of lines by 2007, with extensive comments and a built‑in compiler.

Internal Workflow

Project ideas originate from PMs or engineers, followed by UX mockups. Projects undergo a low‑success‑rate approval process before development begins. After implementation, a small‑scale online experiment runs, data is analyzed, and a second approval is required for full rollout. Most projects have long cycles (at least a quarter) and many never reach production; decisions are driven by data rather than individual authority.

A Day in the Life (Example)

Matt Welsh, a Chrome team engineer, illustrates a typical day: checking email, writing code, running unit tests, submitting changelists for review, switching between git branches for different projects, running a multi‑hour MapReduce job, attending video meetings across locations, analyzing experiment data, and taking short breaks. His schedule highlights the emphasis on code review, data analysis, and precise timeboxing.

Internal Tools

Google’s internal tooling includes Sites for intranet pages, Docs for collaborative design documents, a code‑review system (e.g., https://codereview.chromium.org/), Groups for discussions, an issue‑tracking system, Buildbots for continuous integration, and various quality‑checking utilities. These tools are often custom‑built versions of public products.

Takeaways for Other Teams

Key practices that can be adopted elsewhere are: making source code openly visible within the organization, enforcing strict coding standards and mandatory unit tests, integrating CI (e.g., Travis CI) for all projects, using code‑owner reviews, coupling documentation with code, and dog‑fooding internal versions of external products. Google’s static checking for GWT inspired the development of TypeScript, which is now considered for future adoption.