Expert Talk: The Current State of Software Engineering

From Accelerate to SRE and Beyond

Holly Cummins: Welcome to GOTO Unscripted. I'm delighted and honored to be here with Jez Humble, who I've never had the chance to interview before. And yeah, so, I'm a bit excited and a little bit fan-ish. But maybe you could start by telling us sort of what you're doing.

Jez Humble: Thanks very much. It's a pleasure to be interviewed. So, I'm working at Google, as a site reliability engineer. Been doing that for about two and a half years now. Finally feel like I kind of understand how the serverless platform works a bit, and don't panic when I get paged, so that's nice. Before that, I've done a multitude of things. But probably, I think what people know me for is having written some books about software and continuous delivery and so forth.

Holly Cummins: Yes, definitely, people know you for Accelerate. And I think it's sort of quite interesting and maybe slightly surprising to people that you might be doing something that's not just rehashing Accelerate over and over again and that you've gone and you've learned something new. And how did that feel to go from being the sort of, you know, "the Jez Humble" of Accelerate to the Jez Humble who doesn't understand SRE?

Jez Humble: I think my problem is I'm easily bored, and I have a short attention span. When I feel like I've got to grips with something and I get very comfortable with it, I start to look around and find something else to do that I don't know anything about. And so, that's really what happened. I got to Google, and I was in DevRel for a couple of years when I joined, mainly because it meant I got to work from home and hang out with my family, and that was great. But then COVID came along, and then I could work from home being an SRE. So, I thought I'd try that and give that a try. And it's been great. It's been cool.

But the thing about Accelerate is that both Nicole and I have been working on that since 2014. So, we've been doing it for five years by the point we joined Google. And I think both of us are very happy and surprised that Accelerate has been so well-received. And, Google, they're continuing to work on research programs, the State of DevOps Report for 2023. It's currently open. You can go and take the survey for that. There's an amazing team working on that, still providing assessments to Google Cloud customers. We've got amazing resources at dora.dev. You can go and take a quick check and read about all the different capabilities. So, that work continues, but I think both Nicole and I in 2019 felt like we wanted to take a break and she's off at Microsoft doing research, and I'm at Google doing SRE.

Holly Cummins: When we were sort of first thinking about having this conversation, I was thinking, okay, well, what do I want to ask you? And the sort of the list in my head was Accelerate, Accelerate, and Accelerate. And then I thought about it and I thought it must get quite old for you of just sort of everybody coming up to you and going, "Accelerate, the DORA, DORA metrics, Accelerate." And you ever sort of wish people would talk to you about other things or are you happy to...?

Jez Humble: I mean, it's a huge privilege, but it's a great problem to have that people wanna talk to me about that. It means that it's been successful and people have paid attention to it. So, you know, I'm not complaining about that at all. I think it's great that people have found value in it. And that's the most you can hope for as an author, is that people buy your book and then they read it, and then they talk about it to other people, and then, you know, it becomes widely adopted. So, that's great. I think I worry that it goes the same way as Agile, what Martin Fowler calls semantic diffusion, and everyone's doing Accelerate, but not doing it. And, I mean, that was the reason or one of the main reasons I started on the program in the first place, is because back in the day, we were doing continuous integration. And then you kind of...everyone's like, "Oh, I'm doing continuous integration." And then you ask them what they're doing, and they're not doing it at all.

Recommended talk: Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • GOTO 2023

Holly Cummins: I don't think continuous means what you think continuous means, because your word definition of continuous involves the word six months.

Jez Humble: Right. It's infuriating.  I've got some hot-button things that piss me off, and that's one of them. So, you know, for my sanity, I kind of disappear into SRE, and I'm like, doing that kind of stuff because there's only so many times I can stand up there and talk about CI and then get wound up by the fact that a lot of people still haven't really...  I would love it if people didn't just talk about it, but if it just became the way people worked, and then people stopped talking about it because it was just the way people did stuff. That would be ideal for me. And we're not there yet, so there's still work to do. But, you know, I can't do that all the time because, you know...

Holly Cummins: Blood pressure.

Jez Humble: ...it'll drive me crazy

Keeping Up with Modern Software Engineering Trends

Holly Cummins: Yes. I think that's such an interesting insight, the idea that if people are talking about it, then that means that you've got a ways to go and that you're sort of at the...either you're at the start of the journey, which is okay, or you're doing this sort of very superficial thing, where you have all of the words, and it doesn't translate into any difference in outcomes or behavior or anything like that.

I hesitate to ask this question because it's just so existential and bleak, but we've sort of seen this trend over and over again of this kind of superficial, thoughtless adoption of things that, you know, you have the sort of the, "We're doing Agile." Well, I'm not sure you are. And, "We have a CI." I'm not sure you do, because I think it's a verb, not a noun. And it just seems to happen over and over again. And do you think that's sort of just necessary and hopeless, and no matter how good an idea is, it becomes sort of corrupted and devalued? Or do you think we are going in the right direction, even though we have these personal frustrations? Is there hope for humanity?

Jez Humble: Tough one. It is, I feel like..and this is true just more widely in the world, I think. Things go backward as well as forwards. And definitely, there's a lot of that at the moment in the wider world. I think it's the same in software. Software is so driven by trends. It's so fashion-driven. That's something that's become increasingly obvious, is the, you know, software people like to think of themselves as super-rational, and kind of, like, this very, kind of, abstract beings, and software's not like that at all. It's just wildly fashion-driven. And so there is a certain cognitive dissonance in this stuff being very popular to talk about. And you still go and poke around at what's on the ground. And what's on the ground is, you know, very different. But I think that's always been the case.

I remember doing the research for the Lean Enterprise book. And there's a book by McGregor called "The Human Side of Enterprise," which was written in 1960, talking about Theory X and Theory Y and, you know, how Theory X is about carrot-and-stick rewards, and Theory Y is about intrinsic motivation, and how managers approach motivating people, and the behavior that you get depends on how you treat people. Here we are in 2023, and people still haven't learned that. And so, that's 60-plus years old by this point. All right, if I was gonna get existential about this, I would start talking about capitalism, and how capitalism creates these reward structures, which create these kinds of intrinsic motivations, and that's the reason why we see a lot of the things that we do, which I think is true. But if I was gonna be a bit less ranty, I would say a lot of this is about developing good habits that help you achieve long-term goals. And so many of our incentive structures are short-term. And so much of it, especially as a developer, is about... You know, developers are very good at following incentive structures. And so often, the incentive structure is just to get the code in as quickly as possible, and to sit on your own and kind of do stuff. Talking to people is difficult. Communication is difficult. It's an overhead. It's not what engineers are trained to do. And I think...

Holly Cummins: A lot of us became engineers specifically to avoid having to talk to people.

Jez Humble: Right. That's right. And, you know, that's a huge problem. We were talking about stereotypes, and women in tech, and a lot of these things feed into each other. This stereotype we've created, that it's kind of an activity by people sitting in rooms on their own, with, like, wearing hoodies and doing all this. Software engineering is fundamentally a social activity. I know I'm preaching to the choir.

Holly Cummins: That's not just at me though. It's at me and however many thousand of our closest friends, so preach away.

Jez Humble: I think a lot of what we're trying to do with CI and Accelerate is talk about teamwork, and how to build high-performing teams. That's, we're very specific in the book about that, about how it's about building high-performing teams. And so much of that is about behavior, communication, board structures, leadership, and effective leadership. Leadership is not about the executives. Leadership is about everyone. Everyone on the team trying to help grow the team and grow the capabilities of the team. And so, I still think, like, the reason there's not so much focus on that is just because these stereotypes persist. They're perpetuated by a lot of the existing people in tech, and in society more widely.

The Social Aspect of Software Engineering

Holly Cummins: I have another theory about the fashion aspect of it which is slightly less depressing, so you may enjoy it. Because I think you're 100% right. It is so fashion-driven. We see this so much of the...I mean, we saw it with Agile, and we see it with microservices now. One of our consultants used to get frustrated because he'd sort of go and talk to a client and they'd say, "We wanna do microservices." And he would say, "Why do you wanna do microservices?" And they would say, "Netflix." And they'd say, "Okay, well, but what problem are you trying to solve?" "Netflix." No, but...and then, you know, the conversation would, you would be in trouble because they weren't talking about decoupling or, you know, anything like that.

But I think all of us, we wanna do the right thing, and we want to become better. The way that we do that is by looking at the people that we perceive to be doing things in the best way, which, in the case of Netflix or, microservices certainly was Netflix. And because we all have too much to do and too much cognitive load, and because we're lazy, but I'm trying to be optimistic, so we'll say because we have competing demands, you know, you do take those mental shortcuts, which means that you copy the superficials of, "Hey, maybe I can make my application distributed," rather than the more fundamental things of, "Hey, maybe I could decouple my application." Because it's harder. People aren't very good at doing hard things, but that's because we have lots to do, and we're prioritizing in a way that's not always wise but is coming from a positive place of aiming to improve, and prioritizing unwisely.

Jez Humble: I think that's right.

Holly Cummins: Have I cheered you up yet?

Jez Humble: I mean, the problem is... I agree with that. But I think, you know, then you're relying on people to create systems that encourage the right behavior, and I just don't see enough of that, I guess. That's optimistic if you imagine that people are gonna create the capacity to do the right thing. And I guess that's what worries me, is that I don't see enough of that.

Holly Cummins: I was used to getting depressed when I'd get asked, how do we persuade our management to let us refactor? I used to think, well, you shouldn't have to persuade your management to refactor. You should just do it, all of the time, continuously, and things should be getting better and you should be being rewarded for that. And if either of those two conditions isn't there, then something deeper is wrong, than "I don't know the right argument to persuade my management to refactor."

Jez Humble: I think that's right. What I tell people is, "Don't tell your managers. Don't ask permission." You know, and this is the same with testing. Like, "How do we get permission to do testing?" I'm like, "You don't." I mean, when you take your car to the garage to get your car fixed, does the person in the garage say, "Oh, well, you'll pay this up...you know, this is the charge to get your car fixed, and this is the extra charge to make sure it works after I fixed it." Like, that's not how it works. You pay it, and they check that it works as part of doing the work. So, you know...

Holly Cummins: Although, you know, going back to incentive structures and systems, again, that if garages did offer that two-tier pricing, quite a lot of people would quite happily take the...

Jez Humble: The cheapest option.

Holly Cummins: It's cheaper. I'll take it. And then be aggravated that the car doesn't work, and then think it's the fault of the garage.

Jez Humble: Right. No, no, that's true. That's true. You'll always find a way to blame someone.

Holly Cummins: So you have to bake it into the system so that it...

Jez Humble: Right.

Holly Cummins: Yes.

Jez Humble: So, you need to get better at that. And again, that's about human stuff. I think a lot of software engineers are rule-followers, and don't wanna get into trouble.

The Difficulties of Initiating Change

Holly Cummins: We were talking before about systems, and one of the things that some systems, I think, probably are easier to shape into the right direction, and some systems have constraints that make it more challenging. And sometimes they're real, and sometimes I think they're superficial or apparent. So, you mentioned Lean Enterprise. And when I would speak about process things, one of the questions that I got every single time, was, "We'd like to be quite cool, but we're a regulated industry, so we can't do anything well." And then I used to say, "Have you read Lean Enterprise?" And the answer would be, "No." And I would then sort of give half an answer, and, by saying, "Go read Lean Enterprise." One of the things that you show in there is that these rules that are used as an excuse often actually don't prevent good behaviors. And really the, you know, regulated industry, of all industries, you should be testing, and you should have the rigor, and you should have the auditing and that kind of thing. So, can you talk a bit more about what you've seen in regulated industries?

Jez Humble: Yeah, I mean, exactly as you say. The things that we talk about in continuous delivery and extreme programming, are even more important. People seem to have this idea that Agile and extreme programming is about being a cowboy and cutting corners.

Holly Cummins: Yee haw!

Jez Humble: Right, exactly. And that's not it. You are being much more careful and much more rigorous about the way that you do your work, and making sure that you're building quality. That's one of the key concepts in lean engineering, as well as extreme programming. And so, yes, as you say, it's even more important in that situation to be doing the right thing. So…

Recommended talk: 5 Tricks To Make Your Apps Greener, Cheaper & Nicer • Holly Cummins • GOTO 2023

Holly Cummins: We're in a regulated industry, so we really wanna do the wrong thing.

Jez Humble: You don't wanna do testing and continuous integration? Hmm. That's an interesting choice. That's exactly right. And I think a lot of the time, what they're saying is, "We can't change the way we work. Because if we change the way we work, then someone's gonna come and slap us on the wrist." And I think, you know, that fear is real. It can happen anywhere. It can happen in startups, you know, and it's just a function of the fact that any successful organization, and again, this is not me, this is...oh, I'm blanking on the name of the...Schein's book, "Corporate Culture Survival Guide." He talks about the fact that successful companies are successful because of the way they work. So, if you're trying to change the way some successful team works, you're saying, well, the things you're doing, that made you successful, are the wrong things to be doing, and now you need to change it, to which the obvious response is, "Well, why?" You know? And I think that's really what's kind of going on in a lot of places, and the fact that there's a cost to changing the way you work, and the auditors might well come in and be like, "What are you doing here?" And so, that's real.

I think the response to that is, you know, it's all in your mind. Firstly, to challenge yourself always to think, what if the way I'm working is not the best way that it's possible to work, and there is a way to improve? And so, there is a mental thing that you have to always be thinking, you know, "How can I get better?" And that's something that, you know, I know probably for psychological reasons to do with my childhood, I've always kind of had in the back of my mind.

Also, I think the thing that still surprises me is the extent to which the industry is, like, segregated into...you know, people can work a certain way. So, for example, the question I always used to ask, for trunk-based development, is, you know, "Do you do trunk-based development, or do you work on branches?" And I go and tell everyone about continuous integration and merging into the trunk all the time. And there were two responses to that. It was very, very binary. People would either say, "Oh." Or they would say, "That's completely impossible. What are you talking about?" And you find a lot of people who've worked a particular way, and they find it inconceivable that you could work any other way, or that people over here are doing something different. And that's shockingly common, I think. I think that's another kind of mental thing that people have gotta overcome, that, you know, the way I've been working all my life... And that's scary, right? If you've been working a certain way all your life, and you've been successful, and someone's coming along and telling you that there are problems with that. You take that as, like, a personal insult, almost, or at least a challenge. So, there's a lot of that, I think.

Jez Humble: But again, most of these problems... Someone said this, and I can't remember who it was, unfortunately, but they said that a lot of extreme programming was about getting people to talk to each other more, and it was about overcoming a lot of these stereotypes about software engineering. So, you know, continuous integration and testing, and a lot of these things are about, you know...and extreme planning and, you know, cards, and all this kind of thing, it's about encouraging conversations. And so, if you go and talk to auditors at regulated companies, often you can have really good conversations. And I've done this on multiple occasions, you know, gone to banks and talked to the developers, and like, "Oh, we can't do this because the auditors will hate it." And then you go and talk to the auditors and they're like, "Oh, that sounds cool. How can we get in on that?" You know, and it's just because they're not talking to each other. So, that was always my biggest hack with DevOps, is, like, how do you implement DevOps? Find the people who you think are gonna say no to you, and go and take them out for lunch. Find out what's motivating them and what they care about, and have a conversation. And normally, you'll find you've got a lot in common.

Balancing Communication in Tech

Holly Cummins: How do you balance? Because I see two sorts of trends in tech talks and tech writing. One is, that we need to talk to each other more, and these problems that seem like technical problems are problems caused by not talking to each other. And the other one is we need to talk to each other less because we're not getting anything done. After all, we have this enormous communication overhead. How do you reconcile those?

Jez Humble: That's an excellent point and a very good question. The standard spiel on this is about Conway's Law, and about... I think the crucial insight is, that you've got limited communication bandwidth. How do you use it wisely? And how do we use it to talk about the right things instead of the wrong things? The right things are the information that you need to get it right in the first place. The wrong things are detailed planning across teams, to find out stuff that is an artifact of the fact that you've organized your APIs and your teams wrongly. So, that's what it is. It's like, yes, the bandwidth is limited. How do we use it for the right things? And a big piece of it is, like, well, you've gotta get the team structure and the architecture right, so that you can use that bandwidth to be, you know, focused on strategic issues rather than tactical issues fundamentally.

Holly Cummins: I guess, as well, then there's sort of the "don't waste time communicating about things that could be done by an automated process." So, instead of having a conversation about the status, let's have the status automated. Instead of having a conversation about the current implementation of the API, let's have somewhere where we can look it up and just use it. There's probably loads more examples like that, yeah.

Jez Humble: That makes me just think about the importance of good platforms. So, one of the things that I found cool about joining Google was, you know, I wanted to... So, we had all this stuff, from all this material in DevOps research, that Nicole and I had built. We wanted to set up the website on Google infrastructure. In a lot of companies, you would need to go and talk to someone, and, you know, go through a whole process. What I discovered at Google, it was just scarily easy that you could just create, you know, I just created a directory, created a mapping to the Google front-end to stand up the website, like, pushed all the code, and I just needed to send change requests to people, and then they would look at it and be like, "Yeah, that looks fine." I didn't need to talk to anyone. I could just stand up this website and, you know, do it all with just pull requests to people, and that was a standard process, and it just worked. And so much of Google, you can just get stuff done with a change request, without having to talk to anyone. And I think that's exactly your point. We've built a platform at Google where anyone... you can't directly change anything, but you can certainly send a pull request to anyone. Anyone can do that. You can find all the code, you can send change requests, and you can get stuff done that way. And it's wildly efficient.

Holly Cummins: And you get the audit trail as well.

Jez Humble: Absolutely. You get all those things you want from compliance, which is the segregation of duties and all that stuff. It's all for free.

Holly Cummins: Nice. I mentioned, you know, that there's these environments where it seems like the system makes it harder to do the right thing, but it's not. Because, you know, you're in a regulated industry. It should be easier to do the right thing. But then I think there are other ones where, maybe we don't know the answer yet, and there are ways that we would like to work, and other constraints that we have. Where I'm going with this in particular is, the relationship between extreme programming and open source, because both of those are just the best things since sliced bread. But one's a round piece of bread and one's a square piece of bread. I sometimes find that the sort of, reliance on pull requests in open source is really necessary to enable an asynchronous way of working because no one who is maintaining an open-source platform wants to be rung at 2 in the morning by someone saying, "Hey, buddy, I've got an idea. Can we do some pair programming?" "No. It's 2 in the morning and I had other priorities." But on the other hand, pair programming solves so many problems and it's a nice... But what's your solution?

Jez Humble: I mean, I wouldn't say I had a solution, but I think my analysis of it is that you know, again, fundamentally, we're looking at technical mechanisms as a proxy for actual human behavior, such as trust. So, the reason that you want pull requests if you're maintaining an open-source project is that you don't want just any old person committing to your repo, because you don't trust them, quite reasonably. And if you're, you know... I don't know, probably someone will contradict me on this, but if I've been working with someone a long time, and I know how they work and I know the kind of their risk tolerance and their way of working, then it's much quicker for me to be able to review their change requests and see what they're doing because I've got so much context on the way that they work and the kind of work that they do. And so, you will treat different people differently. And, also, if you've been working in open source for a long time, you know better than to send, you know, six months of full-time work as a change request to someone and expect to get it committed.

I used to lurk on the Linux kernel mailing list back in the day quite a lot. And you'd see all the time people would submit change requests, or send a patch in those days, as we called it, and someone would say, "Take that. Break it into eight different bits and submit them all separately," because otherwise, how are you supposed to understand what's going on there? I mean, as you know, you know, you can't just look at a huge change request and visually understand what's going on. So, the answer is to break that up into small bits so you can understand each one independently, and evaluate that. And that's exactly what continuous integration is. It's breaking it up into small bits and then integrating them regularly. So, the same forces, fundamentally, apply in both scenarios, I think. And it's all about, you know, working incrementally and iteratively, and understanding what you're doing, and working in this context of complex systems, where small, apparently simple changes can cause unexpected side effects, and building systems around managing the risks of those changes.

So, I mean, fundamentally, the same forces apply. It's just that we're gonna apply different techniques to manage those different risks. And, certainly, for me, my happiest times are working in a co-located team, pair programming, and it was so efficient, and you got so much work done. And I understand that you know, that's not possible anymore, and there are disadvantages to that, and not everyone can work that way, and that's fine. But you've got to change the way you work based on, you know, what's appropriate for your team and the wider problem you're solving.

Holly Cummins: I think there's such a tension between the joy of working in a co-located team and pair programming, and the joy of working with a distributed team, where you have the choice of people who are anywhere in the world, and you can work in your pajamas from anywhere in the world as well. And again, both of those are so good, but they just aren't compatible.

Jez Humble: It is very cool. You're right. I mean, there's a joy to be found in both ways of working.

Holly Cummins: I find... Because I used to work in an office, and now I work at home, and I got so much work done on the train that I don't get done anymore.

Jez Humble: Oh, right?

Holly Cummins: Even though I don't miss the commute, I think I miss that kind of decompression structure that existed at the beginning and end of the day.

Jez Humble: It's nice. Then you get to decompress a bit. And when you're at home, you can be in that headspace a lot more, whereas the transition when you work from home just can be a lot more jarring.

Addressing the Formatting Issue

Holly Cummins: When we were talking about the sort of response to Accelerate and some of the frustrations that you had, do you have any other complaints and rants that you'd like to share? Because this is the perfect opportunity to just complain.

Jez Humble: To rant about stuff.

Holly Cummins: Exactly.

Jez Humble: Well, we were having a little chat before this...

Holly Cummins: We were.

Jez Humble: ...about how, when you get that big pull request, the only thing you can do, apart from send it back and get them to send it in smaller bits, is complain about the formatting, and how that shouldn't even be a thing in the first place. I'm gonna talk again, annoyingly and smugly, about Google's toolchain, and about how the first thing that happens when you send a pull request in is it runs the linter against it, and it fails the build if the linter says that your code is not formatted properly, and how they've got this nice toolchain where you can just type "g4fix," and it'll run the linter on all the files, and lint them correctly. So, it's just never a problem. And if it is a problem, it's an immediate facepalm. The CI system's just like, "Run g4fix."

Holly Cummins: I think you can get these pockets of fixedness, but it does frustrate me that in our industry as a whole, it's 2023, and I've been saying this every year for the last 15 years, we still haven't fixed this. We have the isolated bits, but I never really got on with Go as a language. But the one thing that I thought was amazing in Go was the Go format, to just say, "I don't care about your opinions about tabs versus spaces. This is the format. Sort it out." Whereas for, really, the Java ecosystem that I'm in now, well, in fact, in general, I think, you know, we still don't even have a rich cross-IDE formatting specification, and it's 2023. I still get comments on the formatting in my pull requests. And every time I do, I just lose the will slightly because we can send people to the moon and we've been doing that for 60 years. And, you know, the problems that we can solve now are so complex, and yet the problem of getting people to agree on tabs versus spaces, and encode it in an industry-wide way, is apparently...

Jez Humble: Beyond us as a species.

Holly Cummins: Yes

Jez Humble: I don't know if you watched the "Silicon Valley" show.

Holly Cummins: Yes.

Jez Humble: There was a whole episode...that was brilliant. I mean, as I say to people, "the reality TV show that is Silicon Valley." Yes, no, exactly. And I think what you see from Go is that kind of emerged from Google culture. Because part of Google culture we have this mono repo, where everyone's committing to the same enormous codebase. You have to have the same style used everywhere because the linter is applied to everything. We just choose it. You know, we have this very annoying concept of readability at Google, where, every time you submit some Java code, for example, it has to be approved not just by someone else, but by someone with Java readability, who'll make sure that you've written Java code that's easy to maintain, and that's got tests, and that, you know, meets the style bar, and, you know, and so forth. So, there's this whole bunch of things that people look at. Once you've submitted enough code, you can get readability for yourself, and you don't need to get someone else approved. But they do enforce the monoculture. If you're writing, everyone who writes Java at Google writes the same kind of Java, and it's the same for all the other languages as well.

It's one of my goals to get readability for at least one language.  I'm close to getting readability for SQL, which should tell you everything you need to know about being an SRE. And Go. Nearly there for Go. So, we do enforce that, and that's why Go is like that, and it kind of emerged from that culture, which emerges from the way we've organized the toolchain. So, you know, that kind of thing, as, like, a process geek, always fascinates me, you know, how all that works and what the incentive structures are and so forth. But I think it's something that people use as a way of, like, you know, I would say almost like othering different people, it's like creating tribes where they shouldn't exist necessarily, and around the wrong things.

Recommended talk: Observability Engineering • Charity Majors, Liz Fong-Jones & George Miranda • GOTO 2022

Holly Cummins: I think it's so tribal. A while ago, we applied formatting standards across the whole codebase and enforced them in the CI. The amount of conversations we had about it, of, "But could we make an exception for this little bit of the codebase, where I'd like these standards?" "No. It only works if we all do it that way." And fundamentally, it doesn't matter.

We talked about how you get these sorts of trends that come and get applied virally. DORA metrics and the Google SRE book is another one, I think, where, you know, you get sort of people who go, "We've read the book," and then you ask them questions, and you realize that they haven't absorbed much of the book. They're just physically holding the book. And maybe that can be the next sort of tech trend that will come out of, you know, "Yes, we've read the Google book on formatting. We're all in. We're a format shop."

Jez Humble: It's like, well, one of the big list of things that if you do it at the beginning, it's super easy, and then if you don't do it at the beginning, it's a total nightmare. And I think so much of... I'm sure you deal with this as well. It's like, you're fixing things that should have been done right in the beginning. And just, it's outrageously more expensive trying to standardize later.

The Need for Industry-Wide Standards

Holly Cummins: I think I can probably answer why there's never going to be the Google format book though, because I think with a lot of the other things, what makes them interesting is back to the incentive structures, isn't it, of...

Jez Humble: Mm-hmm.

Holly Cummins: ...if I've read the Google SRE book, I might be able to get a job. And if I go and I put it on my CV, "I'm good at not formatting code," it seems so trivial. It seems so obvious. And so, then that means that we get away, as an industry, with being terrible at it. Whereas the things that are hard, like microservices, like SRE, we're still terrible as an industry at them, but we put a lot of effort into continuing to be terrible at them in slightly different ways, with a fancier vocabulary. Sorry, I've depressed you again.

Jez Humble: No, I think you just made my head explode. Let's focus on the right things, for God's sake. But, you know, people, reading. All hard.

Holly Cummins: I think we should probably wrap up, but we need to say something nice and positive to wrap up with because otherwise, it's gonna be depressing.

Jez Humble: If you spend time reading the news or on social media, it's so easy to catastrophize. We're living in an era where we have these incredibly powerful tools. Tech tends... I mean, this is the problem with Silicon Valley, is that you take those tools, and you use them to reinforce existing power structures. I hope that we can find ways in industry to use those tools to demolish some of those power structures. And instead of disintermediating people to maximize corporate revenues, maybe we can find ways to use these tools to help marginalized people, and level the playing field a bit. So, that's what I would like to see. I don't know how to do it.

Holly Cummins: At least in the interim, at least we have continuous integration now, in a way that we didn't 15 years ago.

Jez Humble: I'll take your word for it.

Holly Cummins: Yeah. It is. It is so much better, it is. Well, thank you very much, Jez Humble. It's been great.

Jez Humble: It's been a pleasure. Thank you so much.