Fundamentals 46 min read

Overview of Google’s Software Engineering Practices

Google’s software engineering practices—including a unified source repository, Blaze build system, rigorous code review, automated testing, continuous integration, and structured project and personnel management—are detailed, offering insights and comparisons for other organizations seeking to adopt similar high‑scale development methodologies.

Continuous Delivery 2.0
Continuous Delivery 2.0
Continuous Delivery 2.0
Overview of Google’s Software Engineering Practices

This article translates and condenses the key software engineering practices described in the paper "Software Engineering at Google" (https://arxiv.org/abs/1702.01715). It adds explanations about the corresponding chapters in the SE@G book, related open‑source projects, and notes on the author’s disagreement with some of Google’s cultural viewpoints.

Source Repository – Most of Google’s code lives in a single, massive repository (86 TB, ~1 billion files, 2 billion lines of code as of Jan 2015). All engineers can read any part, while write access is controlled by directory owners via OWNERS files. Development occurs on the main branch (trunk) to reduce merge conflicts, and presubmit tests run automatically on changed files.

Build System – Google uses Blaze (open‑sourced as Bazel) for distributed builds. BUILD files declaratively describe targets, dependencies, and compilation rules. The system is hermetic, deterministic, and caches results in the cloud, enabling fast incremental builds across thousands of machines.

Code Review – A web‑based review tool integrates with email, requiring at least one reviewer and an owner for each change. Automated suggestions help pick reviewers. Large changes are split into smaller CLs, and review size is highlighted (e.g., “large (300‑999 lines)”).

Testing – Unit, integration, and regression tests are mandatory; presubmit runs tests before code lands. Coverage tools (e.g., Zapfhahn) report results in the code‑review UI. Load testing and post‑submit dashboards monitor performance.

Defect Management – Google tracks bugs, features, and processes in Buganizer, linking issues to CLs. Triage is performed regularly, and many teams use custom tools built on top of Buganizer.

Project Management – Engineers can spend up to 20 % of their time on any project (the “20 % time” policy). OKRs (Objectives and Key Results) are set quarterly and scored publicly. Hackathons and annual reorgs encourage innovation and mobility.

Personnel Management – Roles include Software Engineer, Engineering Manager, Tech Lead, Research Scientist, SRE, Product Manager, and Project Manager. Career ladders are separate for technical and managerial tracks, with clear promotion processes and peer‑based feedback (peer bonuses, kudos).

Configuration Example

rule_set {
  static_analyzer {
    test_coverage {
      changelist_threshold:40
    }
  }
}

The article concludes that while Google’s success stems from many factors, its engineering practices have stood the test of time and provide a valuable reference for other organizations seeking to improve their software development processes.

software engineeringCode ReviewContinuous IntegrationGooglelarge-scale systemsbuild systems
Continuous Delivery 2.0
Written by

Continuous Delivery 2.0

Tech and case studies on organizational management, team management, and engineering efficiency

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.