Develocity: Improving Application Developer Productivity – Baruch Sadogursky, Gradle

This is Textron tv. Hey guys, thanks for the throw. We're here with Baruch Urky, who's principal developer advocate for Gradle, and they've just recently read Christen their enterprise product into something called Dev oss.

And we're gonna talk about all good things related to developer productivity. Baruch, welcome to the show. Thank you.

Thank you, Michael. Okay. Glad to be here.

All right. I think people are generally familiar with your build tools, and now there's this renamed enterprise tool, but walk us through what's going on here. What's the difference and why did you feel the need to have two different names?

Yeah. So, uh, the, it's all started with Gradle, the build tool, Hans doctor, our CEO, and, and, and founder wrote this open source build tool back in 2000 and, I guess seven, eight, something like that. I heard the first time about it in, in around 2009.

And, uh, became like a huge fan since then. It allows a much more control and flexibility, um, and, and power to your build. This is something that I've been passionate about since I joined Alpha CP company that, um, uh, specialized in CICD pipelines back with Ant and Open Source Hudson.

It was very long time ago. Uh, but since then, passionate about all things delivery, CICD, which obviously, uh, took me personally to J Rog and, and took Gradle, the, the, the company, uh, to kind of come about with services around, uh, Gradle build tool. Um, in some point of time, uh, Gradle realized that while it is important to have a great tool for improving your build, the entire space of developer productivity, engineering is actually more than that.

It's not a, it's not, uh, only about, uh, gradle. It can and should be achieved and strive to with every build tool. Um, if we're talking about the JVM ecosystem, um, developer productivity engineering should be a thing for Maven.

It should be a thing for basal, it should be a thing for SBT as well. And you know what, it's not only the Build developer productivity. Engineering is all about your entire, um, developer experience, which means the way you write code, the way you test code, the way you build code, obviously the way you ship code.

It's about, it's about all the aspects. And, and that was kind of the idea behind what used to be called Gradle Enterprise. How do we take the success in developer, um, engineer in developer productivity engineering and take it from the build tool to the level of the entire enterprise.

Um, so, um, the Grid Enterprise came about, um, it came out in 2000, I think 18 or somewhere about, and, and it was mostly centered about giving more in the aspect of build, but things then, um, the, the tool added features that deal with testing that deal with observability, that deal with like a managerial o oversight and, and obviously expanded way past Gradle and now supports Maven and Basil and, uh, even SBT, um, in the, in beta. So it kinda, we had a tool that is not only gradle and it's not only about enterprise, so the name, the product anymore. And, and this is where we decided that we need a better name.

And the velocity is a name that expressed exactly that it's improved velocity for your entire developer experience. Mm-Hmm. We hear a lot more about developer productivity these days, but I feel like it's always been an issue.

I also hear a lot more about the phrase platform engineering, which is some sort of attempt to centralize the management of DevOps. Um, what's your sense of what's going on here? I mean, uh, these problems have been around forever and a day.

What's changing? What's, what's fundamentally different? This is, this is an excellent question, and, and I think the answer is, we now mature enough to pay attention.

And if you wish, here is a hot take for you. We figure DevOps out tools. Well, you know, there are tools for doing DevOps, Kubernetes and what's not.

Um, and, and platform engineering is kind of the last piece of the puzzle here, which frames the engineering aspect of DevOps around the right things around the platform for doing DevOps. Um, I personally hated and still hate the term DevOps engineer. It doesn't make any sense to me.

Um, it's a collaborative practice. It's not an engineering practice. The engineering practice of DevOps is actually platform engineering.

So now I feel that we have a complete vision of how software should be delivered. For example, in the Phoenix project, they were real and had to be solved. But now if you look for the answers and you look at the right forward-looking companies and forward-looking teams, and, you know, third leadership, uh, thirdly, there's individuals, you know how to solve it.

And I think it's time for us to look for the next bottleneck. And you remember right, the, the theory of constraints optimize at the bottleneck. DevOps delivery was a bottleneck.

We know how to solve it. Next bottleneck is, okay, how, let's look back at the developers and see how they write code, how they produce the product that will be delivered through, through, through DevOps. So we are looking at, okay, we know how to deliver software.

Let's solve the bottleneck of writing software more efficiently through developer productivity engineering. Um, more people embrace that. 'cause sometimes I feel like a lot of smaller development teams embrace DevOps because they didn't wanna be subject to central it.

And so how do we kind of get the benefits of a central motion in a way that doesn't alienate people? I, I think in the end of the day, it's about the results. All we do is for Cargo Cult, we do it because everybody do it, and it actually harms the individuals, the company, the product.

Then of course it won't, uh, it won't stick. Everybody will hate it and will be, will be painful. But in the end of the day, if DevOps is about better delivery experience for everyone, and DPE developer book engineering is about better development experience for everyone, it'll be embraced because it's doing good.

And you know what? For developer productivity, it's even easier sell than DevOps because the, um, the benefits are so obvious. People want to get better.

People feel the pain and the solution is straightforward. For me, this is one of the reasons why everybody are talking about developer productivity, developer experience, and, um, those kind of topics. Because, because it's out there.

In my personal experience, I go out there and speak with developers about DPE and about Velocity, and people are like, Hey, take my money. But it's absolutely clear what you try to achieve, and we see that your product actually helps us, uh, elevate our experience. You mentioned, we finally wrapped our arms around DevOps, and yet I feel like we're on the cusp of some other transition involving generative ai where there's gonna be a lot more code moving through the system.

The builds are gonna get bigger than ever. So, um, you know, we moved the goalposts all of a sudden, and what do we do about it? I am, I'm only happy that we managed to figure out DevOps before the avalanche, right?

I mean, if, if AI revolution came at us like 10 years ago, that would be like a real disaster. Remember, people who released from their own machines, uh, yeah. Uh, it wouldn't be, it would be, it would be a catastrophic, but, but now with DevOps, we actually can do it.

We have the tools to, um, absorb, uh, kind of digest and release. Geez, that was a very, uh, interesting analogy. Uh, all, all this code that AI generates successfully because of DevOps, thanks to DevOps.

And, and, and at the end of the day, it's just about the scale, right? If we know how to release software, we know how to release software. Again, I'm not saying that everything is perfect or everybody in the industry are the elite performers by Dora report or, or Space metrics very far away from that.

But I'm very well aware how huge part of the industry are even behind. But it only takes an organizational will to find the right answers. What we did as the industry, and I'm very proud about it, is that we found the answers that look like they are working for the forward looking teams for those, um, elite organizations.

And that means that everybody in the industry can replicate it simpler or harder with those hurdles, organizational harder, uh, hurdles and maybe cultural and mental, uh, hurdles. But in the end of the day, if you want it hard enough, you know where the answers are. This is what I mean by we kind of figured it out.

Not that everything is rosy and everybody are doing the, you know, the perfect thing. Do you think that AI will be applied to the DevOps workflows themselves to help even things out a little bit for folks? And whenever we can throw AI out, uh, at, we'll do, the question is, will it generate the, uh, improvements that we're looking for?

And I think it will. I think it will because, uh, AI is about pattern recognition. Pipelines and quality gates are about patterns.

In the end of the day, if we can turn the AI to a tool that can help us automate quality checks, does it consistently with good results, that would be a tremendous improvement in the overall quality of software that we see. And this is what I really, really look forward when we look at what AI can do for our DevOps and software release practices. So what's your best advice to folks then right now?

I mean, it seems like everybody's scratching their heads a little bit with this whole shift. I mean, how do you go after it? 'cause I think it's a little intimidating if I start thinking about platform engineering and then I'm starting to think about ai.

What should I do today to get prepared to do this right tomorrow? I, I think it's, it's the same as always. It's the same in the nineties.

It's the same in 2000 and 2000 and tens. And the answer is, take your risk. This is the only thing that it that matters.

You don't rest on what, you know, figuring out, okay, I know this programming language, I'm good, or, or I know this technology and it's fine. You have to stay curious because the industry is running forward, leaping forward, and if you just stay in place, you actually fall behind. And, and this is something that, um, now we used to evolve DevOps, for example, right?

10 years ago, if you heard about DevOps, you were in a great position to do great things either through maybe a startup around DevOps or DevOps SecOps, which in some point of time was bound to be successful, right? Or through a better position in your organization or a career change that will make your position much better. And, and it is the same today with, uh, with ai.

You, you stay curious. You learn about it as you learn and you see the opportunities because the opportunities are there. And this is one of the most exciting things in, I mean, in the IT industry.

The, um, frontiers never stop, right? You always can be there at the new frontier and discover the opportunities that frontiers by the nature of them being frontiers generate for, for, for you. And, and all you need to do is just to be there.

And that means being curious and, and, and staying up to date. All right, folks. Well, you heard it here.

It's kind of just like the most interesting man in the world used to say Stay curious my friends. Hey boo, thanks for being on the show. Thank you.

Thank you, Michael for, for having me. Cheers. And uh, yep, improve your productivity and stay Back to you guys in the studio.