Justin Reock,Gradle Inc. | KubeCon + CloudNativeCon NA 2022

This is Textron TV. I told you we'd be back. We're back here.

We are at kubecon 2020 in Detroit City Motor City. We're back having great more great conversations. I'm really excited about this because we talked about really developer and developer productivity.

So I'm joined by Justin react. Yeah. I feel she tell with great cradle.

That's right. Yeah. Thanks Mitch.

I'm really happy to to be here talking to Textron. So it's great to talk with, you know, we talked about devops all the time. But developer tools aren't necessarily devops tools always right.

I mean, we have our own capabilities and Suites of tools that we use whether we're doing devops or not it fits within an advert but developers such a valuable resource and you know, they're not just a widget to do Purdue sex amount of work, but we want to make sure we're not wasting their time on stupid stuff there. They're able to do this stuff that they do really, well. Absolutely.

It's funny to me that for all of the Progress that we've made with devops over the last five years or so in terms of productivity for organizations and that and when you can you can tell how firmly rooted devops practices are in. Practices that have come before it, you know, I loved I love drawing and like I call it the ancient business wisdom of the 70s and 80s, but you know things like the theory of constraints and the work of Eli Gold rat and how that would fold into different ways of thinking about productivity. We've made all of these huge leaps.

And yet we've completely ignored these still like massive sort of extant bottlenecks that are just hiding in plain sight in the developer experience, you know, like why after all of this progress, do we still talk to developers who are waiting an hour for a test cycle to complete? Yeah or spending and tired days trying to you know, diagnose things like flaky tests, you know, so so it's it's funny to me. We made all of these leaps forward and yet in some ways sort of Left Behind like the essential component of all of this, which is the person actually sitting there writing code.

So maybe there should be the automating devops workflows. And yeah, I mean those are important too but I'm curious so tell us about cradle what you do which which you're focus is first so we make sure folks know about you. Yeah, absolutely.

So I think most people know us as the Gradle build tool which is the open source part of our business and we do employ about 50 full-time Engineers who work on Gradle build tool as part of the open source project. We also have a completely separate product called Gradle Enterprise, which is a set of enabling technologies that promote this practice of developer productivity engineering which is really starting to hear more about this. It's emerging out of the Bay Area but companies like Netflix have been practicing this for about five years LinkedIn followed up pretty shortly after Netflix.

So it's still a relatively new process, but effectively what we're doing is providing acceleration and observation and analytic Technologies that'll Focus specifically on improving developers ability to sort of stay in Low state right. So removing unnecessary toil from the developer like waiting 45 minutes for a test cycle to complete or like dealing with tests that are flaky or non-deterministic. So this separate product it's named Gradle Enterprise which we struggle a little bit sometimes with that naming because you look at it.

You're like, oh, what is this? Like the open core model for Gradle? Is this like Gradle plus and it's actually a completely separate tool it integrates with Gradle, but it also in a grates with Maven it brings feature parity and all of the same type of productivity Improvement Technologies to Maven that we brought to cradle as well as the basil build tool.

By their totally a total aside, you know, you've made it. I mean go right it's not around anymore. But his book the goal is now in a graphic novel.

I have it. I have it on my bookshelf. Yeah.

Well, it's it's one that I really like to recommend to folks who are kind of coming into this space specifically around productivity because at the end of the day, you know, the whole inventory costs throughput model. I mean, it's an excellent model right the models in general anytime that you can use the laws of physics to try to predict Behavior within an organization. I love that approach because you can't break the laws of physics.

So it's a very reliable way once you apply the right features to the right equations to be able to say, you know, this business is either gonna succeed or this new practice is gonna be good for the business. But you know what we all have in common these like practices that have stuck around and really stood the test of time and and, you know become mainstream practices is that one thing to do they decrease cost and increase throughput in every case and if they do it's it's a winner so, you know anything that Found is people don't write software kind of don't understand what it what kind of mental state you have to kind of get into to be productive and I was equated to it's like riding a book. If you were going to work on the next page of a book, you know, just start writing kinda have to get yourself back into the story understand where you were pick up from right there.

And then then you can be productive and that context shift of waiting for that 45 minutes going to working on two or three other things. There's another can be 15 20 minutes just to get back to where you were to take the next step. And so that productivity isn't just that 45 minutes.

It can be the 15 minutes on side of it and you do that for fine time today and you're not getting any work done. It's the brain has actually been mapped. I don't know if you've seen some of these experience but what developers are sitting the writing code, I have not and you should check it out.

It's really interesting and it's this wonderful sort of ecstatic soup of left brain and right brain activity happening at the same time. What you're talking about is a state of creative flow, right and That's a big part of efficiency and we talk a lot about this in the practice of developer productivity engineering. You know, we talked about a 45 minute build time.

But what about the toxicity of a 10-minute build time even in that 10 minutes the developer doesn't have any time even to pay that context switch tax that you pay right? So I mean, you've got this Flow State where you're creatively solving problems you're looking at a problem. You're visualizing it you're trying to solve it and then you've got this scientific analytics side of the the work where you're then sort of making this hypothesis with a build tool chain.

Hey did the code that I just wrote adequately deal with this problem that I've visualized in my head and then we wait for the build tool chain in that dialogue to give us some kind of feedback that we've done the right thing. And so If we have a feedback coming in 30 seconds a minute, right? We're good.

We're staying in our Flow State where we're happy. We're where we want to be as developers. But even the the 10 minute crawl 10 minutes you you can't do anything right?

I mean, what are you gonna do like, you might check emails for a second. You may come back and abandon the work entirely but either way you're out of your Flow State, right? Well, you may squirrel down one of those paths completely and yeah really starting over no exactly and but that this is really what the process is all about.

It's looking very closely at the value stream that's zoomed in just to the experience of writing code again, and then figuring out where are these opportunities for developers to be pulled out of their Flow State and then doing something about it using technology to actually do something about it. And you know, it amazes me, you know, I speak to a lot of different audiences about this subject and I always ask one question that really shouldn't be so provocative but it is who in the audience is tracking local build times when the audience is actually aggregating up how long Developers are sitting there waiting for their projects to complete and it's still just crickets. Nobody like nobody's even looking at this one metric and it's it's it's fascinating to me because that one metric really is I think the best quantifier to developer experience and and if no one's really looking at this then how can we possibly hope to improve it?

Right 3,000 year old adage what gets measure gets improved but it's this true now as it was back then and it's it's a metric that I think I think the whole industry is just kind of gotten in nerd to this problem where it's like no this is just what it means to write code. You have to deal with these occupational hazards of the job, you know, you're gonna deal with long build times you're gonna deal with the inconsistent or unreliable build tool chain, but I think our argument is like it doesn't have to be that way right we can we can use technology to to improve this talk about theory of constraints There's a constraint right there. Absolutely and it's becoming a primary constraint, but I think it's absolutely none of this is try to is to try to demean that the the the great progress.

That have been made through devops tooling and devops mindset and philosophy. I I love that mindset. It's really important.

And if you look at some of the biggest blockers to productivity and throughput for a business that we had five years ago 10 years ago. It made sense that a lot was being lost in productivity and just the act of deploying the software or trying to enforce quality and security, you know, but now now that we've done a lot of good work to improve those problems the primary constraint is shifted even further left and now we're dealing with the basic stuff like again idleweight times and and unnecessary toil so you tell me we've taken build Friday and carved it up into a bunch of little pieces happening always right through the week There's still waiting for those builds imagine that small frequent incremental change sets, which allows us to refine our work more often. Right?

I mean the more we can ask for that feedback and the more often and with the smaller change set that's the the deeper psychology of what happens here. And I think it's like obvious to say, okay, it's great to developers aren't wasting time waiting for code to build but what really happens well when developers know they are only going to 8 30 seconds, maybe a minute for something to complete or even less than that. Ideally.

Well, they're likely to build more often more frequently. Push smaller change sets which is gonna mean it's gonna be easier for them to figure out if they broken something because they're dealing with a smaller amount of code down the line when we actually push that code it's going to be as smaller change set less merge conflicts. So there's all these cascading impacts that come out of this just improving this, you know, just this one metric this team.

I maybe I'm sure I'm oversimplifying but it seems like build time should be a resource that you could easily add more resource too. Right whether it's local or distribute or put in the cloud or some combination. You're not stuck where you are.

I mean you can you can get more resource to help with that absolutely and it's not even necessarily a question of using more resources, although accommodation of this is really good. So many build systems are still not as efficient as they could be, you know, like so one of our acceleration Technologies is just build caching which is different than dependency caching. It's not like artifact.

Pository it's not like a J frog or a Nexus or something like that. It's instead. It tasks outputs from Individual phases of a code build so that if you are for instance making a small incremental change to this part of the build and you have an impacted all of these other areas, you don't have to rerun those parts of the build again, and we also have predictive test selection which was incubated at Facebook and Google and published in a academic paper back in 2019 uses a machine learning model to take a look at a corpus of tests that need to be run by the build system.

But it takes a look at the history of changes that have been made to the source code and what those changes have done in the past to the test set and makes it prediction. It says okay. Well, there's really a very low likelihood that if you run this test it's gonna produce any valuable output for you.

So don't run it and developers already do this manually, you know, they'll go and make me oh, I don't need to run that test. And yeah, but now this takes, you know, even that part of the thought process out of it so we can make the builds more efficient and then where we still need the processing power. Lutely, we can then distribute them, you know, so our test distribution approach kind of this three acceleration accelerator approach that we've got right now.

We'll take any tests that still need to be run after benefits from caching and benefits from the predictive model and run those in parallel across multiple elastically scaling agents in kubernetes. So so it's a combination of using the resources asiciently as possible. And then where we still need those resources making sure that we can take advantage of things like elastic work on the part of the problem not really use worked on at the rest reassemble, right?

Yes, and we talked about the part of the code that doesn't ever get executed. That's all another right but Justin Justin rear filthy seal with Gradle. Thank you so much.

I appreciate a great conversation. Have a great show to and we need to have you come back. I would love that.

Yeah, I would love that nature really get more into this because it's I think you know, the developers world is fascinating and it is such cool stuff and great work and it's always fun to look at what's happening inside that process. Us in the time is is now I mean right it's six you've probably heard the statistic I'm sure it's been thrown around that we are now living in a 65% digitally transformed Global GDP, actually, I believe it I mean that's and so that we have so much we have this this debt of code that needs to be written and it's about time that we really focused on developer happiness and developer Joy which will lead to better productivity. We're now in the business strategy not in the back office.

I love that. There you go. That's awesome.

Thank you Justin. Thank you. We will be back here real soon.

Hang tight. We're back real quick. We got more great conversations just like we had with Justin so that same bad Channel same bat station.

Don't go away. We'll be here.