Browse the Knowledge Hub211 resources
Software Engineering at Google: is it worth reading?
How engineering practice changes when code must survive for decades, with three substantial chapters on testing.
We earn nothing from any link on this page. No affiliate links anywhere in this library.
- published
- 2020
- key ideas
- 3
Software Engineering at Google
Lessons Learned from Programming Over Time
by Titus Winters, Tom Manshreck, Hyrum Wright
- Publisher
- O'Reilly
- Year
- 2020
- ISBN
- 9781492082798
Useful when you are: Senior / lead
Verdict
Should you read it?
Read it if
You work on long-lived systems, or you want the most rigorous available treatment of testing economics at scale.
Skip it if
You are at a startup optimising for the next six months. Much of the book is explicitly about problems that only appear at scale and over time.
The argument
What it argues
The organising idea is that software engineering is programming integrated over time. A decision that is fine for code living a month is often wrong for code living a decade, and most engineering practice exists to manage that difference.
The testing chapters are the most valuable part for this audience. They cover the small-medium-large taxonomy, why test size matters more than the unit-integration distinction, the economics of testing at scale, and a frank treatment of how Google handles flaky tests at a volume where manual triage is impossible.
The chapter on deprecation and large-scale change is also quietly relevant, since it explains why comprehensive automated testing is what makes refactoring a codebase of that size possible at all.
Key ideas
Ideas worth taking from it
- 01
Programming integrated over time
The distinction between writing code and engineering it. Nearly every practice difference follows from expected lifespan.
- 02
Test size over test scope
Classifying tests by the resources they may access, small meaning single process and no network, rather than by what they conceptually cover. More actionable in practice.
- 03
Hyrum's law
With enough users, every observable behaviour of your system will be depended on by somebody, regardless of what you documented. A sobering argument for testing behaviour rather than contract.
Criticism
What has dated, and what it gets wrong
Google-specific in ways the authors do not always flag, and some practices assume infrastructure that essentially no other organisation has. Like How Google Tests Software, it is frequently over-applied by readers who skip the part about what it costs.
Keep reading
What to read next
Reads well with
Reading about quality is cheaper than learning it in production.
QAble runs QA for products in BFSI, gaming, healthcare and SaaS, with engineers who have read these and argued about them. Start with a free QA audit.