Software Engineering at Google: Practices, Tools, Values, and Culture

[ad_1]

Key Takeaways

  • We wrote “Software Engineering at Google” for people at all levels of experience, from students to engineering policy makers. We’ve tried hard to not say “This is the one true way to do it,” because we recognize that our scale and resources are wholly different than other organizations.
  • Software engineering is not (just) programming, it’s programming over time. We’re focused mostly on how to keep things sustainable over time, and how to coordinate and collaborate with other people. There is very little code in the book, but it’s still very much about software.
  • Google is imperfect, both technically and organizationally. You can see that in our handling of technical issues like maintenance of external packages, and also in our cultural issues around equity and diversity. 
  • Code review is not primarily about defect-detection, it’s more useful as a communication exercise. It provides a great opportunity for education, and establishing a shared understanding.
  • Choice is often the enemy of efficiency in technical domains. Our version control and dependency management policies work mostly by removing options from our engineers. If you don’t have a choice, you don’t have a problem.

The book Software Engineering at Google curated by Titus Winters, Tom Manshreck and Hyrum Wright provides insights into the practices and tools used at Google to develop and maintain software with respect to time, scale, and the tradeoffs that all engineers make in development. It also explores the engineering values and the culture that’s based on them, emphasizing the main differences between programming and software engineering.

InfoQ readers can download the book for free: Book Software Engineering at Google.

InfoQ interviewed Titus Winters, Tom Manshreck and Hyrum Wright, about software engineering at Google.

InfoQ: What made you decide to write this book?

Titus Winters: After the public launch for Abseil I tried to take a breather. It had been a few years since I’d really reconnected with the schools and friends I had before Google, so my wife and I did some travel and outreach in Southern California. When technical topics came up, a lot of people that I talked to seemed to be in exactly the same place they were technically back in the early 2000s. Schools still had the same curriculum. Companies were still ignoring the importance of unit tests. At the same time, Google was consciously pushing to be less of an “island” with respect to the tech of the rest of the industry, but I was seeing a lot of topics where I genuinely believed that the Google approach made more sense. So I pitched the idea of a Software Engineering version of the SRE book, and my VP at the time (Melody Meckfessel, now at Observable) gave us the go-ahead.

Tom Manshreck: I had the advantage of having worked in publishing before as a managing editor so I knew what I was getting into. Although I had experience in the software industry for 15 years, once I joined Google, I needed to learn so much more about actual software development. I wanted to consolidate all of this knowledge about engineering practices into a coherent whole, so this idea was something in my head for a long time. When Titus approached me with the thesis for this book, I realized this was the opportunity to write all this knowledge down. And given Google’s unique position and scale, I knew that we had something unique to say.

Hyrum Wright: Basically, Titus roped me into it. 🙂  More seriously, it felt like we were having many of the same conversations with various people outside of Google about the way we do things “on the inside.”  Google has published various academic articles and our colleagues have given a number of talks at various industry venues about our approach to software engineering, but there wasn’t a good referenceable and approachable resource for folks in the industry.  The book is our attempt to put the lessons we’ve learned down in a digestible format so others can learn from both our successes and failures.  The goal isn’t to tell people they have to follow our exact path, but to help them see what path we’ve taken and where the pitfalls might be as they find their own way.

InfoQ: For whom is this book intended?

Winters: We were aiming for this to provide the “Why”, and our understanding of best practices at Google scale. I think it’s probably most useful for people involved in policy and decision making for a software organization – whether that is the people making the decisions or the people proposing changes and improvements. I hope it is also useful in university classes discussing software engineering. A formal classroom environment is a great place to focus on the theory and the reasoning, before people make it into the industry and rely too much on “This is how we’ve always done it.”

Manshreck: Usually you write a book for a specific audience, but in this case we have a few. People unfamiliar with the aspects of software engineering itself (i.e. students who have no work experience) will find a wealth of information about how software development “really works.” People already within the industry will see how a development team adjusts to a growing organization. And even industry professionals will find information about “how Google does it” to compare and contrast to their own practices. As we stated in the Preface, we don’t mean to imply (or even want) to tell others how to do things. But we do want to share what we’ve learned, and especially share how we dealt with mistakes along the way.

Wright: Different audiences are going to have different takeaways.  Higher-level decision makers will be interested in chapters that discuss the background of the decisions we’ve made (for example, why a build system like Bazel is ultimately more scalable for your organization).  But we hope that it’s also useful for the folks “down in the trenches” as well.

InfoQ: How would you define software engineering?

Winters:  I think one of the oldest definitions is still one of the best. Software engineering is “the multi-person development of multi-version programs”, and that quote (from the 1970s) still captures the main themes of Time (multi-version) and Scale, especially process and communication scaling (multi-person). It is one thing to write a program to solve your problem. It’s wholly another thing to collaborate with a 10 person team to solve your problem in a way that you can keep working in a decade after everyone on the team is gone to new things.

InfoQ: How can we build a great software team?

Manshreck: Brian Fitzpatrick’s chapters illustrate this well. The skills required for developing good software are not the same skills that were required (at one point) to mass produce automobiles, etc. We need engineers to respond creatively, and to continually learn, not do one thing over and over. If they don’t have creative freedom, they will not be able to evolve with the industry as it, too, rapidly changes. To foster that creativity, we have to allow people to be human, and to foster a team climate of trust, humility, and respect. Trust to do the right thing. Humility to realize you can’t do it alone and can make mistakes. And respect for the members of the team rather than relying on a few individuals. You simply can’t make a good software team with a few “rockstar” engineers who play by their own rules. That may work in the short term, but in the long term, it will fail. You need to allow people to continually evolve and contribute to the organization, and they need to be part of a team.

InfoQ: The book mentions that psychological safety is essential for learning. What can we do to establish psychological safety in large groups?

Winters: From what I’ve experienced, one of the most critical things is for leaders to admit their own fallibility. Normalize making mistakes, get people out of the false idea that perfection is expected (or attainable). Once we stop treating mistakes as failing, but instead look at them as a chance to learn, your team is going to accelerate a lot. And, counter-intuitively, when you make it clear that it is OK to make novel mistakes, you’ll wind up making fewer mistakes in the long term….

[ad_2]

Read More:Software Engineering at Google: Practices, Tools, Values, and Culture