PostHole
Compose
Login
SE Radio 609: Hyrum Wright on Software Engineering at Google
Hyrum Wright, Senior Staff Engineer at Google, discusses the book he co-edited, "Software Engineering at Google," with host Gregory M. Kapfhammer. Wright describes the professional and technical best practices adopted by the software engineers at Google. The wide-ranging conversation investigates an array of topics, including measuring engineering productivity and writing effective test cases. This episode is sponsored by the Algorand Foundation.
Hyrum Wright, Senior Staff Engineer at Google, discusses the book he co-edited, “Software Engineering at Google,” with host Gregory M. Kapfhammer. Wright describes the professional and technical best practices adopted by the software engineers at Google. The wide-ranging conversation investigates an array of topics, including measuring engineering productivity and writing effective test cases.
This episode is sponsored by the Algorand Foundation.
Show Notes
SE Radio
Related Links
- Book Reference: Software Engineering at Google: Lessons Learned from Programming Over Time, T. Winters, T. Manshrek, and H. Wright, eds., O’Reilly Media, 2020.
- Book’s website: https://abseil.io/resources/swe-book
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Gregory Kapfhammer 00:01:13 Welcome to Software Engineering Radio. I’m your host, Gregory Kapfhammer. Today’s guest is Hyrum Wright. Hyrum is a senior staff software engineer at Google. He is the technical lead for the C++ concurrency primitives that they use at Google. Along with teaching at Carnegie Mellon University, Hyrum was an editor of and contributor to the book called Software Engineering at Google. That book is the topic of today’s show. Welcome to Software Engineering Radio Hyrum.
Hyrum Wright 00:01:44 Thanks Greg, it’s great to be here.
Gregory Kapfhammer 00:01:45 Thanks for taking your time to participate in the show today. In order to dive in, I want to read you a few quotes that come from the Software Engineering at Google book and if you would be so kind to do so. I’m going to read the quote and I would love it if you could contextualize it and then try to explain it. Does that sound cool?
Hyrum Wright 00:02:03 Sounds great.
Gregory Kapfhammer 00:02:04 Alright. The quote number one is as follows, ìWith a sufficient number of users of an API, it does not matter what you promise in the contract. All observable behaviors of your system will be dependent on by somebody.
Hyrum Wright 00:02:21 So, this is probably the thing that gets quoted the most and it’s come to be known as Hyrum’s Law — and I should be quick to point out that I did not name it Hyrum’s Law, so I want to be humble in that respect — but this is an observation that came from many years of doing software maintenance activities across the Google code base. And recognizing that every time we tried to change something as simple as a line number or a comment in a file or a log message, tests would fail in various interesting ways. And we started to realize that if we get enough users of our system, anything we try to change will break somebody in some way. This isn’t a new observation. There’s an XKCD comment about it. There’s other places you can find references to this online, but the presentation in the quote that you mentioned and the name Hyrum’s Law (?) came out of the book.
Gregory Kapfhammer 00:03:10 So I heard you say that sometimes you could make a very simple change and then a test case would fail. Can you give us like a concrete example of when you’ve had that type of experience at Google?
Hyrum Wright 00:03:20 Sure. So we were trying to reorganize one of Google’s core file API primitives, and the result was that we were moving functions into different header files. We were changing just the basic structure of these primitives to be more understandable and be more consistent across our code base. What ended up happening was that at one point we changed a comment line which ended up changing line numbers within a file. We didn’t think anything of it, but we run all the tests just to make sure we’re not breaking anything and tests started to fail. It turns out that some tests somewhere was including the line number of the log message in their validation in the test. Now this is not good practice. You should never depend on things like line numbers that you don’t have any control over, but somebody had copied the error message and pasted it verbatim into their test. And so when we changed the comment, it reflowed the file changed the line number and the test started to fail. So even the line number of an error message was an observable behavior that somebody was depending on.
Gregory Kapfhammer 00:04:21 All right, thanks for those insights. We’re going to talk more about testing later in the show, but now I want to turn to quotation number two. So here it is. ìTraditional managers worry about how to get things done, whereas great managers worry about what things get done and trust their team to figure out how to do it.î What does that one mean Hyrum?
Hyrum Wright 00:04:41 This is really about trusting as the quote says, the people that work for you to do the job in the way that they think best. As a manager, you may manage many different teams and many different individuals, and you cannot be the domain expert in all of the things that you’re responsible for. It can be tempting, especially if you have a technical background and lead technical teams to jump in and dictate exactly how they should solve the problem that you’re giving them. But if you’re smart and as the quote mentions, great managers will just tell the team what needs to be done and let them as the domain experts figure out how to accomplish it. Managers still needs to support the team. That doesn’t mean you’re completely hands off, but it also means that you trust them and their expertise to get the job done.
Gregory Kapfhammer 00:05:28 Okay, so those two quotations have revealed very clearly that the book has both technical and professional content inside of it. This leads me to the next question. When you were writing the book, what type of audience did you have in mind?
Hyrum Wright 00:05:42 So we really want to share the things that we had learned within Google with other practitioners, my other co-editors and I spent a lot of time talking at conferences and in other external forum about the experiences that we have at Google. And we found that we kept saying the same things over and over again and we wanted to be able to write down the lessons that we had learned in a way that made sense for this external audience. We also found out that there was a significant desire within academia to take some of these lessons and present them in college courses. And so every once in a while, I’ll find some random college course somewhere that lists the book as either a required reading or supplementary material for their course. And that really makes me happy because it means that this message is getting to a much broader audience than we even intended when we started writing.
Gregory Kapfhammer 00:06:31 So if you won’t mind me saying, it actually turns out to be the case that I teach one of those random software engineering courses and we use the Software Engineering book in the class.
[...]