With all of the hype around the future impacts of AI, it can be easy to overlook existing solutions that solve some of the biggest pain points faced by your engineering team.
On this week’s episode of Dev Interrupted, co-host Conor Bronsdon and LinearB’s Head of Developer Relations, Ben Lloyd Pearson, discuss programmable workflows and how you can apply policy-as-code principles.
Recorded live at the DevOps Enterprise Summit, Conor and Ben explore how gitStream’s programmable workflows can reduce manual effort, facilitate faster feedback loops, and improve developer experience.
They also touch on the gitStream's seamless integrations and its future enhancements.
Episode Highlights:
- (2:00) Understanding programmable workflows
- (7:00) Challenges in the code review process
- (11:30) Improving the code review process
- (15:00) Adopting programmable workflows
- (17:00) Future of gitStream
- (20:00) gitStream integrations
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Conor Bronsdon: Hey everyone. Welcome back to Dev Interrupted. I am delighted to be joining you live from DevOps Enterprise Summit. I am your host, Conor Bronsdon, and I'm joined by one of my good friends, the Head of Developer Relations for LinearB, Ben Lloyd Pearson. Ben, welcome back to the podcast.
Ben Lloyd Pearson: Yeah, it's great to be here.
It's been great energy so far at the event. I'm really looking forward to, just getting through the rest of it.
Conor Bronsdon: Yeah, we had a really fantastic opportunity to kick it off at the DORA Community Summit. I know we want to get into a bit about what we learned there, some of the conversations we had.
It was very informative. And one of the things that we've been hearing a lot about here is about programmable workflows, which is something that we're very passionate about, and you in particular have a lot of depth on that. You're building out the free tooling that LinearB is doing for initiating programmable workflows and applying policy as code for organizations.
Can you start off by defining for the audience what programmable workflows are? And then let's dig into a bit about why they matter so much.
Ben Lloyd Pearson: Yeah, I think what it really comes down to is giving developers the tools that they need to configure, program, design, all the sorts of automations, tooling that they need to get software from an idea to deployment into production.
oNe area that's done very well in this area is CICD. There's a lot of tools out there, there's a lot of established practices and processes, a lot of automation, a lot of the toil that developers used to have to spend has now been automated away from them, but using conventions that are very familiar to them.
It's configurations, it's coding, it's stuff like that. We've spent a lot of time focusing earlier in the process than CICD. We've been promoting this idea of continuous merge, which applies, more of the, that mentality to the code review process. So a little bit earlier upstream from the CICD system.
And that's opposed to, some of the other workflows that developers might have to deal with day to day for example, every team has a project management software. Most developers don't really like using it. They know they have to. I love Jira. What are you talking about, ? Yeah.
Man, it's a beast. It can be amazing, but it terrifies developers valid. And it's a big context switch, so anything you can do to. To make it easier for them to interact with that in a way that's more natural. That's what we're proposing. And, there's also a lot of interest that I've seen around regulatory and compliance as well.
There's a lot of things that you need to... To make sure your organization is following, especially if you're like, in a highly regulated industry, if you're in banking or something like that, or insurance. I've also seen, just so far at this event, there's been a real big interest in, And having like policy as code, programmable workflows that make sure your organization is mitigating risks associated with delivering software.
Conor Bronsdon: So let's dig into that a great example of code and maybe help with compliance or security concerns?
Ben Lloyd Pearson: Yeah, so if you have, parts of your code base that, need extra scrutiny or it impacts user data or it potentially could open up security vulnerabilities. You want to make sure that you have the right processes in place, both to catch those, but then, there's always situations where you might need exceptions having systems built in place to, to that, that prevent people from getting blocked within those processes,
Conor Bronsdon: So an example of that might be, let's say, we're looking at a part of the code base that we've identified is highly compliance, there's a high degree of importance to compliance there. Maybe, to your point, it deals with user data. Maybe you want to add an additional reviewer who's sits on a certain security team or compliance team to add additional reviews, those prs and you're saying we can automate that process or other approaches to it based on however you wanna configure your workflows.
Ben Lloyd Pearson: Yeah, imagine if you asked a developer every time that they needed to get an exception to a policy. To manually go through and figure out which policies are applicable and flag the appropriate people. It's just, it's never going to scale. It's never going to be successful. So you want to make sure that It's as automated as possible so that you don't miss anything and that you're not just putting toil on your developers that distracts them from the stuff they, or, you hire them to do.
Conor Bronsdon: Do you see this implementation of programmable workflows as something that developers are going to be pushed to do to, in order to implement policy as code in the coming years?
Ben Lloyd Pearson: Yeah, so I, I almost think that it potentially is going to be both ways. I think there's going to be a lot of scenarios where an organization might, for example, want to get SOC 2 compliance.
And in a situation like that, it's, the decision's probably made at the executive level. They're going to push down all of those requirements. And, myself, I don't know much about SOC 2, but I know when someone comes knocking on my door and says, We need to do this to get prepared for it, then I know I have to, I have to prioritize that.
There's no debate around that. But you can't really expect me, or you can't really expect a developer to know, when they're potentially at risk of stepping out of the bounds. A great way to do that is just to have some sort of automation that flags anything that looks like a SOC 2 concern.
So that, when you have to go back and verify that you do follow those practices, like you have some verifiable proof. But then you also have the bot, the reverse of that. I think there's a lot of developers who face a lot of challenges, particularly around, The code review process there's a lot of delays that tend, that, that happen in, in, in that area.
And, a lot of the fixes are they're developers scratching their own itch. They don't like waiting on PRs to get picked up for a long time. They don't like having to come back to a, to review code days after they submitted it for review. In those situations, I think there's also very much a bottoms up appeal.
Conor Bronsdon: I'm glad you brought up the code review process because this is such an important friction point in the software development life cycle. And we're seeing that come through in the research data. So we did our 2023 engineering benchmarks report, and we clearly saw that there were challenges in code review, particularly for some large organizations.
And it's also very clear that when you can merge code faster and speed up that cycle time, you're just able to deliver more value. And it's something that was also followed up by the 2023 DORA report, which we partnered with Google on. And they actually found that faster code reviews were indicative of 50 percent higher software delivery performance.
LinearB has focused in on code reviews as this key friction point to improve. Can you dive into a bit about how gitStream is trying to approach this, and why LinearB is so focused on this key area?
Ben Lloyd Pearson: Yeah we fortunately have a lot of data around this, which is, puts us in a really great position to have some fairly strong opinions about it.
And one of the things we know is, after looking at, I think, more than 4 million PRs at this point, That have been processed through our platform. The thing that consistently comes up as the biggest slowdown in the software delivery process is around the code review process. Developers write code really quickly.
Once it's been reviewed, it tends to get merged quickly. The CI CD systems tend to be pretty good at getting it deployed to production. Relatively fast. All of the testing and everything we have we've, it tends to be pretty good for, ensuring quality and efficiency.
But there isn't really a lot of solutions out there on the market for people who are facing challenges with code reviews. And what we found is that like some teams, a lot of teams are waiting multiple days just to get someone to look at a code review. And if it's a small fix, like that's demoralizing for a developer.
Every developer wants to do their part to, to fix whatever they can. And if they make a small improvement, but it doesn't get any attention for days, like that's demoralizing. But it's also just, if it is a complicated fix that you have to come back to, there's a massive context switch that only gets worse the longer that takes.
The difference between getting feedback the same day on code you wrote versus a week later is massive in terms of productivity. And yeah, sure, developers will do other things while waiting on the reviews, but there's always going to be that context switch that you want to avoid.
Conor Bronsdon: Spend that time to get your brain back in gear and go, okay, the notes that I wrote in this code, what the heck did they mean again? What was I doing here?
Ben Lloyd Pearson: Yeah. Yeah, and not to mention, there's lots of things that, lots of practices that maybe are, they're not clear within the organization. So developers might, they might run a foul of things that need to be flagged. And so the first review could be that it is just a developer saying, Hey you missed these couple of things that you maybe you weren't aware of, or We just changed this and we haven't communicated it, or whatever.
But that causes another cycle, yeah. Yeah, that's why we made Git Stream. 'cause it's a, it's we, we wanted to find a way to help developers find reviewers get them assigned, get reviews through more quickly, unblock things that aren't as risky. And then, make sure that any sort of criteria that, or requirements that you have for your code base are being considered before you have any sort of human, spend their time to.
Conor Bronsdon: This speaks to that policy as code use case we talked about earlier, like maybe you're a financial institution and you want to make sure certain PRs in certain parts of the code base are treated in certain ways. And it's interesting you bring up what we're seeing in the data because it has been really clear in LinearB's quantitative data, but we're also seeing a ton of qualitative signal.
So not only did the DORA report highlight PRs and has highlighted code reviews for a couple years now, but we've also seen it with every major enterprise we talk to. The Netflixes, the metas of the world. They have custom tooling they're building internally. Maybe it's not as configurable, but they have stuff they're doing because they've realized it's a huge problem for them when they scale these massive org sizes.
It's clear there's a need for free tooling that can be brought out and leveraged throughout the community. And frankly, we're also seeing it in developer experience surveys where people are saying, this is a huge headache. I love we're diving in here, but for teams who are considering starting to use programmable workflows and hopefully trying to fix their code review process or other parts of their processes.
What are the headaches or challenges with getting started?
Ben Lloyd Pearson: Yeah one thing that's been there's been a few use cases that we've seen have been fairly consistent. One of them that I think is a great first bite out of this is identifying, or it's building code expertise and then assigning those experts to be the reviewer on relevant PRs.
You don't, you always got to consider the bus factor. You don't want to have a single person that's always in charge of reviewing everything because it creates bottlenecks. What happens when they're out of the office or you can't get them because they have other priorities.
So a lot of organizations are looking for ways to, to both build, build or implement policies that. Enable their team to share knowledge across the organization. And then once that has been distributed, giving them the empowering them to take reviews into their own hands rather than having to depend on a select few.
So that's been a very obvious one. In terms of like compliance there's a lot of, there's a lot of concern about one, one thing that. One use case that comes up in SOC 2 is like, making sure that you're tracking every change that goes into your code base in some sort of centralized repository.
Like whether it's your project management or some other BI solution. And, developers, once again, developers, they don't, they hate going into JIRA, but they need to say, this PR is part of this project over here. And if you can do that without forcing them to constantly have to, have multiple tabs open, switch back and forth.
Write some automation. Get URLs, yeah, just automate all of that away. It's a toil that developers just, you know, they don't want to do, they have to do it. They can take off their hands. So those are like sorts of the sort of two, two major use cases. But we really see just very broad adoption, but there's a lot of like small, low hanging fruit. Small things that you can just implement just to make your developers lives a little bit easier.
Conor Bronsdon: Is this thing like, integrating into the testing suite or CICD and trying to apply that? What are you thinking?
Ben Lloyd Pearson: Yeah, if you have a CI pipeline that, maybe you have too many jobs, or maybe you have so many jobs that you don't need them for every PR but maybe your developers are waiting on them for every PR, like that, you're just wasting their time waiting for something that may not be relevant.
Why not skip a few of them? Or only trigger them if they're necessary for the code that's being changed.
Conor Bronsdon: What I'm hearing you say is that gitStream is facilitating programmable workflows that not only cut down on manual effort, but also facilitate faster feedback loops.
Would that be an accurate way to describe it?
Ben Lloyd Pearson: Yeah we can do things like estimate how much time it's going to take to review a PR. You're a developer, you got a meeting in 15 minutes, you think, maybe I can go look at a PR real quick, and help one of my teammates.
And then you open it up and find out it's 500 lines of cha of code that have changed across, a dozen files and multiple subsystems And all you wish is oh, I just wish I could unsee this so that I can go back to the rest of my day and get on with my life. Yeah. But if you could tell them, there's that one, that's a big one.
So save that for when you have time. There's this other one over here that, maybe it's smaller, it will only take a couple minutes to review. It's a really great way to just help your teammate out super fast. So there's stuff like that. There's, finding when someone is, maybe accidentally using some deprecated APIs or something, maybe you have somebody in the review process that's gonna catch that but why bother them? Like, why not just catch it automatically ahead of time and let the developer know immediately so they have that immediate feedback about what needs to change.
Conor Bronsdon: Reduces the context switching piece.Let's be able make immediate changes. Makes total sense. How are you going about adoption for programmable workflows? I know it can be a big change for some teams. What do you do to really get folks to buy in and actually get their leadership to, get on board with these big changes?
Ben Lloyd Pearson: Yeah, find your pain point, your biggest one, and just solve for it and start there.
And then just go down the list, find the next biggest one and so on and so forth. A great place to look first is DORA. Get some DORA metrics in place so that you know how you benchmark against other organizations. Where you might have the biggest slowdowns.
I wouldn't be surprised if you find that, like we predicted, it's often in the pick up and review time. But if it's not, there's other practices that you can take. But, DORA, that's one of the great things about DORA is it's a really great value oriented framework that, that leads to these sort of natural technological solutions that solve the problems.
Conor Bronsdon: Yeah, and I'll say we were listening to Nicole Forsgren talk earlier too, about extending that and applying the space framework and saying, okay, like you've started with DORA. What's the next step for you? Is it maybe you should be paying attention to your PR review sizes? Maybe that's a really crucial early indicator for you.
Or maybe it's developer happiness through your DevX surveys. It's like a key north star metric for you. And I think that's a great way to think about it and say, okay, let's identify. The things in our cycle that we want to move faster, and then we can apply tooling to reduce those friction points to try to speed it up and make our developers lives easier.
And I think an underrated aspect of this is that if you apply these programmable workflows well, you're actually going to make your dev team feel better about what they're doing to you. It's less of the work they don't want to deal with. It's less context switching. You're going to have more good days for them.
And that opportunity is great for recruitment. It's great for retention. It's great for productivity. I love to hear it. Do you have an idea of where you see gitStream going next, though?
Ben Lloyd Pearson: Going next our goal has always been maximal extensibility. We want to be a glue in between just about every other tool in your developer stack.
That's definitely a direction that we're going. And we also, we really, I want to touch on a couple points you mentioned there, because, there's one common theme I saw, I've heard so far at this event is developer wellbeing. It's a very big concern. And a lot of that, those conversations have been centered around things like, for example, the the McKenzie metrics that focus more on like effort and output rather than any sort of like value stream, like changes.
And I think there's a lot of concern that those sorts of approaches don't really take the developer quality of life into account. They often don't. Yeah. And I feel like that's, where DORA Plus space is really trying to account for, it's like the metrics that quantify the challenges that you're facing, like that feels in the DORA realm.
And then I don't really know if they're metrics, or if it's just more of a mindset.
Conor Bronsdon: The framework to apply to decide on what you want to measure next.
Ben Lloyd Pearson: Yeah, and that focuses much more on just your organizational well being. Because we know happy developers do better, they're more productive, they ship software faster, so I feel like it is almost like a response to, we don't want to, we don't want to analyze developers in a way that, That makes them feel pressured.
We're not telling you this is the tool that's going to, increase the number of lines of code you change. We're telling you this is a tool that's going to unblock things that you might be struggling with.
Conor Bronsdon: Ideally, it should reduce gamification metrics. Because I know that's a big concern for a lot of engineering leaders, and it's a valid concern.
Goodhart's Law says that when you start setting goals against measurements, you're going to see them improve, but, it's a lot easier to create one ten pound nail than... A million small nails. So you're like, great, I need to create 10 pounds of nails, let's do one big one. You didn't specify.
And that gamification is not what we want to see. We want to see a process that moves faster and works better for everyone. And so gitStream's a great way to say, let's put tools in the hands of developers where they can set the process up in the way that they need to have it done and also fulfill the needs of the C suite and say, okay, great, now policy is code for compliance.
Awesome. And now we have higher efficiency throughout our pipeline. Fantastic. We deliver more software faster, more predictively. But ideally it needs to be one where it's we're putting in the hands of devs and making their lives easier. And so I love that approach is being taken.
Ben Lloyd Pearson: And I would love for us to get to a place where we can surface those insights to the managers.
So we can say, they can log into say their linear B dashboard, get their DORA metrics, and within that, see some sort of breadcrumb that says, we've detected that. There's an issue over here, there are automations that you could implement to solve that. Or maybe we have some knowledge of base resources that are beneficia.
Conor Bronsdon: So obviously I think we're both just big fans of programmable workflow tooling, and I know we're talking about LinearB's gitStream in particular, it's free, it's available. What are some of the integrations that are set up already in gitStream that people can start to leverage?
Ben Lloyd Pearson: So we've been hard at work building out a pretty robust integrations marketplace.
Like I mentioned, we really want to be the glue between a lot of popular developer technologies. So we're looking at your project management stacks, whether you use Jira or Asana or Shortcut. We're finding ways to integrate with those. We've got, we recently built some integrations with one of my favorites, the new, our new integrations with GitHub Actions, which lets you orchestrate your CI pipelines effectively, so you can decide that, if, let's say this code changes my mobile app only, I only need the mobile build process for that, so I can choose to ignore the rest and just run the processes that I need.
So that's a huge time saver that I'm really happy we were able to ship. Thank you. We also have now enabled outgoing webhooks, so you're able to connect gitStream to practically any service that has an API. So if you want to send Slack notifications, if you want to auto update JIRA tickets, if you want to send a PagerDuty alert, whatever tool you want to send some sort of alert from your Git repo or from a PR we can now enable that.
This list is only going to grow. I encourage people, if they want to check out what we're doing, just to check out docs. gitStream. cm. Where we're building out all of our integrations.
Conor Bronsdon: Fantastic. Ben, this has been a wonderful conversation. Thanks for giving us an update on what's happening in programmable workflow land.
Very excited to see where this goes in the next couple of years. To your point earlier, I think it's... This is a crucial thing that we're seeing being called for in a lot of fun, and especially doing it in front of this live audience, people walking around us here in the Dome at DevOps Enterprise Summit in Las Vegas.
Thanks for listening, anyone. And if you are interested in gitStream, as Ben mentioned, docs. gitStream. cm, learn all about it. You can add it to your GitHub right now. And yeah, thanks so much for writing out those great docs, Ben. Thanks for coming on the pod and we'll have you back in soon.
Ben Lloyd Pearson: Yeah, absolutely. Thank you.
Conor Bronsdon: And if you're listening to this and you want to see Ben and I flail around, actually hit mic stands, maybe have some bloopers in here and we'll hopefully edit some of those out. Check us out on YouTube. We'll put the clips on LinkedIn as well, but you'll definitely find the full video on YouTube.
It's a lot more fun to see the experience of what we're doing here. So thanks so much for listening to y'all.