Bookshelf: Software Engineering at Google

 

When I wrote "Beauty In The Eye Of The Coder," my idea of beautiful code was how well it stood up to time:

Requirements change, database fields are added, code is refactored by multiple authors. Time conspires to distort and contort programs, but the ones that endure are often considered beautiful. 

The book Software Engineering at Google tackles the nearly incomprehensible scale of Google's software engineering efforts, and the subhead "Lessons Learned from Programming Over Time" caught my eye. Was there room for beauty in software that was engineered for scale, time, and cost? More on that later.

I discovered Software Engineering at Google at an online ACM TechTalk, and the book's curators, Winters and Wright, provided an excellent starting point for exploring the book's hefty 600 pages. The authors distinguished programming from software engineering, and they were careful to point out that one was not better than the other because the disciplines really operated in separate domains.  In their words:

"Programming is the immediate act of producing code.  Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team."

While the passage greatly oversimplifies programming (which Donald Knuth considers an art), I get it. When I studied chemistry in college, it was largely theoretical and steered me toward research and development. When I asked my counterpart at the engineering school what chemical engineering involved, I learned it was about manufacturing at scale with an eye on costs.

Not all software engineers work at a company the size of Google, nor do they need to deal with the accompanying challenges.  Nevertheless, there are some interesting lessons to be learned. One such lesson was the "Error Budget" which was a carried over from another Google book, Site Reliability Engineering.  Instead of having a goal of 100% uptime, target something lower such as 99.9% and use the margin to adjust for risk tolerance. That is, release software faster if there is room in the error budget, slower if you have used some of that margin.

During my time at the New York Stock Exchange / SIAC (circa 1990), we had a similar practice. At the start of the year, employees were eligible for 100% of their pre-allocated bonus. With each outage, however, a certain amount would be dinged. Thus, releases happened more frequently at the beginning of the year and slowed down toward the end of year so as not to jeopardize the remaining money. While I can't speak to the NYSE policies of today, back then, this practice balanced software updates with system stability. 

This book covers a lot of ground, including culture, tools, and efficiency. One way to absorb the material is to study the table of contents and find what interests you. Also, every chapter ends with handy TL;DRs to help you decide if you want to read further.

My preferred way would be to open the book to a random section and read during software compiles, and therein lies some irony. The software at Google was so large and complex, that compiles took a very long time. The authors didn't say exactly how long, but made their point with an xkcd joke where the cartoon programmers engaged in swordplay while the code was compiling.  Google's answer was to write its own distributed build system, which incurred its own costs, but their tool cut down on build times drastically... which would also, theoretically, cut down on my time spent with this book (in addition to time spent reviewing when I should have parried when I thrust).

Alas, while I see the possibility for beauty in programming, there is no room for beauty when it comes to the policies, practices, and tools that make longevity, scale, and cost efficiency possible. Engaging in  s wordplay, and with apologies to René Descartes, I like to say as a programmer:

I code, therefore I am.

As a software engineer, I would say:

I engineer software, therefore WE are.

Which puts us on the path to eventually say:

We are Borg.