REVIEW - Software Engineering at Google - Lessons Learned from Programming Over Time


Title:

Software Engineering at Google

Lessons Learned from Programming Over Time

Author:

Titus Winters, Tom Manshreck, Hyrum Wright

Publisher:

O'Reilly Media (2020)

Pages:

602

Reviewer:

Paul Floyd

Reviewed:

March 2023

Rating:

★★★☆☆


Verdict: Recommended with reservations

Before reading this book, I expected several things:

  1. Fascinating nuggets about how Google solves problems at a large scale
  2. A minor buzzword overdose (and in particular, ‘subtle’)
  3. A degree of excessive certainty about the Google way being the way.

There are 25 chapters, mostly written by different people. Whilst the style does vary it still stays fairly coherent.

Just about everything about software engineering at Goggle gets covered. The first few chapters are introductory, then there are a few of chapters on management. That leaves a large part of the book that covers code, building, testing, changes and documentation.

Not too much is only applicable to Google, so most people and companies should benefit. Chapter 3 on Knowledge Sharing does describe internal Google collaboration tools at length, but even still the ideas should be fairly portable. A few of the chapters are only applicable to very large scale projects. I also found a few of the chapters were a bit overly Java-centric and could have done with a bit more coverage of other programming languages and toolkits. Particularly Chapter 18 on build systems could have done with more coverage of Make-style building or C/C++/Rust style applications.

I found the chapters on code search and deprecation very interesting. I’m not going to write a code search tool, but the sheer size of the Google code base makes the need obvious. Deprecation isn’t something that I read about often. We’re often told how to write new code or to fix bugs, but not often told about the problems related to deleting code.

Google does seem to have reinvented their own wheels for many of their tools (version control, build system, test). I did wonder why third party tools were not used. I’d have liked to have seen some of the pros and cons of using home made tools vs third party FOSS or commercial tools.

The chapter on dependency management was a bit overblown. The biggest problem in computing? It can be a headache but for me it has never been a major problem. The only chapter that didn’t interest me at all was the last one on compute as a service though I do see more and more ‘cloud’ services.

In summary, this was an enjoyable read. It would be nice to be able to use some of the tools and techniques described, but I suspect that for most people that will only be possible if they get hired by Google. Which might have been one of the secondary goals in publishing this book.

Finally, how did my preconception go?

  1. Yes
  2. Yes and I can now add ‘brittle’ and ‘flaky’ whenever talking about tests
  3. I think I was wrong there. There is a bit, but there is also a clear drive to learn from mistakes and be open to change.

Website: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/






Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED


By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED



Settings can be changed at any time from the Cookie Policy page.