PurePerformance - Agile for real? Or, Are you still faking it? with Leandro Melendez

Episode Date: February 14, 2022

Do you regularly go to the gym or are you just wearing your sweat pants and sneakers at home and think that will do it? Or how about agile practices? Do you think by religiously attending your daily standup your colleagues think your performance testing all of a sudden happens within each sprint?Leandro Melendez (aka Senor Performo), a DevRel Advocate for k6 load testing, tells us what he has seen in organizations he is helping to transform their performance engineering practices. The true benefit of becoming Agile, DevOps or whatever the next buzz word is, is to enable engineers with automated performance feedback on their changes. Listen in and also learn about Leandro’s ideas on PDD (Performance Driven Development).Show LinksLeandro on Linkedinhttps://www.linkedin.com/in/leandromelendez/Señor Performo Sitehttps://www.srperf.com/K6 Load Testinghttps://k6.io/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always my co-host is with me the wonderful lovely amazing all dressed in I imagine all black today but I only see him from the top up Andy Grabner. How are you doing Andy? It's good it's good that you only see me from the top up because you don't know what's down under. I know. Hey, you know what? A while back, we had our honorary 150th recording with Mark Tomlinson, but as we know, it wasn't the 150th one. We just figured for timing or whatever.

It was fake news. I don't even know. Yes, yes. Ladies and and gentlemen it was fake news we're admitting it but today is our actual real 150th episode wow and uh someone related to mark someone i don't mean maybe by perhaps although maybe well who knows maybe if you go back well he speaks he speaks german too a little bit i know mark does and i know our guest does a little bit too because before you joined the recording session he talked german with me oh very interesting oh yeah and well so so people might be hearing the voice they may have heard him before he's been a guest you've been i think he's been a guest before i know i've done podcasts with him and you've done podcasts with him. He's got fantastic mustache, a fantastic cat with a mustache, very similar to his. And I, you know, I'm sorry.

I'm, I love to sing the praise of this guy. He's doing so much for the performance field, especially in areas that haven't really been concentrating on performance. So I don't nicht, Andy, kannst du die Vorstellung beenden? Weil ich habe versucht, sie dort zu machen, aber ich bin nicht wirklich gut bei ihnen. Du machst immer die Vorstellung.

Ich habe nur gesagt, wie es geht. Hallo, wie geht es dir? Hallo, wie geht es dir? Wie geht es? Auf Deutsch und... Nein, hallo, hallo, alle. Ja, es ist ein Vergnügen, zurückzutreten. Danke für diese kinderlichen Worte, Brian. Und wow, ich bin a pleasure to be back. Thanks for those kind words, Brian. And wow, I'm on a special episode. I yeah, I'm sure. Oh, my God means you shouldn't better not

mess it up. Oh, my. This one will be our lowest rating. I predict it will not, though. I think this will be our second highest rating. I know I'm going to break things, but I hope for a good and a good perspective. Hey, Leandro, I think last'm going to break things, but I hope for a good perspective. Leandro, I think last time when we had you, you were just about to publish your book. Oh, yes. Yeah, we were talking about it. Yeah, it's already out there in the world

and I hope people are still enjoying it. I have heard good feedback out of it. Have you been nominated for the Nobel Peace prize for performance? Not yet. Or that I know. Has anyone given them my number? I'm not sure. I'm sure they find out. But the thing is when they call you, they might, you didn't speak Swedish.

Maybe somebody from Sweden called and you didn't pick up because you thought strange number. Ah, those robocalls. I mean, you cannot pick up the phone lately at all. Hey, for anybody who might not know about the book, what was the, can you remind our listeners about the title and topic? It is a hitchhiking guide to load testing projects, a fun walkthrough guide into the steps for a traditional load testing project where you go on those old phases that you discover what to do, you design or put

together a plan, a set of scenarios, automations to do, put up your scripts, create them and then execute the test. But in a very guiding up the people in a very traditional way to do those things, scary things. And I think one of the feedback I remember that you asked me and I'm pretty sure Brian and others as well to give you some reviews before the book was published. I loved it. But then also I think in the end I said, hey, wouldn't that be, what's next?

Because you've been talking about, let's say, as you got just reiterated, a more traditional way to load testing projects. And then I said, hey, we've been talking about DevOps, we've been talking about SRE, we've been talking about automation, we've been talking about agile. And I said, hey, we want to have you back

if you want to tell us more about these topics. And then you, I think, and I have the email open, I think it was around Christmas time last year. You said, hey, I want to talk about Agile for real. And I had some salsa and some good camole on it because you also want to talk a little bit about Aztec automation sacrifice pyramid. I mean, there's a lot of things you, you threw to us in an email, which is now, which is a, I love to, uh, especially start with, uh, agile for real because, uh, the, the thing that you brought up is some people think they're doing agile, uh, whatever agile means for them. Some for some, however,

it feels like they're just impersonators or imposters. They're just pretending to do an agile, but actually they're not doing Agile. And I know you've been teaching people and you have your own experiences. And this is why I would like to dive into that topic. What can you tell us? What have you learned? What are you teaching? And how can people figure out if they're doing Agile for real or not?

Well, good that you bring it up from the book's perspective and what was pending, because I can say right now it's a work in progress part two where I'll be diving fully into how to tackle this performance thing in an agile way and an element while writing it that has been jumping a lot at me, and it's not just from the book. It has been jumping since I started to get into this Agile thing and learning it and understanding it, not just in the traditional way that, hey, I'm on Daily Stand-Ups

and now I am Agile. It's something that I started to notice while I was as a consultant jumping on different organizations providing services and finding lots of them saying yeah now we are agile we do this scrum thing DevOps and all those terminologies I'm gonna use them somewhat interchangeably. The people that know the trades, please don't jump at me. I'm just referencing all these modern methodologies to produce software. And I think that the big element here, as you mentioned, the thing that when I started to learn it better and understand this beast was

that hey you are not agile you are not I mean you are embracing it you are doing some of the things you are trying at least but it doesn't feel like to me that you are getting the benefits and I came up with an example that has helped some people to understand what i'm trying to say so being agile is more or less like being a fit person in terms of fitness doing some workout staying in shape like trying to take care of the good old gut box that we were given. And some people may be just saying, yeah, I'm so fit, I'm taking care of my body, just because they wear yoga pants. I mean, it's a pandemic. We all do that. And some others are, and I have people that I know that started to do some of the right things. And then they ended up just having protein milkshakes,

but that's it. They just drink lots of protein milkshakes. I'm like, well, you're still not there. Some mothers would buy the most modern jogging shoes and have them wearing them all the time. And yeah, I'm super fitness now and I'm a speedster. I have never seen you running or actually doing the thing. And I think that we all can agree on more or less what are the kind of things that make you a fit person right that you more or less take care of your what you eat doing some exercise like whatever you you do it's really really good to have the yoga pants to have some protein and all

of the things that I said but there are key elements that if you're not doing them, it's like, okay, well, good for you. And it's very similar. Good for you. You had a write-off. It's so polite. Good for you. Hey, good for you.

I mean, you're at least in your mind trying, but that's not it. You're not getting the benefits of what we are looking for and trying to be fit, which I would say, be more or less acting up, doing some sort of exercise, given if you are into weights or swimming, running or golfing, yoga, whatever you do, or what you're looking to at getting good at. And the second would be some sort of consistency. Like, yeah, this is exactly the good time of the year for that example.

We are all in January going New Year resolutions that, yeah, I'm going to be going. But third week of January or starting February, we're like, yeah gonna and little by little you start show up if you show up there at least I would say once a week or twice and my personal opinion would be the bare minimum to consider like hey yeah you're trying to keep good care of your physical staying in shape right and it And it's very similar with Agile. With the Agile practices, I see all over the place that, yeah, daily stand-ups, we have a Kanban board, we do the Scrum meetings and these plannings and the backlog and the reviews but most of the organizations

that I've been at are not doing the key component like I said with the gym most of them are not doing them or getting those benefits and don't get me wrong I there's a benefit or doing the daily stand-ups. There are benefits of organizing, following up, having little pieces of deliverables. But to me, there are three components, like I said with the gym, that would define if you are truly embracing this agile philosophy.

And it had me down the rabbit hole to read who's his name Jeff Sutherland's scrum book where all of these things are described I think as a starting point and I think that some of them and keeping it with the gym example, get into the CrossFit mindset where everything is about CrossFit and I need and the life starts to spin around it. But it's not anymore about being fit. It becomes about CrossFit. It's like you're doing the craziest exercises you're doing. And in Agile I have noticed that as well,

like religiously the daily stand-ups and start to polish and the burnout chart and all those things have become for the sake of Agile, not for the benefits that Agile will bring us. And I think I've turned around these topics, but I think the first one that is really critical to achieve this agility would say to be releasing to production frequently. There's most of the time, that's a key component. Some may get benefit to releasing to those pre-production environments, staging, QA, any of the flavors that you know that come before production. But the key element of it is release frequently into it so that your end users, whoever has to use the software that you're creating, have the capability to give it a try, to start using it, to start seeing that's the point of these sprints, these little deliverables so that

everything can continuously be showing up hey what do you think of this new thing um let's try it out let's uh push it for to say it in a way for the world to see it and to close the loop the second element will be to pay attention to what happens once it's out there, once the end user is using it. If the person or the audience likes it, hates it, is having bugs, is having problems, and quickly loop it back. Because on one hand, pushing frequently to production, some say like, yeah, we are pushing once a month. I mean, to me, that's pushing it a little bit because then to close the loop and have that feedback will be another month.

And then to push a new thing will be another month. And three months later, you barely are fixing something that was requested three months ago. It's like a very, very long period to have those risks in production or be holding up things and that and that's why those two week sprints are happening that's the main reason to give you a chance to push in front of people these new things and quickly get feedback and pay attention to that feedback would be hear the people and act on what you're hearing

because other organizations like yeah yeah yeah you have problems but we're working on these new features and that's all they care about or we have this deliverable this big release in six months and that goes a little bit against this agile philosophy that that you should be able to continuously check, see if what you're doing makes sense, if it's okay, if it's good, if you're going in the good direction and be able to, in an agile way, change direction. Otherwise, you are still blindly driving towards a goal that who knows if it's going to be really what generates impact that you're looking for and it the same story that we had with the waterfall days you will find out in six months in a year when the release happened and if anything is

found out maybe a waste but we will see in the next six months when we do another one and many organizations are not aware of those key elements they are just into like yeah I have the yoga pants and the protein powders and all that. But they are not doing or getting the real benefits from these philosophies or these methodologies. Where I think the third component that I would say, and this is the one where I'm not so sure, I wouldn't set it in stone, but I would say that your scope is not defined or with a clear end date for a real Agile project. Most of the solutions that are developed in an Agile way, you keep switching lanes

or changing direction or this little piece I'm gonna put it this way I'm gonna remove it and it's not like by the end of year the software has to be released with these disease and that is some what elastic no pun intended another no modern technologies but it shouldn't be like an old waterfall practice. This date, these deliverables, and it's going to be the end of the world if you don't commit to that. Because especially you are hearing your market, your audience, your end user, just change those directions. And there are some things that you may not be able to complete or you may not even complete.

Say like, hey, the user hated it, does not need it. We thought it was good, but no one is using it. Let's drop it. Why don't we add something new? Or just we sadly wasted some time on this, just out of the picture. Let's not waste more time, because if we did it in a long release process,

it would be six months until we figure out and we waste even more time. So those are the advantages. And most organizations have no idea. They are just jumping into it for the sake of some buzzwords or activities that we hear, see all over the place. And it's amazing to me. And even reading the Scrum book, as I said, it dives a lot into the process because, yes, you want people to learn the process,

but then you get lost into the weeds and it's like the process for the sake of the process and not for reaping the benefits of all this. Wow. I mean, yeah, he brought up a lot of points that i would love to dive into but i also want to make sure we stay focused on on a little bit on performance but one thing i want to highlight a couple of things um that getting into smaller deployments or like breaking bigger features into smaller things and allowing you to be flexible and then reacting to it is obviously the desired state, but it's also very challenging because it

needs a lot of planning. How can you break down a big feature into smaller chunks that it can deliver something that is actually valuable? And I think the trade-off is always, yes, of course, I want to deploy something that already provides some value, but it has to have at least the minimum value because otherwise you are making your users mad. I just had a conversation yesterday with a friend and in Austria we had years ago, they switch over to a new system for electronic track record keeping of healthcare data.

So basically doctors were able to put in all of your data electronically and they had this new system and when they they deployed that system they forgot a search feature so that means every doctor couldn't search for the patients you know couldn't search for any of the records so they had to manually click through everything and obviously it was a minimal viable product, but nobody used it anymore. Nobody started using it. No, not so viable. So I think this is important.

And I think this was years and years ago. Andy, can I add one thing to that? Because this fits right in in the idea of how agile. We had a similar thing with the medical records here. And I went to a doctor. And it was for my daughter and their version of the electronic records as they took all the notes by hand scanned it in and then pulled up the pdf yeah this doesn't give you any any value right so that's one thing um the other thing i

really also love the fact that when you deploy fast and frequent, you can get feedback, but then you also need to be very careful, I believe, as the one that makes decisions to which feedback you listen to and to which feedback you need to be also careful with. Because if you listen to every feedback and change direction with every two weeks, you're never finding kind of your end goal. I think that's also challenging. And the last thing, this is now my segue over what does this mean for performance engineers or let's say site reliability engineers or

whatever we call them these days if we move towards a continuous deployment model every other week what has to change in these teams what do they need to adapt does it help them if they just participate in the stand-ups and then know what they are supposed to do or what other what does it mean to be agile for a performance engineer and yeah that's a a question and a discussion that i have had even with organizations now what they say help us, what type of people do we need and what type of roles. And this is another one that I'm kind of suggesting how, because how organizations should work as it is a, you need to change the mindset of how we used to do performance and load testing in the old days, like these big load testing projects were at the end of the

project like six month project they left the last three weeks for a load testing that was somehow supposed to cover all performance possible issues already from that departure point was already a little stretching of things. But you would get to those three weeks that you gave to the project and in reality were just a week because everyone else ate that slot of time. And none of that will work anymore in these continuous and agile ways. There's a full change of mindset and practices that a performance engineer, I think that's why you may not be hearing so much the performance tester term anymore. Where the tasks of the performance tester before were you are kind of a scripter and then you execute and create the scenarios. Do some sort of analysis and generate a load test. But nowadays, I wouldn't say it's so much about those traditional big-ass load tests

that we used to have where, yeah, almost everything was related to capacity planning. Nowadays, as you say, we are continuously, we already have the software in production. We already have an idea of how it is doing if we are doing things accordingly. So the way we do things, how we attack it and who attacks it is going to be very different for performance engineers nowadays. And that's another one. I recently had a discussion with an organization that were asking like how many Scripters should I hire and I'm like, I don't think you should hire Because they were migrating to micro services

Ditching all an old monolith that they had as a solution Hey, are you still gonna use the monolith or working around it? Yeah a little bit half of it Okay, have a couple there. That's that's unavoidable. You need to keep doing it the old to use the monolith or working around it? Yeah, a little bit, half of it. Okay, have a couple there. That's unavoidable. You need to keep doing it the old ways with the monolith. But for the new pieces, I wouldn't recommend to have a scripter holding your Agile team with the handover, waiting for things to finish, to do the test and back that back and forth you only have technically like two weeks if your sprint is a standard some teams are shorter or you have continuous releases you

don't have the time for waiting for a scripter to do that automation front-end automation god forbid you're doing that in the these new more times sometimes have to, and there's no other way, but you should not be creating software that is also difficult to test and automate at different tiers. And that brings a little bit the topic of the tiers and the sacrificial Aztec pyramid of automation. But before I get into that, the role of the performance engineer i think is

more around i'm not sure if using the term but evangelization or being an ambassador with the agile teams because as well you have these smaller teams that you should or cannot depending on the organization but wouldn't be good that you stay with them. You just come in, teach them about some of these practices, you teach the developers to do animations at the correct tiers in the pyramid, and teach them what are the things that they should care for, be aware or checking, and don't give them or do the fish for them teach them how to fish what type of fishes are interesting and trying to keep in the fishing

analogy that the teams become self-sufficient and that can automate some performance metrics and measurements and i would say with that you're continuously releasing tests for some sort of load. And the performance always, I mean, you should have performance testing in the purest definition, like when you measure impact and response times in a given scenario. The base performance testing should be done everywhere all the time, and coming from Dynatrace observability, all those things, I think you all agree that should be happening.

As a matter of fact, no argument or no question there. And the point for the big, huge load tests, I don't see a true need anymore for doing it always. Rare occasions you will need it. There are so many other practices where you can do some sort of load testing with beta users, releasing into production. Again, you are already in production

if you are doing Agile, so you have some idea of how do you respond to some loads. There are very few scenarios like a Black Friday. Of course, you need a load test. They're traditional and try to push it as far as possible. But very specific scenarios. I don't see that the team should be like some other teams that I met, like we need a production load test before we release into production. Why? You released last sprint,

you are going to release the next sprint. Don't you already have an idea? Just check the new thing that is not bringing too much noise and most probably you will be able to do well. And also focus on rolling back if for any reason you have a bottleneck so that you can tune it and and that's the importance of going back and forth quickly as well if you can identify that you have an issue right

away observability wise you will notice it immediately in production say hey hey alert alert these strings in the Toyota production line that you could pull and stop everything and send it back. Can't remember what's the name of that string, but... I think it's string you make string face. Like, yeah, an alert and an alarm, stop the machinery. And it's important to try to release the software with all that in mind instead of just holding on to those old practices and old methodologies. The role of the performance engineer is more on teaching the people in the team

because they should have some knowledge around what is happening and if possible, being able to do most of those automations that you should do nowadays instead of just front-end, end-to-end old automations and help them.

Like, okay, you may need to integrate your Jenkins with observability and triggering some stuff after you do a check-in. I can help you to implement it. I can teach you to implement it, but you need it because this, this, and that. When you do a check-in, have a unit test,

service level automation, some things that quickly will tell you if what you just created is okay, and don't waste time waiting to attest or to come in to verify it and I mean you have the checks in the production line I mean here you will hear a lot of analogies with production lines and assembly spiritually but that's the idea you identify the problem where it's happening and not waiting until I don't know in that production assembly line the car is already on the road and you figure it out when they are already crashing that's when it gets more costly

more expensive slower and all those ugly things that we want to avoid yeah i think the um the key there even ties not to plug your book again but it ties back to the concept of your your first book right because we're going from traditional low testing to more modern style and if you think about the people who are coming in, let's say net new, right? They haven't been doing the old style load testing. All of this makes, I think, very clear sense. You test the bits that need to be tested, you roll it out, you observe, you have feedback loops and you roll things back.

But for the people who've been coming from more of the traditional world, I remember when I started hearing stuff, and every time I hear these conversations, I feel a little fear because you're like, but, but, but, but, right? But I always realized, number one, you were never testing everything anyway. You're testing scenarios you scripted for. But number two, all of this idea of not doing, as you call it, the big-ass load test, I guess you should term the word bolt, right? That's a bolt test. It's because you have a bunch of other checks and balances in place.

If you're teaching, as you're saying, if you're coaching your developers, to me, performance starts when the code is finished, or actually, technically, I guess, before it's written. You think about it before you write it. But the first time you could really test it, you don't even need a load. You run one run-through of it. And then if it's something that existed before, you can compare it to the other one.

Did we increase our CPU time? Did we increase maybe the code lock time? Did we introduce something? Did we improve things? And before it's even under scale, before it's under any load, you can see if there's a net change that's either good or bad, right?

So if you're getting people to do that and then maybe test their services and all, right, you're mitigating the risk. You can't do a full risk analysis for everything except for those Black Friday deals. But there are a bunch of checks and places going back to the factory line, right? There are sensors everywhere for small little deviations to pick these things up to really, really mitigate that risk. And there's a comfort level you have to get to it. But for, you know, again, someone coming from the older style of load testing, or I don't want to call it older, but the bigger style of load testing, right?

It's making sure you don't just switch over, but you switch over and you have all those checks in place. And that's the key piece, is having those checks and balances in place so that you are mitigating that risk. And the most important one, as you say, is having something like that two-week release cycle and a good rollback plan so that if something did escape, you can either roll back or you have a fast path towards a fix if you need to move forward.

But these all have to be in place. It's not just, oh, we're going to do spot checking and not big. But you have to have everything there. You have to build it all. Again, you can't just wear the sweatpants. I love that analogy, by the way. that's a fantastic analogy because yeah that's me i'll go do that i'll buy my new sneakers and i'll work out for a few weeks and then all that there is is just the yoga pants for amigo brian one thing i wanted to add leandro is

and maybe you you meant this, the way you said it, but I understood it maybe incorrectly. You said the performance engineers are more like mentors, so teaching them how to build the tests and how to integrate them with Jenkins. For me, it feels like, at least the way I tell it to our users and the community, I want to encourage the performance engineers to not only teach them how to write scripts and the community. I want to encourage the performance engineers to not only teach them how to write scripts and then how to integrate with the CI CD, but actually provide that level of automation

already so that the engineers only need to check in their description of what they want to have tested, their test scripts, whatever, like K6S or other new tools we have out there, then check in their definition of what metrics are important for them in Git. But then I don't think that every engineer or engineering team should figure out how to now integrate all of these tools in the pipeline. I think this is what I thought, at least a modern performance engineer, is that they're working with the platform teams, the pipeline teams, the DevOps teams,

whatever team that is, and kind of bake performance into the pipeline. And then obviously enable, and this is where the mentoring comes in, show developers, hey, when you create a new microservice, here is where you put in your test folders, I will use it where you put your test, here's where you put in your test folders. I have a user where you put a test user. You put your observability definition. Here's where you put in your SLIs and SLOs. And then from that on, every time you check in, you will make sure we will make sure that your tests get executed. So that you are sharing the framework, right?

And that goes a little bit in line with what you were saying, Ryan. Maybe I didn't go as far at the explanation. I'm toying with the term PDD, like test-driven development, performance-driven development, where not even in the definition or the meetings when you are doing the sprint planning and what we are going to do or creating the requirements on your tasks on your Kanban board from the very beginning when you are about to start a project bring on the performance engineer and say hey mr. performance engineer what would you recommend do we need to have these Jenkins pipeline our solution is

going to be created I don't know in, in C Sharp or in Python, what tools, at what levels, what best practices, and even at a level of infrastructure, like how many of us have walked into a load balancer that is misconfigured just because it was just dropped down out of the box. And some of these little problems and defects, the performance engineer should have some assessment, give a feedback. And when the team establishes these processes, as you said, Andy, we have this new requirement. Not all of them are going to be the same. Not all the teams will use the same tools, the same integrations. And one process may require more attention on web performance, one requirement, and the other may be more on database.

I don't want more than 10 connections to the database or that the query brings back this much information. Some of those things should be defined at the very moment in those sprint plannings where we create the backlog and say this to do this task that I'm putting on the cam and board has a check for performance that when the developer finishes it can be moved to done and this includes having some sort of levels of automation unit testing and some checks and passes for hey you just created a I don don't know, a database request, should not be reading more than this number of records, not do any full table scan, and have no response in this period of

time for five threads. So just give a quick example, right? And to be completed as done and be able to be fully checked in or move further in our repositories or even to production should come paired up with some of those automations, unit testing, service level testing, and some of what I was wanting to say with the automation pyramid, to make sure that we have coverage where we need it or should have it at the earliest. Checks and balances at the earliest. Keeping with the gym

reference, you are going to the gym because you want to lose X amount of pounds. That's it. Have your SLOs, SLIs defined for that little element so that you create software with all that included, which you know is important, and you'll be able to use it even once you're in production. I mean, some of those things hand in hand, and if you teach the developers to give an example, to do those automations, to do those things,

they are the ones creating the code. They are the ones that understand it better and how to check it. I mean, if it's a service, if it's a unit, it's super fast, super straightforward. Shouldn't be leaving it for a tester to wait and see, and hey, what did you change? What are the differences? The developer already knows it. And most of the modern services, microservices, unit tests, are pretty much function calls or method calls for classes. It should be done there. It's the most efficient way.

I mean, and to jump a little bit. Amen. Yes, I thought that was the quietness. Yeah, so quiet. I was about to do a drop mic... Amen. Yes, look at that. That's the quietness we're like... Yeah, so quiet. I was about to do a drop mic and get out of here. Yeah. And I think, Brian, what you were alluding earlier,

I want to come back to my earlier thoughts. If we are modern performance engineers, help build this into the... Build a framework or help build the platform. Obviously, I need to plug in what we do around Captain because that's exactly what we try to do. And by the way, a lot of this was inspired talking about performance and performance as a self-service by Mark Tomlinson, because Mark Tomlinson was the one who showed me and told me the story of what he did at PayPal back in the days when he automated the whole sequence of actions when a developer wanted to get some performance feedback. The only thing they had to do is they had to create a Jira ticket,

and that triggered the automation. And the automation deployed, tested, and then pulled back metrics and put it back on the same Jira ticket. So the Jira ticket became the trigger of the automation. You know, today we would probably use just a pull request and that would then trigger the build, the deployment, the test. And we're trying to do this with what we do with Captain. We're trying to provide this as well as

one of the use cases yeah and i think uh it's important you know as you mentioned andy to as the performance engineer to enable the developers as much impossible as possible we don't want to do the phishing for them right as you as you said le. But at the same time, I think an easy way out a lot of people take is to push it on the developer, right? So what can we as performance engineers do to enable them and make the efforts that they have to contribute as easy and seamless as possible? And that's where I think a lot of it comes into,

this establishing a framework, maintaining a framework, and then teaching the developers about what's important about performance, what to look out for, so that they just have to plug in a few things. It's a low effort on their part, but it gives them the ownership without the maintenance or, you know, how should we even tackle it? I think that's where performance engineer can use their expertise and their knowledge to build that all up for them and say, here's your inputs, plug your stuff in here, and you'll be good to go. And I want to point out, sorry, you had a comment on that one, sorry. No, no, on that level, some automation tools that are designed or are code-based

so that the developer, hey, this one uses Python, this one is JavaScript, this one, all of them, and here a plug for the ones that like JavaScript, K6 can use it, and it's the goal. Like, hey, Mr. Developer, you don't need to learn this new or thick SDK clients or user interfaces, drag and drop and complicated. It's just almost the same code that you are doing already in the solution. Just write a couple more lines, hit it.

Straightforward. Make it as easy and transparent for them. Agreed. And one comment unrelated, because I guess we're about, we got to wrap up in a moment, but I wanted to point out that there's a term that you need to be aware of for the wearing of the workout pants and the workout clothes and the fancy sneakers. Without it, it's called athleisure, a combination. It's a fashion term, athleisure. And we have a, before COVID-19 hit Denver, we've had for years a pandemic of athleisure in Denver. Everywhere you go, people just wearing the workout clothes to the supermarket to pick up the kids, even not to eat.

You know, it's a really such an important concept, though. Right. And it's human nature. What you're talking about is human nature is I want to do this cool new thing. So I'll get all the tools and all the looks but i don't necessarily practice it and maintain it and execute it but i look like i am same thing happens i think we see with kubernetes so many people are like oh kubernetes is there let's move to kubernetes oh what does that mean we spin it up and we lift and shift our stuff

onto kubernetes like no no no no you didn't do it you did not do it you're not doing it you're not learning anything you're not getting the benefits and that comes to anything you know if you look behind me i have all this fun musical gear right a lot of it you acquire because it looks fun and then it sits there for months before you even get around to it to start exploring what you can do unless you're making a practice of of of really exploring it and this just really really comes back to human nature over and over again. And we see it manifest itself in everything, including the agile. There's the old joke, what's a stand-up meeting? Meeting in a room where there's no chairs. Doesn't mean it's a five minute meeting. It's just complicated. Anyhow, that's my rant.

Sorry. No, I think we all have those type of rants because we have faced all those situations. It can be frustrating at times and some, like what you say, like hey, you're clearly not doing workouts. Why are you wearing the yoga pants or things like that, right? Walk around with a spray bottle, keep a constant sheen of parents' sweat looking like, oh no. You just sprinkle it in. Yeah, yeah, yeah, I totally did it.

And I see organizations doing that. Like, no, truly, truly, really, I just did. No, you're not. So then maybe Leandro, to kind of wrap it up here here what I took away from this is that it's I like the the gym analogy like Brian does and I think what we want to do is we want to encourage people that really want to make a change in their organization if they find anybody if you see something say something right if you see somebody that is that is just faking to be agile. Try to be a role model and really do it for real and show them the benefits of it.

If you not do it once a week, if you continuously do it. For the performance engineers out there, there's obviously, first of all, more developer natural tools, friendly tools, as you said, right? No longer the UI rich point and click tools, friendly tools, as you said, right? No longer the UI rich point and click tools, but more everything is code, whatever language or declarative and maybe in the ML or JSON. And also tools that can be fully automated and integrated

in your pipeline. And I encourage every performance engineer to look at these tools, figure out in your development teams what are the languages of choice. I think that's also good, because while scripting languages are easy to learn, but if you already have, let's say, knowledge of Python or JavaScript, then pick a tool that provides these languages,

makes it easier. And then also work with the DevOps teams or the pipeline teams to integrate those into your pipeline. Because in the end, the developer needs to make as little change as possible teams to integrate those into your pipeline because in the end the developer should needs to make as little change as possible to get the automated feedback off on performance and and i think that's how that should be the goal of every performance engineer yeah i will close close with a a small analogy there as well from what you said um making the task as easy and transparent for your team as possible because many times the developers are like

we were all when we were kids, children, and our parents were forcing us to brush our teeth before going to bed. It's a little thing. It takes just a couple of minutes. You should do it a few times a day and it just takes a little bit of time. If you don't, the consequences

may be long sits at the dentist, painful sits with it and having lots of issues. And in the same way to the children, when I get to that, don't give them the full blast of mouthwash and flossing and just give them a funny toothbrush tiny for them that is i don't know baby shark themed or something like that um yummy uh paste uh for them to be excited about it so to not to suffer little by little you start to introduce them to start to give them a path to instead of having to take them to the dentist and have root canals or ugly things. The gamification for the key. It's a great analogy.

Making the game, and I think we need to find the same thing for IT. Baby shark themes for IDEs. Yeah. I dare everyone to take that song out of your heads now. Yeah, thank you. Some people, fortunately, might not know, although they did, I don't know if you've seen Ted Lasso, it's a fantastic show on many levels, even just from

a leadership point of view, but there's a guy named Jamie Tartt and his chant is, but Jamie Tartt do do do do do do. Anyhow. Okay, now you took this tune into everyone's mind. Yeah, I'm just obsessed with that show lately. Me too. Thank you so much for this. This is fantastic. It's always great to have you on. And thank you for being part of our 150th actual show. I'd like to say if there's anybody out there who's been listening to us since day one,

get in touch because I'd like to buy you a gumball. It's about the budget we have for the show. But seriously, to everyone who's been listening for however long you've been listening, if you just tuned in or if you've been listening for a while, thank you all so much. Leandro, thank you for everything you're doing for the performance community. We need more people like you that are actually trying to help and not just get speaking credentials but really trying to help people and do so much more. So it's fantastic.

And I'm glad to know you. We've got to make a better world. Thanks, Andy. For the children. For the children and the baby shark. And the baby shark, yes. Thank you for getting that stuck in my head. Andy, any closing?

You said it well. I just say goodbye. Hopefully we'll see each other soon in person. Someday. Take care, everybody. Bye-bye. See you soon. Thanks.

Bye-bye. Bye. Thanks. Bye-bye.