1

Lessons from Software

Engineering at Google
Lawrence Shin | CST438 Software Engineering | May 28, 2021

Introduction

With the advent of CST438 Software Engineering, I was given the opportunity to gain
perspective in the latter through the supplemental reading of Software Engineering at Google, by
Manshreck, Wright, and Winters. Published in 2020, this brief book serves as treatise of
strategic software engineering topics narrated by various Google contributors. The topic of this
report, then, is a summary of relevant findings that should be of interest to the following: new
and experienced software developers in all industries, computer science students, and anybody
who has interest in the topic of software engineering.

A plethora of anecdotal content for topics related to software engineering is readily available on
the web. Why is a book about software engineering at Google potentially be considered more
relevant over another resource? From a credibility perspective: Google’s parent company,
Alphabet, is one of the largest in the world, with a current 2.5 trillion dollar market cap (June
2020). This value represents the scale of innovative, software-related technologies Google has
built and maintained since its origin as a search engine company. It is well-established that in
addition to market leadership, Google is also a leader in organizational development, marketing
technology, product development, machine learning, cloud computing, and more. Google’s
influence on the engineering job market has been so impactful, their engineering talent
acquisition methods have been adopted throughout various industries. Empirical evidence
supports the hypothesis that Google, given its spectacular growth and resources, can provide
valuable software engineering strategies for anybody interested in the topic. This passage in the
forward best summarizes this rationale: “If you aren’t familiar with the practices Google has
developed, you’re missing a perspective on software engineering that comes from tens of

Lawrence Shin
Lessons from Software Engineering at Google 2

thousands of engineers working collaboratively on software over the course of more than two
decades. That knowledge is far too valuable to ignore.”

This report asserts specific relevance based on my experience as a Computer Science

undergraduate learning about software engineering. Select, weekly readings from Software
Engineering at Google paired with the learning and application of critical ideas in software
engineering have validated the contextual relevance of this book as an asset.

Topics

This report will present a curation of important learnings under the following topics.

• General Software Engineering

• Code Reviews
• Testing

Summary

In this informal technical report, I present a selection of topics from Software Engineering at
Google that met the following criteria: validated as relevant to general software engineering
principles learned in CST438 and part of Google’s framework. Content that was specific to only
Google was filtered out. These topics are: General Software Engineering, Code Reviews, and
Testing.

Findings are explored in greater detail in the Discussion section of the report:

• Programming vs. Software Engineering.

• Time, scale, and trade-offs.
• The code review workflow at Google.
• The impact of brittle tests.
• Three primary methods of implementing test doubles.
• Unit testing best practices.

Lawrence Shin
Lessons from Software Engineering at Google 3

Discussion

General Software Engineering

“What is Software Engineering” was the title of the opening chapter of Software Engineering at
Google, as well as the first question asked in CST438. The significance of this question can be
framed by considering the difference from programming. The book references three distinctions
between software engineering and programming: time, scale, and trade-offs.

Programming can be viewed as an immediate activity, with little to no commitment to time.

Longer term commitment with programming dependencies requires more layers of support,
hence the definition “Software engineering is programming integrated over time.”

Scale considers change and sustainability. This concept relates to all the dependencies necessary
for scale. For example, if a codebase were to grow, does the organization have the human
resources, architecture, and policies that can scale? This can be described as a system. For a
system to be scalable and sustainable, it must have scalable resources and policies.

Trade-offs are presented as impact and associated costs of decisions related to software
engineering. Important costs to factor are:

• Financial costs (e.g. money)

• Resource costs (e.g. CPU time)
• Personnel costs (e.g. engineering effort)
• Transaction costs (e.g. cost of action)
• Opportunity costs (e.g. cost of inaction)
• Societal costs (e.g. what is societal impact?)

Code Reviews

The code review process at Google usually follows this flow, prior to the acceptance of a
commit.

Lawrence Shin
Lessons from Software Engineering at Google 4

1. An “author” makes a change in their local workspace, followed by a creating a snapshot

of the change via patch, with a description of what is changed. This change is referred to
as a “diff”.
2. The author can self-review the patch and send other reviewers the patch for evaluation.
3. Reviewers evaluate the diff and add comments that resolve or require additional
resolution.
4. The author may modify changes as necessary and continue to send new snapshots for
review.
5. If reviewers fully accept changes in a snapshot, they communicate acceptance with
“looks good to me” (LGTM).
6. The author can commit the change to the codebase if all comments are resolved, and the
change has been approved.

Three aspects are considered for an approval for changes at Google:

• Correctness, comprehension, and consistency.

• Approval from specific “code owners”.
• Approval from language specialist.

Four general types of code reviews are:

• Greenfield reviews: this is potentially new feature development or brand new code.
• Behavioral changes, improvements, and optimizations: modifications to existing code.
• Bug Fixes and rollbacks: a change that resolves an issue, which requires additional
testing. If new tests expose new issues, then a rollback can designate changes to be revert
to a previous state before the change.
• Refactorings and large-scale changes: these are changes which have greater scope and
risk, therefore require a greater review process.

Testing

Brittle tests are tests that are written in a way that may negatively resist change. As a result,
these tests can potentially fail given changes to production that do not introduce any bugs. Such
tests require refactoring to keep up with changes, which prevents automation and scalability. It

Lawrence Shin
Lessons from Software Engineering at Google 5

also violates another concept at Google, that tests should be unchanging. Google encourages
developers to optimize tests whenever possible by making them less brittle.

While a real implementation is preferable during testing, in the absence of the implementation it
may be necessary to substitute a solution, or a “test double”. Test doubles can be implemented
in variety of ways. Three primary techniques are:

• Faking: implementation of an API that behaves similarly to the real implementation.

• Stubbing: implementing functions that return dummy values with the help of mocking
frameworks.
• Interaction testing: testing the function’s validity without calling the function, with the
help of mocking frameworks.

Unit testing is defined by the following attributes:

• Small: narrow scope, usually limited to a single class or method.

• 80% of the test suite should consist of unit tests.
• Should test behaviors (outcomes), not methods.
• Tests should not contain logic or complexity.

Conclusion

Key Takeaways

Software engineering is programming integrated over time, with respect to scale/sustainability

and trade-offs.

Unit tests should make up most of a test suite (~80%) and can potentially cause friction/limit
scalability if not optimized. To mitigate this risk, unit tests should be narrow in scope, test for
behaviors over methods, avoid logic/complexity, and brittleness.

The selection of content presented from Software Engineering at Google is based on outstanding
relevance to corresponding learnings from CST438. Careful consideration was taken in filtering
out content that skewed towards being too Google specific. The result is a list of software

Lawrence Shin
Lessons from Software Engineering at Google 6

engineering best practices that are already established outside of Google, with additional insight
and methodology exercised in Google. I believe that makes this list highly compatible with
general software engineering practitioners.

Recommendations

However relevant or correct the information presented in this report may seem, it is
recommended that readers approach all findings as anecdotal. A contributor states: “Applied
practically, this book will give you ideas on how things could be done, and a lot of information
that you can use to bolster your arguments for adopting best practices like testing, knowledge
sharing, and building collaborative teams.” Consider that my summary of findings is a curation
of what I believe to be the most important lessons from the book. This presents a biased
selection process for what information was included, and how it was presented. Also consider
that during the curation process, topic content that was too unique and specific to Google was
excluded. In light of such considerations, If the ideas presented resonate strongly with the
reader, then I recommend that the reader to go and read the source material.

Lawrence Shin