Verdict: Recommended with reservations
Before reading this book, I expected several things:
- Fascinating nuggets about how Google solves problems at a large scale
- A minor buzzword overdose (and in particular, ‘subtle’)
- 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?
- Yes and I can now add ‘brittle’ and ‘flaky’ whenever talking about tests
- 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.