 Welcome to today's Postgres Conference webinar, the first in a series of three with Justin Ryock, Chief Evangelist, and Field CTO at Gradle Enterprise. Today in Episode 1, Introducing Developer Productivity Engineering, we're going to discuss the emergence and adoption of DevOps practices at scale, following constraints-based approaches such as Agile and Lane, an overview of hidden productivity bottlenecks that still exist in our common built test and CI practices, how observing and tracking KPIs can help your organization accelerate these tasks and greatly improve developer focus, and developer productivity engineering, DPE, and how to begin implementing these practices into your own organization. My name is Lindsay Hooper. I'm one of the Postgres Conference organizers, and I'll be your moderator for this webinar. A little about your speaker. Education is an outspoken blogger, speaker, and free software evangelist. He has over 20 years of experience working in various software roles, and has developed delivered enterprise solutions, technical leadership, and community education on a range of topics. Welcome. A few quick notes for our attendees, and then we'll get started. So the first is that I put all attendees on mute to avoid background noise and to preserve audio quality. And the second is yes, we are recording this webinar, and it will be accessible on the Postgres Conference site by the end of this week. So with that, I'm going to hand it off. Take it away, Justin. Thanks so much, Lindsay, and thanks everybody for attending today. I'm really excited to talk to you about this subject. Do you know it's, it was interesting when we were first talking about how this webinar might really play into Postgres Comp's webinar series because I've been involved in this with this series in the past and with the Postgres conferences in the past, representing my previous company OpenLogic. And that was a pretty straightforward relationship, right, you know, OpenLogic providing support for free software, Postgres being, you know, the premier enterprise open source database. And so in talking with Lindsay about how we could, you know, kind of talk about the subject here, it actually became really clear just through the conversation, you know, what we are doing is a very data driven approach, as you'll see, to improving overall productivity. Engineering in developer productivity engineering is a verb, right. In other words, we are applying engineering principles to help with developer productivity. And so it's very much about data. It's about aggregating data, as you'll see, and taking actions as a result of that data. And we also use Postgres as our backend database for the product. So we have that as a bonus. So it actually was interesting at first, you know, I was thinking, oh, is this really going to be a fit and let's play around with it, but really in talking through it and understanding the spirit of this conference, I think you'll find that it actually is a very good fit and that we're doing some very interesting things with data analytics in this practice. So speaking of the practice, I kind of like to start with this quote from Eric Pearson from Intercontinental Hotels Group. And there's some variants of this quote floating around, but it's no longer the big beating the small, but the fast beating the slow, okay, it's no longer about being the big software corporation that has all the assets and all the features and functionality. It's about how fast you can adapt your business, right. It's about how fast you can react to changes in the market and how fast you can get new features out. So let's be pretty clear about the problem that we're trying to solve then with developer productivity engineering, okay. We know that the process of writing software is a very feedback focused process, okay. I like to think of software programming as a combination of a creative process like writing, but also a scientific process. Because as you are finding the most efficient ways to use the language and frameworks to sort of achieve your goals, you know, at the same time, you're trying to figure out whether the changes that you've made to the code actually do what you wanted it to do, right. So each time you put out a new line of code, you're kind of making, you may not think about this anymore if you've been a seasoned developer, you've been a developer for a long time, but you're hypothesizing and you're trying an experiment, right. You're saying, I think that if I make this change to the code, it's going to do this thing, then you run it, build it, whatever it is, wherever you get your feedback from nowadays that may be a CI system or something. And that feedback either confirms or denies that you did the right thing, right. So it's a feedback cycle. And we know these are incredibly important to developer flow. But what do developers commonly run into with these feedback cycles? Well, sometimes the feedback cycles just take too long. Sometimes the build just takes too long, right, or the test cycle takes too long. Sometimes it takes too long to fix, right. Sometimes you get feedback that's, well, I got a failure in the build system and now I have to go take off my code writing hat and put on my troubleshooting hat and work with the build engineers to figure out what's gone wrong. And moreover, a lot of these failures could have been prevented if somebody was tracking them, right. If there was someone in the business that was actually paying attention to and aggregating data about various failures across the developer organization and data about the velocity of certain build scans and test feedback cycles. If somebody was actually aggregating the stuff, then a lot of these pitfalls and bottlenecks to productivity could have been prevented in the first place. And when you take these little micro kind of micro interruptions, right, that interrupt a developer's creative flow, they really can add up. And you start multiplying that by multiple days per calendar year and hundreds of developers, you find that although DevOps, I think, has taken us far in understanding how constraints based theories like Lean and Agile have really helped with productivity, there's still a lot that we can do. There's still a lot of sort of dark costs that are really sort of hidden in the developer experience and don't often leave that developer's workspace. And so because they're not felt necessarily at other areas of the business, they're not necessarily addressed. Fundamentally, software development is a creative process. And when we first started out, a lot of us who started out as developers in this field felt this way when we would make an accomplishment with the software that we're working with. But the early programs that we played with, the early bits of code that we wrote. Well, they would compile immediately and give us feedback immediately, right? And they weren't solving sophisticated business tasks. They were Hello World programs where they were changed the background color programs, but we got this kind of joy. We got this kind of dopamine hit out of that immediate reward and benefit in having a hypothesis and seeing it proven true. And that for so many of us is where developer joy comes from. That's where so many of us find this to be such a rewarding field. It's in this reward of validation of the work through software feedback. But enterprise development has changed the landscape for a lot of us. Enterprise development has created a unique set of challenges that can interfere with developer productivity and ultimately take some of that joy out of the process. Because you replace a lot of that immediate feedback with waiting and idle time. You don't get the flow that you want when you're having to code in a sort of herky jerky manner. But I think a lot of us have taken that for granted. And where these interruptions have come from, where the inefficiencies and the feedback cycles and things like that, ironically, are generally a result of project success, projects that have grown in terms of the number of lines of code or the number of developers who are working on the project, the number of individual code repositories that are needed to house all the source code for it. The overall diversity of the tech stack. So the success of a particular project within a business will lead to degradation in the tool chain just by nature of what's happening. There's more code that has to be compiled. There are more dependencies that have to be pulled or built in. There's just more work that has to be done by the build process. There's more tests that have to be run as the code gets more sophisticated. So as projects grow into enterprise scale projects, right? I mean, enterprise software development really is what's creating a lot of these challenges, then these feedback cycles that we're rewarding to developers can get worse and worse over time. And as we find, there's just not a lot of companies who are doing their diligence in terms of aggregating this type of data and really taking a look at this part of the developer experience. And not just as a one shot like, hey, this is slow, let's speed it up. But as a continuous process of, hey, okay, we optimize this, we made this experience better for our developers. But let's keep that up. We don't treat this as a one shot deal, right? This is a practice. So success for DPE is pretty straightforward, right? It's giving developers hours back in their work, in their week to work on unvaluable solutions for the company, work that actually makes them feel good, right? Troubleshooting builds with build engineers is just not the most enjoyable activity for developers to have to take part in. And it's not because the developers don't like solving problems. Developers love solving problems. It's the methodologies that we have in place to help with these troubleshooting. It's just not as efficient as it could be. Oftentimes build engineers are still just taking some console log output from Jenkins and copy pasting it into Slack. And that's the level of collaboration that's happening between the build engineers and the developers. And the build engineers are asking a million questions. What was the build environment like? How many threads did the system have? What operating system was it? And there's just all this back and forth that's just really a time sink and just not very efficient. And here's the thing. There's a broader appeal here. We know that by 2022, IDC has predicted, and this is a study that came out, I want to say October of 2019, if I'm not mistaken. But the study came out, excuse me, October 2020, excuse me. Study came out and has basically said that by the end of this year, by the end of 2021, by 2022, 65% of the global GDP will be digitally transformed. 65% of the goods and services that we pay for will be software. Goods and services will be digital in some way. It's 2 thirds of our world almost, right? It's accelerated certainly as a result of COVID or as a result of the pandemic. But that doesn't change the reality that a great deal of the quality of our life is directly driven by the work of software developers. And so we owe a certain responsibility, I think globally, to do everything we can as business leaders or as people who are in support of those who write software to make their experience as best as possible. It's a responsibility at this point. And it extends beyond just matters of GDP. A lot of you may be familiar that recently a new neural net was able to come up with all possible protein folding combinations for the entire human genome. If I remember that study correctly, it was predicted it would take an extra decade for us to do that. But because of an advancement in deep learning methodologies, we were able to accelerate that work and now sort of lifting all boats in the harbor as a result of that. Okay, so yeah, the outcome of DPE has a tactical outcome of giving developers back a time valuable time in their week to work on valuable things. But this extends beyond productivity, right? It really extends into developer happiness because if you look at what is frustrating developers, I like to think that frustration is sort of the opposite of I wouldn't say it's the opposite of joy, but it's certainly not pleasant and it's certainly not what you want as part of a creative experience. And if you look at, in this particular survey, what respondents and this would probably resonate with a lot of you who do write software. The number one source of frustration here was just waiting for CI pipelines to run. And then after that waiting for builds and tests outside of CI pipelines to complete, these are those feedback cycles that I mentioned earlier, right? So this isn't our theory that's saying that businesses need to spend time establishing a discipline for developer productivity engineering, right? This is, I think, something that is kind of known and felt in the market. But that a lot of developers and practitioners have become in some way sort of numb to, and I can certainly remember for my years and years writing software that the reality was that builds just took a long time and tests just took a long time and that's just part of the job, right? But when you think about how much better they could be when we start looking at some of the applications that we have in this practice, you know, you realize that there are things that we're still not doing. We've done a lot of good things, but there's a lot that still needs to be done and developer productivity engineering focuses on, again, on a lot of those bottlenecks that just haven't been addressed. So we stem from a few basic beliefs here. First is that teams work far from their true potential. I believe this deeply having worked with many software teams as a trainer, as a consultant, you know, as an analyst, as a fellow troubleshooter. I see these common pains that are still felt by so many developer teams that just aren't being focused on. So much great work is being done in terms of deployment now. You know, we have businesses going multi-cloud through Kubernetes and that's becoming easier and easier for businesses to latch on to. But there's still so much potential that can be derived from software teams when we really pay attention to helping them engineer a better built infrastructure using data. Developer productivity affects developer happiness. Nobody wants to show up to work and have all the wrong tools for the job. Okay, people come to work to succeed, especially creative individuals, right? Especially people whose job it is to create assets for a business and to create code for a business. They show up wanting to know that their work has been meaningful. And when they can't be as productive as they can be, that frustration directly affects developer happiness. And low developer productivity is blocking business innovations. The world could be turning at a faster click if more businesses were gathering the type of data that we recommend with DPE and taking action on that data. All right, so let's put DPE maybe in a little bit of a historical context before we really start talking about the specific practices that will kind of help businesses, you know, eliminate some of these bottlenecks and make developers happier about what they're doing. So we started with just in time manufacturing back in the 70s. Now, this is, you know, absolutely a well-known practice that came out of the theory of constraints. For those who have read the work of Eli Goldrat, like the goal, or if you've read the sort of more modern alter ego of that book, The Phoenix Project written by Gene Kim, a very, very prominent figure in DevOps. You know, you'll know that the constraints base theories for improving the productivity of a business, although they can get a little bit complex when you start getting into some of the deeper theory. At core, the spirit is really just about finding and then eliminating bottlenecks within and in the case of just in time manufacturing, the manufacturing process, but fast forward to DevOps. And it's really just about improving, eliminating bottlenecks in the software development process, constantly delivering, you know, CICD principles, automate everything, difficult things are hard, so do them often, right? I mean, these are, these are familiar principles, but they came out of the theory of constraints. And the theory of constraints talks about, you know, any business or really any complex system, I should say, for those who aren't familiar with Goldrott, who's not a business person originally, he was a physicist who applied complex mechanical principles to corporations instead. And he says that any business really has three basic components, concepts, things to think about, that's inventory, that's cost, and that's throughput. And the job of a business is to convert inventory to throughput as fast as possible. Now, in the case of manufacturing, that means we take the raw materials, we take the parts, we put them through the various centers of the factory, and we end up with a finished product that's boxed and ready for sale and actually is sold, right? Very important that, that, you know, in the theory of constraints, that we don't really consider any inventory to be valuable to the business until it's been converted to throughput and it's been product that's been able to be put on the market and sold. Same is true for software, same theory. We say code that is laying around being maintained and has not been converted into money yet becomes this toxic substance called work in progress and basically can be, you know, create no visibility in where value is being created for a business based on the productivity that's being put into it. Now, all kinds of stuff is happening right now around this subject. You've probably seen a million reports come out over the last few months about value stream management and how 2022 is going to be the year of value stream management for DevOps focused businesses. And this is very important because all of this stuff, you know, we can put it in these, in these tactical business terms that really talk about, you know, creating value and creating money for businesses. But they're all really conversations about data. I mean, value stream management is a highly data driven process that tries to create almost a digital twin, if you will. I mean, it does try to create a digital twin of the organization and then be able to model revenue streams for that digital twin to be able to say, you know, OK, if we, you know, spend some additional marketing dollars on this one, one event that did really well for us, you know, we should be able to after the actual work involved, after we pay the employees who has to have to do this work and after we maybe pay any services that we need to produce this thing. You know, how do we then know by tracking leads or whatever that this work actually created more value for the business, right? It's very important to be able to have this visibility. And it's it's 100 percent a discussion about data and how we can model data to discover bottlenecks in the organization and to figure out if new practices that we put in place for the business actually achieve the goal of creating more revenue for a business. OK, so it's it's a it's a practice that's becoming very exciting for business leaders. But it's also a practice that should be exciting for data professionals because it's very challenging. There aren't a lot of great solutions out there right now. I remember just a few years ago, you know, going to to my own chief revenue officer and saying, hey, what do you normally use? I want to try to I want to play around with with some value stream map stuff with our with our team and see if we can make some improvements. And he told me like, I usually just use a spreadsheet. You know, but if you look into what value stream mapping really is, I mean, it's a highly visual or at least to be effective. It's a highly visual practice. But anyway, it's a data driven practice to and developer productivity engineering is taking these constraints based approaches that started with JIT and that turned into Agile and DevOps and pushing it, continuing it further left into the developer process by by gathering more data about the developer experience. And more importantly, proving out and validating that changes made by the organization improve the situation for developers. OK, there's a long, you know, kind of long introduction there. But I feel like it's really important to draw these theories back to, you know, their predecessors to understand that this comes from somewhere. This continues from principles that have been well established in DevOps. OK, so when we say developer productivity engineering is the next thing, we really mean that very literally. It's using acceleration technologies and then the accumulation of data and analyzing that data across the business and using that to address the next set of bottlenecks in software productivity frictions and slowdowns in the developer experience often are often caused by unreliable or slow build infrastructure and they can represent these black holes to productivity. But just they're just not in scope for DevOps because they're not really part of CICD necessarily. They can augment CI and make CI a lot faster, right? But they're just not they're just not parts of the mechanism that are that are considered by the overall DevOps philosophy. So to kind of think about this in context, because this is a new concept, right? I want to first, you know, repeat what I said earlier that when I say engineering is a verb, I mean, it's a verb, right? It's not engineering as a practice. It is engineering, better tooling, better infrastructure, better builds for the developer experience by gathering data and by implementing acceleration techniques. OK, so put into comparison with what might be considered more traditional productivity management, sometimes called developer productivity management or DPM. DPE would focus on process and technology, right? The speed of the build scan, the speed of the test cycle times as opposed to measuring the people themselves. So we're not going to ever be looking at things like lines of code or story points, you know, a developer, an agile team. The outcome of implementing developer productivity engineering would be a higher capacity for story points per sprint or a higher developer velocity index or something like that. That would be the symptom. But that's not what we're focusing on. We focus on the process of the build itself, the technologies that are used in that build and gathering data from it. So our metrics are going to be based on outcomes, right? Not just the general activity that we see. We want to understand that we doubled the story point capabilities for a team. You know, we'll focus primarily on the build and test parts of the process, although that may be changing a little bit as we start seeing developers rely on, you know, things like canary release feedback and production, an actual production feedback to kind of guide their development. But for right now, that's not really the practice. And so we look at really just up to the CI build and test is where we focus DPE. That's the majority of the developer experience. And then our ROI, what's what's good for business managers who are putting DPE in place is that it's very hard. It's a hard and proven ROI. It's it's it's very easy to be able to say, oh wait, suddenly this developer team can produce, you know, they can close twice as many stories as they were closing before because they're not wasting all their time. Troubleshooting or waiting on feedback cycles. And we, you know, many, many end to end solution providers for for DPM at this time, but just just starting to see them emerge for DPE, you know, Gradle's not the only one. We are starting to see some other people really, really do this as a practice. So which it was just exciting to us. I mean, that's validating for us that this practice is important and creating value for businesses as an as a sort of a whole. We look at developer productivity, engineering's practice across five outcomes that address five specific pains using five specific techniques. OK, so that's another thing about DPE is that implementing it is actually very practical. It's not very invasive. It's it's it's kind of read only in terms of the way that data is gathered. And then, of course, what the business chooses to do with the metrics and data is entirely up to them. And those fixes tend to be validated by the data quickly. You either know or didn't know pretty quickly whether what you're doing is helping or hurting. And you may find sometimes the most obscure stuff where, you know, you had a bill that was taking, you know, two minutes, you know, a week ago, all of a sudden it's taking 15 minutes. You've got 200 developers to try to sort through to figure out, you know, why did that happen? And if nobody's aggregating that data, if nobody's looking at it, you don't even catch it. You know, maybe you just have new developers start working on it. Say, oh, gosh, I guess we added a bunch of the code base taking longer to build now. But, you know, if you had a team aggregating that data, analyzing the data, doing something with that data, then. Then you don't have a problem. So our first one, we've already talked about this, faster feedback cycles. Developers need feedback about their build and their test faster. So how do we do that? Well, right now, the two, and actually there's a third technology that's going to be coming out pretty soon that we'll recommend. But the two solid parts of developer productivity engineering, the acceleration tools that we use for faster feedback cycles right now are a build cache and the concept of test distribution. So build cache is different than a dependency cache. And that actually, it actually caches parts of the build itself. And when we have our next episode, when we actually dive into this main bottleneck of feedback cycles, we'll talk in a lot more detail about how the caching works and moreover, how those metrics about the builds times and test times get aggregated up into our central data source. Again, she's running Postgres. And then is visible as a dashboard for users within the company who are responsible for enforcing developer productivity engineering. Then inefficient troubleshooting. We recommend something called build scans, right? Various build tools have some form of this. Gradle has its Gradle build scan, for instance, which is part of the open source Gradle build tool. You can run one of those right now. Any Gradle build and actually the scan works for Maven too in the open source tool. And what this does is, you know, other build tools have similar stuff where they'll aggregate different parts of the build together and they'll present it somehow. For us, this means aggregating all those things that a build engineer would normally try to get manually, right? So these are all the things that they would usually have to ask. And there's usually a lot of back and forth, including stuff like console log output, infrastructure information. Configuration of the build tool itself, you know, dependencies. And, you know, if there were failures, what are those failures and which tests were run? I mean, all this data, we want to gather all that data in one place and make it shareable, all right? So we want to pull all this data about the build into one place and give it a nice link that can be passed around between developers and build engineers. And we've seen all kinds of approaches for this, right? There's even sort of an open source approach that I've seen come up recently just for Gradle, which is like a, it uses the build tool itself and exports data about the build into Prometheus, right? And so you can start aggregating that data into Prometheus as well. But the idea is that you've got to have something that can be easily portable between developers and build engineers where they don't have to do all this back and forth to try to figure out the context of the build and all these other things you can get right to the heart of the troubleshooting. Okay, flaky tests and avoidable failures, right? We want reliable builds and tests. Flaky tests, what is a flaky test? It's a non-deterministic test. What does that mean? It means that it's a test that in one environment or setting or for one developer seems to pass, but when it's run in another setting or for another developer, the test fails, right? There's a lot of different reasons that this can occur. Sometimes, it's simple verification testing or non-verification. So does this test rely on some kind of external network connectivity that maybe is flaky? Sometimes the test gets a timeout where it doesn't get a timeout for another developer, right? These are things that if no one's aggregating these failures across an organization, it can be very difficult to detect. And a lot of them fly under the radar for a long time causing all types of problems for developers on one off, but then no one ever talks about them, no one ever fixes them. So you've got to be tracking data about test outcomes and then of course, really any other type of failure that's happening frequently within the build team so that it can be brought to light and then collaborated on. And then this new found efficiency can't just happen once, right? There has to be some rigor behind it. And that's where having the data constantly bubbling up into the central data source and allowing a team to look at trends and insights around the amount of time it takes to build code or the amount of time it takes for tests to execute, right? You have to have somebody observing that data. And then there's this kind of fifth pillar that sort of come out more recently and it's hesitate to even really call it about productivity because it's really more about conserving things like cloud resources and using CI resources more efficiently. But it's sort of a side effect if you think about being able to bring in the build times and being able to bring in the test times. Well, that actually means that like a CI system that was augmented by DPE work would be able to do more with less effectively, right? You would be able to run less builds or less parts of the build if you're caching through CI and so many more builds are being done in CI, but it's easy to forget that those CI builds have a cost associated with them and that cost builds up over time. And so by literally being able to implement acceleration technologies that ask the build system to do less, you also are making less of an impact on your overall cloud resources. So there's that. Okay, so breaking each one of these down, build cast test distribution, faster feedback cycles by caching individual tasks in a build. So obviously the more modular you're able to make your code, the more of this stuff can be cached. And so it's not like, again, that you just plug this in and then you're done, right? You get a benchmark of where you're at right now by aggregating this data across many builds. And then you use that to say, okay, well, what if we made the code a little bit more modular here? Would we have better opportunities to cache parts of the build that we didn't have before? So that's kind of the second phase, right? And that's a big part again of why aggregating all this data is so important. And then parallel text execution, actually being able to execute tests like unit tests and stuff for the code, the stateless tests execute them in parallel across multiple agents, right? And we're also working on something that should be very interesting for anybody who has done work with a form of machine learning called Gradient Boosting, which is a cost optimization type of learning. But Facebook has actually premiered this technology and we will be sort of having this, we'll be recommending that this technology fold into developer productivity engineering and it's called predictive test selection. And it's actually using machine learning to determine which tests are likely to give valuable feedback. And then simply skipping ones that aren't and Facebook has been able to get a pretty impressive degree of accuracy. And we're building that into our recommendations as well. Build scans, we already talked about that full X-ray of the build with context. It's a really good way of thinking about it, just an X-ray of the whole build. Failure analytics, being able to view and build the test failure rates and things like that, being able to find flaky tests easily, trending and insights again, so important to have this data up there and visible and then CI cache and resource profiling. Okay, so that's kind of an overview of what we focus on in DPE. And I think that talking about a global appeal for it is very important and understanding that teams can be a lot more efficient than they are by putting these types of practices in place is true and it needs to be said, but let's kind of dive into then some of the justification for that. What are we seeing? It's not like no one's doing this. The leading technology companies, we have been helping put these things in place over the last few years. So these are companies who are, they're out there talking about the work that they're doing in DPE. This is LinkedIn, Twitter, I mentioned Facebook. So leading technologies are doing this. If you go onto our gradle.com website, we have a part that's dedicated to OSS projects that we've given DPE solutions to for free and that are using it. So like Spring Framework is using it prolifically right now. The Tableau data company, I'm sure a lot of you are familiar with Tableau. They're also using DPE now. We've been helping them to use DPE to improve their development. So it's not like no one's doing this. It's just that right now it's been kind of in the lab environments and kind of with the leading technology companies that are starting to see results. But if you think about this, if you think about kind of the numbness that the teams have been kind of feeling towards this, I think it's because it's hard to really understand the aggregate impact of even something is what seems like an innocuously short four minute build time for a project like we see here. I think if you ask the average Java enterprise developer, as a four minute build sound terrible to them, they'll say, no, that sounds fine. It sounds great. So I think we need to reframe the question. And instead of saying how fast the build is, we have to start saying how fast can the build be? And that's because if you look at again, the data when we aggregate all the data up and we really start sussing out an ROI, look at what happens to a team of 11 with a four minute build time versus a team of six with a one minute build time. Basically, if you run the numbers, that team with almost half as many employees on it is able to run more experiments, okay? More hypotheses on the code and then I want feedback than the team with almost twice as many developers. These developers, this team of six are gonna be much more productive. And I would wager a lot that they'll be happier. That fundamentally you meet a team that's able to run their feedback cycles this much more frequently with a smaller number of people, you will be meeting a team with better morale, better organization because they're able to focus on the things that they really love to do. When we really start aggregating this up to large teams, so going from that six developer team up to a hundred developer team, the savings start getting kind of out of this world, right? If you look at a business that has got a 0.6 build time versus a five minute build time now, a hundred devs doing 12,000 local builds a week with a nine minute build time, we have the opportunity to save this team 5,200 days out of the year in engineering time. Okay, that means time that these developers can be spending on features and functionality that matters, time that they can be spending on their own personal enrichment. I mean, I've always felt that you have to grow a business horizontally and vertically, right? You have to make your people better too. And this is an opportunity to put valuable education time back into the work week, which is something that I know a lot of developer teams strive to do, but they have difficulty doing because their teams are busy wasting 5,500 days a year troubleshooting or dealing with slow build times, right? Build caching is a tool for very fast feedback cycles. And again, different build tools have, you know, different approaches and solutions. But the Gradle build tool introduced build caching to the open source Gradle build tool back in 2017. And it's available for both Maven and Gradle basals on the way. It can support local and remote caching for distributed teams, which is pretty cool. That means that, you know, you can have a CI system contributing to the cache. You can have remote developers all contributing to the same cache. In fact, that's what spring does. If you wanna test this, you can actually go download the source code for spring framework and just run a build. And you'll notice that you will pull a lot of the build components from spring's remote cache as opposed to having to run those parts to build on your own because they have this remote caching turned on. You're effectively benefiting from whoever the last developer was, whether that was, or for instance, whether there's a CI process, but whoever was last to run the build and populate the cache, you'll benefit from whatever you haven't changed in that code base being able to pull that from cache. They are complimentary to dependency caches. So they're not mutually exclusive. So that's confusing. Sometimes people say, oh, we were doing this already. You know, we've got an artifact or E or we've got a sonotype set up. Those are dependency caches. Those are meant to take the compiled dependencies and libraries that your code needs to use. And instead of having to go to some public server that might have that bandwidth, you can instead hit a local cache of these dependencies that you have within your own infrastructure. So that tends to help. Don't get me wrong, it's a great practice, but it's not what we're talking about here for the build cache. The build cache accelerates building a single source repository and it caches build actions. In this case right now, we're talking Gradle tasks or Maven goals. And just to give you some ideas, these are, excuse me, some idea of the results of what can be done by improving this caching. I mentioned before that we give our enabling technologies for DPE away to a number of free software communities. And that's very important to us. I mean, obviously, you know, Gradle came out of, came out of the open source community. The Gradle build tool is still solidly recognized within the open source communities. We get a lot of momentum and currency from our users in Gradle build tool. And so of course we wanna give back where we can. And in this case, you know, the commons IO, which is a Java project, we were able to bring a cache build from a minute and 23 seconds down to four seconds. Okay, so the commons IO developers now, when they're waiting on feedback, their feedback happens a lot faster. The Google Guava library, I wanna say we've made this even better now, but still impressive taking from seven down to one. Spring Boot, the Spring Framework. And you can see these results. In fact, it's our demo down from 21 to six. And the Apache Tommy E project down from one hour and 27 minute build down to 20 minutes. You know, tell me that that's not just transformative. All right, and again, it wasn't, it's not magic, right? It really is just this combination of very focused principles and practices. And it's about acceleration technologies and it's about data. So this is another way that things can move faster in terms of feedback cycles. I don't wanna really go into it necessarily, first of all, because it's pretty specific to our product, even though we're not the only ones doing this. But if you're curious, you can come check it out, you know, on the site and you'll see Hans Doctor who is the inventor of Gradle and our CEO, give a really good overview of how the technology works. But to give you an idea more of the practice, basically what it says is that any stateless tests, multiple stateless tests, so any test that doesn't necessarily rely on another test executing, you know, serially, can just be run across multiple agents in parallel, so if you have 1,700 tests that have to be run, you could distribute them across a pool of test agents and then that parallelism can be used to speed up the time that we wait on feedback from the test, okay? Oh, by the way, this is kind of cool too because it's the Apache Cassandra Open Source Project, it's Java database that's actually implementing this in this case study. Okay, so that was acceleration. We have caching, we have test distribution and I mentioned that we have some learning-based stuff, predictive test selection that's gonna be coming around the corner that's already been doing, being done by some organizations, like I mentioned, Facebook is already doing it. But we also, you know, like I mentioned before, the acceleration technologies are crucial, but they don't transform the business without the data technologies, they don't transform the business without using data that we aggregate from the build scans into our dashboards so that that data can be trended and analyzed and observed and all those things. So we all know this and I'm sure we've heard this one, we're all data people, what gets measured, what gets improved, no one's quite sure exactly who said it, but in our case, being able to provide a build scan gives us this comprehensive shareable summary on performance dependencies, failures, test executions, all kinds of stuff and we're gonna look at one so I won't go too much into the detail here, but it makes it a lot easier to spot bugs and failures in itself service to the developer and as I mentioned, this is open source, you can use this right now on any Gradle or Maven project for free. Developers can share build context, excuse me, build details with a context and that's the most important thing, like if you look at some of what's being captured, I mean, yeah, we capture the console log, but that console log is also can be filtered into logs out of individual goals, logs out of individual tasks. And so, you know, the data is a lot more malleable, you can share one small section of the console log and then you're looking at all that console log data right next to the actual failure datas, like diving into the failure details, right next to the overall build performance, right into understanding the dependencies, right into understanding how the infrastructure was built and then it's shareable, it's just a link, it's just a URL that can be shared with anybody within the organization to speed up troubleshooting. If you wanna set one up and also try the caching too, you can. Again, totally free open source, you can add this to your project right now. If you add the Maven extension to dot maven slash extensions dot XML, just add the Gradle Enterprise Maven extension to it and the next time you run that project, it will create a build scan for you that you'll be able to have all that data about your build and you'll be able to pass around to your colleagues. If you're using Gradle and you wanna just use the CLI, you can do dash dash scan and you'll see it also create that URL for you. And we have some videos and stuff that'll show you how to automate this a little bit better if you want to. So let's do a quick demo here and for this demo, all we're going to do is pull up a Maven project and have it generate a scan, right? So pretty straightforward. So for this, you can see that what we've done is added the extension just like we've got in the project. I'm gonna blow this up to make it a little bit bigger so that you can see the text. And I'm gonna bump this because we're actually just released dot five. So I'm gonna save this and when I do just a Maven on this project, I'm gonna do Maven clean verify in this project. It's gonna do its normal build. I may have some stuff that was cashed from this from the last demo. So we'll see how fast this runs. Now it looks like it's gotta run the full thing. And that's okay. This, by the way, was just a very simple project that I wanted to have at least a few dependencies with some spring dependencies in there so that you could see something interesting. But this is just the camel, the camel spring boot route Maven archetype. So anybody who wants to, you could repeat this experiment by just grabbing the camel spring boot archetype for Maven and just adding the extension to it and running a Maven clean verify that's like really all I've done. And you can see that we now have this build scan that we've published that gives us all types of information on the build that just completed. We have a whole, we can see the entire console log but as I mentioned too, we could actually filter down to just parts of the console log output here. All of this can be shared. So if I were to click this line, this creates a unique link right here. And then if I turn around and give this to somebody when they pull it up, it takes them right to the area in the scan. And that's pretty much true for throughout. Like you can link to certain parts of the performance anywhere you see this little link you can link directly to it but you can already see, you can imagine from a developer perspective, they've run this scan, they had this failure, they don't know what's happening and they pass this off to a build engineer who's able to have all of this data in front of them and go through the dependencies, go through every part of the build that could possibly have led to the failure and understand and better troubleshoot that build. So great, that's the scan itself but the most important part is not to just run the scan once. It's using this data to keep builds fast, right? That's why observability and data are just as much a part of this solution as acceleration. We accelerate but we continually accelerate. We validate our acceleration. We know when we have to implement more through our data. Performance regressions I think are pretty easily introduced to projects. And so quick time check here, it looks like we're looking good. Performance regressions are pretty easily introduced as tons of different changes can come into an organization. Code refactor, new office locations, changing networks, build logic configuration settings, new CI agents. I mean, there's so many things that can start introducing slowdowns into a business and into the build infrastructure. And so that's where really these other two techniques, we've talked about build caching and acceleration. We talked about scans but now being able to look at these other parts that we talked about failure analytics, trends and insights. We really recommend that developer productivity engineering teams centralize all of the build metrics across the organization because then they can be used to benchmark and they can be used to ensure consistent productivity and even productivity improvement when new practices are introduced to the business. And that allows them that dedicated DPE organization to continually improve productivity for the business. Build feedback is automatically provided to the DPE team each time a build is run. And you'll see that in a minute where this all gets aggregated up into the build scan for spring. So I like this little quote by Fred Brooks from IBM. How does a project get to be a year late one day at a time, right? Nobody's paying attention to these little regressions. And then all of a sudden you built up to a year late project. Failure analytics, we can compare these types of runs across multiple builds to identify non-deterministic or flaky behavior. And if we can find flakiness further left then we reduce the number of bugs that make it past the debugging phase. And by pinpointing the source of the failure we can reduce time spent troubleshooting builds. So analyzing failure data, right? Analyzing where developers are running into problems. Analyzing where they're really hitting pitfalls and understanding changes. Understanding if your developers were facing two minute build times yesterday and all of a sudden it's five minutes. Someone needs to point that out. Someone needs to be diligent over it. All right, our last demo, I'm just gonna take you through a little bit of how spring is using developer productivity engineering and just give you a little bit more idea of what kind of data should be aggregated up when you wanna start putting these practices in place in your business. So these all represent individual build scams. So I could actually click any of these and go up and see, okay, here's just the same type of build scan that we were just looking at for our example, right? You may see some things that are a little extra in here. We have build dependencies because this is a gradle project and where Maven doesn't have that same concept. But the idea is that these are each individual build scans that can be viewed, shared, anything like before. We can search through them. We've got a nice dashboard for searching through stuff. But now we can also look at trends over time, all right? Right now with our DPE enabling technologies with the things that spring is doing to improve their speeds like caching and like test distribution, how much is being saved right now, right? How much overhead is being put in place by the build cache? And we can look at how this performance has taken place over time, all right? This helps us find trends in build time over time. If we wanna look at the entire month, we can see that things have actually been fairly consistent which is good because there's a team that's constantly overseeing this. Failures we can actually see. So these were non verification failures against these. These are failures that tend to indicate problems in the infrastructure. So flaky networks and things like that. This can really be a time saver understanding which of these were actual code failures like an improper assertion versus failures that were caused by flakiness in the infrastructure and having a dashboard that shows that. And then being able to drill down into each of these tasks, understanding how many users were affected by this failure, how many hosts were affected by it. I mean, just so few businesses are diligently tracking this type of data but it can be the difference between some sort of problem in the builds process that takes a developer days to understand or some problem in the builds place that they never even see in the first place. And then finally understanding test performance across the organization here too. Builds with flaky tests, failed tests. So aggregating all of these data from these individual build scans and then bringing it up into this trending and failure insights. This is the most important part of DPE is the data and doing actionable things with that data, all right? So that's really it, that's the overview. A couple of things you can do if you'd like to learn a little bit more. Remember, you can be a hero to your organization. You do not have to go with any of our enabling technologies. We make a lot of technology recommendations. You can certainly think of DPE as a practice. That is what I do to be completely transparent. I am a large part of my work is helping businesses bring DPE and DPE principles into their organization sort of regardless of which enabling technologies they choose to do that with. And so if you'd like to read more about that and about how I'd like to say you can kind of be a hero for your organization by implementing some of these things, then you can take a look at the ebook here and just kind of put yourself in the position. Think ask yourself the question. You know, what have you had been the employee who brought DevOps into the organization? What would that have done for your own career path and trajectory? Try a free Maven Gradle build scan. We showed you how to do that in the demo. You can read about scans and comparisons here. And if you have any questions, I know we're tight on time, but please feel free to reach out. Jreak at Gradle.com is my email. I tend to be pretty responsive. I love hearing from people in the community. Love, love, love it especially right now when I can't be with you in person. So please, I really do appreciate the interaction. I hope you'll reach out and I look forward to talking to you in our next episode. Justin, that was fantastic. Thank you so much for your time and your thought. And as I said at the start of this, we're actually, this is the first of a series of three with Justin. So I hope to see you on future Postgres conference webinars and have a great rest of your day.