transcript.csv

transcript.csv

Welcome to Legacy. Good rocks the podcast, that explores the world of modernizing existing software application on your host. Scott, for this show is at the change the way you think about Legacy code. When you hear the phrase Legacy code of images of big mainframes anarchic punch card machines. Well, that's true. It only tells a small part of the story, anything that someone else has left behind, is there Legacy this episode of sponsored by cardi B? Cardi B house companies, make their existing custom software systems, more stable, scalable and secure. And upgrades bug fixes performance, enhancements and other maintenance activities designed to help companies generate Revenue lower operating costs. And reduce risk is a senior engineering manager at fast Ruby. IO and he's been developing web application since the days. When the first HTML Pages were painted on Cave walls over the past 25 years. He's worked in various roles from developer product owner to director from many different organizations such as actblue.
University of Pennsylvania. Stanford, University, Ask Jeeves, ETrade and others. Mike is passionate about helping team's improved, and has led a do transitions outside of work. You're likely to find him pairing down yet, another wall in his house. Mike, welcome to the show years ago, he was on. So let's chat a little bit about what a drill practices makes sense when you're working on Legacy code, especially like, when you're working as a small team of Mexico, to kind of keep that off to you. As the first question, like, what does Advil look like when viewed through that lens? So, just to get a little history there before, I answer the question directly. So I was first introduced to her at the practices and strong back in about 2.
The meat. So was definitely sort of a well-established way of doing things at that point but wasn't quite fully mainstream. I'm just like oh that's what everyone's doing or not. Everyone knew what it was about point. I would handle transition with my team at the school of medicine at the University of Pennsylvania. Done that a couple times. Since that other organizations, and most of the places I've worked over the years have been like, not too small engineering teams with small engineering organizations, like the whole engineering organization is maybe 15 people or a small ways to even hit a start-up. I was at all. So you know, I got really excited about Angela practices. When I have my first management job that I was thinking, oh my God, how am I going to do this guidance and support a framework? That was something other than the waterfall. And, you know, I found
Yo the agile literature I think most of what drove the Crickets are a creation of agile. Practices were from the experiences of engineering teams working in, you know, Enterprise organization, the large long-term projects. So some of the practices can be harder to adopt or like smaller teams working on really small or short-term projects. So just to give you an example of the consulting company was at maybe seven or eight years ago or like, okay, like let's try to do some of these has or practices and they're working on a separate project. So it, what is it mean? So I'd like to talk about what you're working on the stand up when it's not really relevant to the person standing next to you. And at Vio where we specialize in rails upgrades, you know, engagements can be as short as a couple months. With maybe two Engineers working on a project. And then after that, they're on to another project.
I think really. So finally sort of answer your question with that is a sort of some context. I think which really key is understanding, sort of the values of the principles are behind, the ankle Azle, practices and have bad Cyrus would help guide you in and how you approach your work. So, what I mean is that by that is, you know, some of the Core Concepts. So like, one of my favorite ones is for the correct alignment of authority and responsibility, which basically means like not being held responsible for things. You don't have already over which is sort of a classic just function in a lot of organizations. So another way to say that is, you know, when powering your team, cuz to me what real, if I can boil it down to sort of a core concept that I taken away from, you know, as well. Practice is the idea of trust, you know. And that's often the
Hardest thing for leadership to really do to say, okay? Like I'm not going to just tell you what to do. I'm going to give you some goals. Give you some guidelines and then trust you to do your job. Well, without me. Micromanaging. You and I think that's awesome. The biggest hurdle for leaders to get over, you know, but I have found it really pays dividends. Cuz when people feel a sense of empowerment over that work, if you are sense of ownership with that work and that's really, you know, a key driver of a motivation, people feel like successful in their job. Yeah, I had I had submitted a conference talk idea to the National Conference
I got this would have been, like, 2007/2008 Jurassic to successive years in a row. I submitted talk to talk about a drill for micro teams and you'll take it. Like you. What would I do? Practice this look like if your solar developer will they look like if it's too
 And the feedback I got from the submission system was, you know, I thought I found that I found the feedback that I received this Mission. So it's really frustrating because, like, one of the people responded with disbelief that anybody could possibly get anything done with that. Few number of people in this problem. If you're interested me as well as like you know, you're there has been so much conversation over the years for like how to scale a show up and you know how to how to make make those practices work for more and more and more people. And yeah I was curious about what it looks like if you took it down and what is it? What is it look like to shrink it down to just a solo person or two people or three people say I got a dress that a little bit more and just 42 to your comment about the pasta machine. You gave I think you know, as agile as become so mainstream and I think it would be some sort of Dominus.
 Yeah. What comes along with that is the cottage industry of Consultants? You know, I've worked with some excellent ones so I don't want to be careful and how I frame this. But I think part of the issue, maybe in terms of that Gap in your finding is, this is not where they can holding money is, you know, the small organization. Specifically you can't pee and I don't know if she know where is large checks to have someone come in for weeks or months. So I think that may be a reason is somewhat sordid on address in the in the marketplace. But in terms of the flake teams with one or two people, I'll go back to a start-up. I was at back in 2012, called the next. It was sort of organization for helping people become politically informed and engaged. Yeah, and it was a when I joined, it was seven people over all in the engineering team was to it with me and the CTL
 And you know, I come from working with my team at 10 which was like 10 or 15 or 16 people. So this was much smaller even than that and you know how things were going cuz the productivity existed in the team was already working on it. At that point. I was coming in to sort of an existing situation and I looked at what we were doing and I was like well you know we can definitely use as a practice this year but not like the full Suite so to speak you know like we didn't have. Does it make sense to have a scrum Master with two people? Probably not you know and we worked in Spring. We worked in like 1 week Sprint. Me and the CTO met once a week to sort of put together our stories, what? We're going to work on for this week, we estimated them, we actually started with, you know, allowing some bigger stories to get to the Sprint down pretty quickly. They can blow up for Sprint cuz they were risky. So we made sure to start sort of breaking the stories down smaller, so you know, lower the risk on each Sprint. So,
 He worked in these one week cycles and Engineering for Sprint's and then the overall organization had a one-month planning cycle. So we should have laid out of goals for the month, but then every week update, that plans was like a month schedule and that works really well. I coached the engine being a sorry that you have the sales and marketing team in in the CTO to do more of a kanban style, they were doing so like the whole organization was like on a jewel as sort of a pared-down sort of agile workflow. Have you seen other address practices that you think that work really well when you're dealing with an older code base?
 And then he kind of spiders. Are there some agile practices that you feel don't work? So great. When you work in an older could piss really key code basis? Like we work with that Rubio. You do, would you a lot of rails upgrades for projects that are often 10 plus years old? You haven't had a lot of development or even maintenance that your test Suite is crucial. So I mean, of course, that's like everyone says, It's always important. But with Legacy code, it's it's make-or-break. And I was a special probably especially for an upgrade effort. When we have a prospective client, our very first question is what your test coverage because if it has coverage is really low that makes you have prayed a lot riskier cuz we you know especially with a larger complex that application you know, what were we have expertise on?
 Rails upgrade process. We're not experts on their business, the main. So we really rely on that test coverage to let us know as we work through the upgrade.
 Are we introducing breaking changes? And for me, it's kind of a, my mind help settle a question. That that I've kind of struggled with a long time around test design, which is always ask questions. Like, how much do you rely on like moxon stubs, look like when your unit testing versus like sort of letting the code before we exercised and from the perspective of doing upgrade the mocking and stopping at actually real problem because we want to know that you have been calling that method calling that method that that entire code stream is working. And if you got that fully covered like in your integration test, your future tests great. But often, you know, that's not the case. You know, there's a significant amount of coverage with you and Wes are covered with the, which is what people are often advised to do, right was heard of it.
 Braves, the more that test wheat is actually exercising, the full codebase, the better because it increases our confidence that as we work through the upgrade we're not we're not break without realizing it is interesting because the, the logic that you need to the business, I would expect to be kind of a new in this unit test.
 Yeah. You know, I wouldn't expect the version of rails to matter all that much for for a lot of that. Unless it to you is living inside of a rails model and dealing with you up at what things are implemented with, you call backs in your lifetime model lifetime, books, and things like that. So yeah, I mean, there's often especially going back to older versions of rails, you know, his work. So it's like you're stepping out your active record calls.
 You know, we will know if it broke, you know. And so you know, they're always debates around testing strategies, especially with rails. And I think they're really good debates and I've learned a lot from him over the years. But you know at least from the perspective of like minimizing the risk of an upgrade having that having test the relay exercise as much of the code is possible. The key for having confidence that the upgrade is going to going to go smoothly and when you all find a project that doesn't have enough coverage for you to feel comfortable, what are you doing? I guess. Yeah, so we took a couple options. One is the first work with them on a creasing that test so we'll want them to help us identify like one of the critical code paths. So we can make sure that at least you'll be the most important areas of business logic. Have a good test
 And then the other option is, you know, to rely on the client and help us with manual QA and that can be risky from a business perspective. Cuz you know when your negotiating yo sort of the scope of the project and everything the client will sometime sale. Of course, like we will totally help you with QA and then you start working on the project and it's like oh they've got some other business spiders have to attend to in the way things come up and up Lauren the list and then we can get stalled. Like not having that help with QA is again, they're the experts on their business to Maine. If we don't have the test coverage then we need their q18 to tell us like you know that I'll be up for you to you know whether it's introducing any problems or not. Yes. Oh so testing definitely doesn't important and it sounds like, you know, your
 Your work is impacted by choices that were made in the past as well, right? So like, the other practices that the previous team, followed or maybe the current e, maybe you're helping with the upgrade for something you alongside and another 15 minutes that's working on it. I'll buy, you know, that the choices they've made in the past year, definitely affect your ability to, to be effective. Absolutely, one of the things that I've learned over the years, you know, prior to working a fast Rubio as well, is the practice of empathy for, you know, the developers of the past who wrote this code. You know, when you think about, you know, any decisions you make in life for a twerk, like anything you do is like well if it seemed like a good idea at the time, so
 You know, people are, you know, using the design patterns with their that they know about to pay you. No think are are good solution to the problem. And as people are coming on to the project, you know, eventually years later after those people are gone, we don't know what kind of deadline pressure. They were under or other circumstances that make you look at the total site, what were they thinking? You know, so I think that empathy is always important. You know, when dealing with older lady, who hosts the show, geckos the show with me from here from time to time. She's working on a book and Cathedral from software development, and in, so he has no, empathy is a yo-yo. Austin top of mine for a station that she and I have about about software in and out of, you know, how to approach to the craft of thinking about the other person who's going to come along later in India, W while you're while you're doing your work and then I'll sober
 Looking back on the people who came before and and yeah, I have anybody for, for all of those audiences. It's it's definitely a skill that skill that can be nurtured and grown
 and you can find more information about that book at sympathy. Intex.com guess I'm curious like we are. There are other technical practices that you feel have a big impact on on your work. Sounds like you've had since probably the end of a practice that has the biggest impact you are there other others that that you really, I really value you when you're doing what is upgrade projects. So often the answer that question is, I think more about the engineering practices of the people who wrote the code base, from the perspective of us doing the upgrade the code based out of this, what it is. You know, what this has been given to us and you know, we tried to take as conservative of an approach as possible. When working on a client's codebase, we don't want to come in and say, oh, like let's refactor all this and move all this code around, because we're just introducing risk.
 At that point, we want to basically change as little as possible have a smaller footprint as possible in the code in order to minimize potentially break as we work through the upgrade. So we can really separate the idea of this is the work we're doing for the upgrade from any other work that might have to do with refactoring or new features or whatever. We try to keep those cold changes in conversations really separate from each other and so
 Maybe a different way too kind of comic book at the question of of the technical practices. This it's not really so much a particular practice, but it's more of a, a philosophy of being really methodical code. But when you're, when you're working through an upgrade, it's extremely important. So to give you an example of some products from one of the projects we've worked on, you know, of old codebase upgrading from us for so you know, big is complicated. And then there's a lot of logic that's been separated out into like a dozen different, internal gems that are themselves fairly large databases and themselves have like direct sort of dependencies on Rails. So, like the terms of being methodical like, what's the right way to approach this? Like how do you break it down? So like we start with the smallest pieces. So we start with the the gems that don't depend on many.
 You know, their internal Custom Gems and then we work our way up to the Custom Gems and then we work our way up to the rails application itself. So starting with those smaller building blocks and working our way up to the bigger, more complex set of relationships in the code. So, and in the process of doing that, you know, you can find, you know, it's often a little comment, someone put in the code somewhere that explains the problem you were working on. So we're just sort of always keeping your eyes open. You know, I almost think of it as like a, you know, sort of a hunter in the woods. You know when you're like listening for every tweet that might snap for bird call or whatever. Like okay, what's going on? Keep my eyes open, you know, you never know what you might see, that's relevant to the thing, you're trying to track down which is, you know, sometimes those mental images.
 Yeah, yeah yeah. I can I can also imagine that you all become experts at just getting a Devin varmint up and running for a 10 year old project. Yeah, I am in to me, that's also like it when I say something about that in a second, when I was 12 years old. I'm so mad at myself here. So 1982, I got a Commodore 64 and loved it and I used it all the way through college. You never went by, then was on Max for PCs. I was still sticking with my, door and I kept it as a hot. I don't really do anything with it anymore. But for a long time, up until maybe 10 years ago, I was still full around with it. And there are
 You know, sort of obvious out there who, like, we're still making hardware for it. So there was like a plug-in cartridge. If we go on the extension for it, that's like gave you a plug-in ethernet cable into your Commodore so you could like put it on a network and I think how am I going to get all my old, you know, all the college papers? I wrote that are on these floppy disks that are compatible with anything. Like how can I get them off? So is like a fun sort of project. So the reason I'm talking about that is
 You know, often what we do, has a similar feel to it. So there was another project we've been working on recently. It was really old rails to and the start of our projects and came to this company through acquisition headlight customers on it. But the developers are themselves, like didn't even know how to get it going in the development environment or just kind of sitting out there in production. I was like, well, you know, I got my son's old Windows laptop from 2014 and I can put cuz it's running YouTube 1214, you know, this area. Well, and the white version of Ubuntu cuz when you dealing with something at all of you, like you need, you can run it and we were trying to figure out how to get it going and Doctor, which is a whole other complicated story. So I thought, well like let's try to get it running. Environment was just a line 4th and to me, that's the fun, you know, taking old thing then like trying to read me licenses.
 Yeah, in in in your like why you don't have to stay there, you're getting it working on. Its current. It's his current versions is definitely an important step in and talk to her. Then we can start upgrading it, you do bring it into the if not for the present at least two somewhere in the past 10 years with with rails versions and Ruby versions. You know that you are those old packages still available like me or you are kidding cuz I know it like the old having done some real work in the past, like something that would always frustrating. Me would be like, will nokogiri compiled on this Mac and if we actually, I was surprised has actually went quite smoothly on the older Hardware. The thing that I ran into there was a big problem.
 I didn't anticipate it all, was it doctor has changed a lot in the last 10 years and it I couldn't really run newer versions of doctor on the older system to get it dockerize the way I wanted to. So yeah, sometimes a problem you're running probably run into aren't the ones you were expecting. I was expecting that nokogiri problem and had it but I ended up with the other challenge to figure out. Yeah, yeah, yeah it was like for you older versions of Ruby if the GCC version is to new it won't it won't compiled on in and things like that. So you end up with these like you interesting interesting dependency this where it's better than the movie Project necessarily identifies. The GCC version has a dependency or the other. They might have but but you know, you did hit point where you GCC became.
 And your drop support for first off and then and then the old older things, don't build until you end up having to like get an older compiler, toolchain put together and things like that. So yeah. And you can run into it, you know, just a myriad set of complications, kind of run older code on a newer system, similar kind of challenge. We had when I was at ice blue actual, that's another topic that sack blue whales party. Goes back to my 2004 you know. But yeah when I was there which was I guess 6 6 or 7 years ago now about half the developers were having all kinds of problems and really hard to track it down and it was like a minor version difference on an open SSL, you know?
 Sometimes hard to track down is a Docker image that the cardi B Team maintains for an older and older Ruby products. I'm trying to find it. Yeah, I was leaving, I should mention for a time. I was leaving. They were everything was so nice of ya. Been a great tool to kind of be introduced to the, to the tool box because it it helps take that readme file with all the steps and things that you would have needed to do. It has everything been clearly documented in detail, and we would have been in that readme file a flight from this Commander, in this matter, in this command. And now you have that you written as a Xanax, kuebel file
 And sometimes it doesn't work. But it's at least a fleece, the starting point for, okay. We'll just probably worked in the past. So then what's changed in the ecosystem that kept us more. Yeah. And then just put just when you think you solve that issue. Like I do a new challenge comes along. So like at the rails, earlier this year me and Ernesto and Luciano from subio we did a workshop like I'm hurting real. So we found an open source project to do the workshop with and you stuck with something pretty simple for the purposes of a of a workshop unit, only a couple hours and we realize for paying for the workshop like anyone who's using a Mac and one is going to have a problem like cuz even with Dr. You know the performance was just horrible translating across the different chip architectures. So yeah we we plan for when we ended up rebuilding the docker image for the mac and Juan Soto.
 And ready to go. So I can one use this image if you're not on the other one like use this. So they're always you know every advance in the technology applications for anything this sometimes not even that old, I found that it's a ruby 193 Docker image cuz it was, we found it particularly challenging to get Ruby 193 to build especially on Yo, newer machines. So getting up that version and so, yeah, it did it, it helps to have you that that, that will be attending the M10 that that chip architecture difference is you don't like, that's something that I'm kind of glad it hasn't become problematic yet but I'm nervous about a a bug.
 Existing production and it not running your that dead bug not being reproducible on my local environment because of the chip architecture difference. Yeah, I have a nice day, I may be out there. I haven't either I'm going to hasn't manifested but it's something that I've been nervous about just cuz yeah, that's something that I that I've always strive for, on teams is try to get the local environment to be as close to Perfection as possible. And now, there's this new processor architecture difference, and it's like, Ugh hiring cuz we could have developers to join us the laptop and it's like in the latest best computer. But it's like, well might make their job harder, you know, work it working with older code basis. So then you say, well, you'll get him a PC and they can run Linux. But then, you know, it's pretty typical on upgrades that we do this. A readme assumed you're running back with unproven everything.
 Do it on Monday but you going to try to figure something out for yourself. So yeah, sometimes the answers are not obvious virtualizing old versions of of Mac OS has no that's that's challenging as well and that's not, you know you used to run to the processor architecture problems.
 So yeah, it sounds like you get an older and older until Mac, and, and try to keep it alive today.
 Just just just to make that was frustrating. So I'm confused about like no other challenges that that you are run into. So you know you talked about your kind of string with a simple stuff in and working your way up. I can't imagine third party packages you that aren't necessarily rails and aren't Ruby but our kind of members of a ecosystem. Imagine imagine there's some pics that that pop up from time to time for you all in one of them. All extensions of those can be problematic, Dockers been very helpful with with all those issues. So we can create an environment you do for doing that upgrade without messing with the developers. You know, the regular sort of more modern libraries that are on that developers computer but maybe if I can take
 Certificate to a non-technical for related thing which is I think the importance of of professionalism especially when dealing with, you know Rubio dealing with clients external clients but it's just as important really, you know, for you know even if you want just a regular, you know, product development team with internal clients. So what I mean by that is importance of speaking up and being honest with people, you know I feel like in my career like that sort of sort of the biggest are dysfunction, did you just see over and over again in organizations is know the business side? There's always pressure. Do more, do it faster? What year were people? Maybe, you know, and developers like okay I have to cut Corners, I have to skip
 I'm 52 years old. So I can set you have been around the block if you died and went to see these things over and over again. It's like no, just like, you're digging the hole deeper and this is just going to make the next thing you have to do even harder. And there's a good forward in the book of the king told her before, it was written by Matthew Might mispronounce. The last name pastor and he talks about a development team that's in this situation. You know, got to meet this deadline and then like 15. Does it like you're ready, you know and the managers comes back to do. You know, we we can't go live and it's like a lawyer's of course lawyers.
 And really the point of that is when you think of professions like lawyers and doctors part of their training, isn't just learning the law and order medicine. It's like how to behave how to behave with your clients, how to behave with your patients, you to bring that are of of, of professionalism and confidence to how you communicate and how you relate to people. And I feel like, that's something that's really important, for software Engineers to learn how to do to, you know, you're always dealing with your manager, you're dealing with clients and when I first started putting my toe in the water, like I should say something about this, you know? And I think maybe maybe I was lucky early on if you're saying, hey, you know what, we really need another week or whatever. You know, this is why I was like, okay,
 Like I said it in like like they're glad I told him there was an issue and like they're going to give me more time. Sometimes you just have to say it, you know, some people are even afraid to speak up or is this how we not that easy sometimes you speak up when you get pushed back anyway. But in those cases, I think it's still really important to communicate the trade-offs of business. People are in the, in their job, is to make money and they need to hurry and help the company make money. So you can get your salary in all of that. But it's important for them to understand the cost of the benefits Awards. So you can say, like we can do this, we can ride, we're not going to have the test coverage. We need, we could watch it on your break cuz what I found this, you're learning things. The hard way in life, you don't speak up. You know what? That something goes wrong.
 It comes back to you say, well, this bro, why didn't you do a good job and then and then it's kind of too late to say well you didn't give me the time to do a good job, you know it was too risky or yeah, I got it after the fact that opportunity slept so, you know, always making sure you're working with aware of the risks of these decisions. You know, have to do with how many people can we put on it, or how much time do we have? Our, what's the scope? You know, those classic set of questions that drive every project like to try not to be shy about communicating with the risk that you see? Cuz you're the one who's close to the code of business. People don't know the intricacies of. That's what you know, and you should be able to just tell them that the opportunities and the and the rest that you see, you can't do it, right? So like they may need to be able to trust you.
 And trust that you're being that you do you trust that you're looking out for them and trust that you're not just you trying to milk them for more money or you you and you or trust that you're not incompetent right like just yeah and you know so just relating that your recent experience of working with a client you don't have even just the past couple of months of like looking at this old code base and seeing all these challenges like how long is going to take? Should we consider rewriting versus upgrade? Cuz it's so old and like I've tried to be very clear with the client, you know? I like I like they're not going to want to work on you know that that's you know what do you call a sort of the Imposter syndrome voice that you know everybody has them always hearing that in the back of my mind and I'm thinking they're not going to want to work with us. They're going to be mad and giving him. The bad news is all these problems. It's going to take a long time and cost him a lot of money and the responses.
 Been there. Like can you put more people on it? Can we give you more money? Like they would, they want to get it done and I think they appreciate that, you know? I mean really clear and you know, me and the rest of the teams we can confidently about the technical challenges involved. Why we think just, you know this is why it's going to take longer these with either the problem areas and so we're building their confidence. We know what we're doing and the other willing to keep working with us, rewrite or fix is something that comes up a lot when working with older older systems, what were you fall? Kind of all on that issue in. And how do you decide the answer to that question?
 can I say it depends what to depend on but I think often it's a really hard question and in my experience and just, you know what, I've learned talking with other developers is
 You know, often with a really large complicated project, and if it's really older, the code is really messy. It's kind of a gamble either way. Like, there's no like, guarantee do, like the rewrite is, you know, you're guaranteed to work out better than them, you know, doing the it's just a regular up gray or the refactor. I think, in general, you know, might buy General. Disposition is to lean to the side of keeping the code that you have and refactoring or added adding test coverage. And the reason for that is there is often a great deal of embedded wisdom in the code that is kind of Silent it. What I mean by that is you know somebody made a commitment years ago that solves some certain problem, there's no comment on the code. You know, maybe they get message, doesn't commit, message doesn't say a whole lot about it, but if you
 Rewrite and just sort of start from okay, like a list of business requirements and extracting, some methods or whatever, like their stuff you're going to miss you know and things when you don't even know where they are that are helping keep this thing alive. So you know positive way I try to think about Legacy code is like just it is still here, it's still here, it's still works. It may be messy and may have problems but it's working in a serving our customers or clients or whoever is using it and send it.
 Battle-tested in that way. And, you know, so like I was saying, you may miss things with the rewrite and then there's a slight the classic problem of like, okay, we're doing the rewrite and it's going to take six months or a now, it's going to take a year and we need to add new features. So now you've got the parallel development going of people still having to work on the old one and work on the new one. And you can often end up with like, having to rewrite the rewrite, you know. So I do feel like the rewrite is often, I guess the riskier approach but I think like thing of some of the projects we were looking at currently at SS Ruby. You know said well maybe the rewrite is the right thing to do cuz like this Israel's to, we want to eventually get up to real seven, each version jump.
 Like there's work to do on each version, jump things and rails, change know the routing completely change your funerals. To in 3 they're always changes to like how active record works. Like there's going to be a lot of investment to take it through all those version jumps. So, and there's also just a lot of us learning. How does this thing even work? You know, so often in it, if it's something that's like that old. Maybe the rewrite is the more efficient way to go. Yeah. So yeah, it depends, I guess it's my short answer but leaning towards sticking with the with the refactor or the upgrading existing system. If I'm remembering correctly that, you know, you all take the approach of upgrading one person at a time. When might you consider just jumping straight to the latest and and and then
 Trying to trying to make that work. Honestly, really just with the most recent versions jumping from like life version, five to version 6 and maybe skipping minor versions in between like I think as rail, his has evolved and you know, we think everyone involved with maintaining rails, you know, he'll make the system better and better over time that the pain, the level of pain in those version jumps I think have gone down, you know, with the more recent versions but I really wouldn't skip it on on earlier ones. For example, there's another one we're doing right now, and we're doing a series of version. Johnston right now, we're on 40 241 and you like my new version jump. Probably not a big deal. I was like, well yeah, not that one. Yeah, like spending an enormous amount of time going through all these active record for age cuz like being away, you know.
 So it's like we have to look at it like every query and like understand it and figure out the right way to rewrite it. So I really wouldn't want to get multiple minor versions there because then you just start pounding the number of things that can go wrong, you know? So it's better to try to do one minor version. Jump at a time with the older ones are the strong parameters switch, was another one that I remember very challenging as well. I forget which two versions that is but that was a minor version as well. End up, putting them on a gym. That's for the continued, letting you do things the old way. You know, if I got her accessible is often the the rewrite of that is so significant, that's like well, why do we support continue to do with your older code here and then like your team can maybe work on that piece of it later? Or you can pay us to come back and do that part at a later point. Is there fun challenges?
 But yeah, you don't have those work around things like active record queries.
 Awesome. I really enjoyed the time that we've we've had chatting together. One of the last things we'd like to ask everybody on the show is yo what do you love about me? Cuz you could cuz work never try to change people's attitudes and an end change people's minds at Legacy code. Isn't a bad thing. So what is it? What is it? You love about it. Yeah, I think the wisdom of the code that's in there. It's often that wisdom, you can't see, but it's in there that says an application that's alive and working and has stood the test of time and maybe it's has some some words that I heard a rough around the edges but you know, I still deserves your love, that would be one thing and then the other and this is something that, you know, some sort of Barry from person to person depending on like you know what, you find engaging. But for me it's like it's at there's a certain element of fun and just taking
 And like breathing new life into it and you started moving it up to work with a more modern version. Two rails or whatever you do for the environment you're working in. Damn. Yeah. I like that to like just the preserving preserving the work that someone else has done and make it last longer.
 Awesome. Thanks for taking the time to chat. If people wanted to get in touch with you, to ask you asking more questions or maybe you hire fast Ruby to help them out on their real tree project? What's the best way to get in touch? And then for fast Ruby? We have contact form on a website. So if you go too fast for me. I owe the contact form is there and you can reach out to us. So thanks a bunch of that. And then for people who were listening, if you'd like to do have conversations with other people who listen to the show, you can head over to slack that Legacy. Cool. Rocks and join the slack workspace in chat, with other people who were part of the the Legacy. Good, Rocks Community in and chat about what you put on the show or other ideas or challenges that you might have on a project that you're working on.
 You can also attend our weekly virtual meet-ups they meet a 1 p.m. Eastern on Wednesdays and yeah that's a great place to hang out with other folks who were also wrestling with with older good basis. So thanks so much for listening and we'll see you in the next episode.