How GenAI + Automation Are Going to Revolutionize Legacy Code Migration

Speaker A: 70% of the software that's in use at Fortune 500 companies is 20 or more years old, uh, which is crazy. Rearchitecting and modernizing your applications as the business needs to arise is like not something that's going counter to what the business is trying to do, actually help the business move forward.

Speaker B: If you're a tech leader looking to learn today's best practices for leading high functioning teams, you're in the right spot. Uh, in each episode we learn from today's top tech leaders as they share their successes, their failures, and the new lessons learned along the way. I'm Debi Madden and this is the Scaling Tech Podcast, your blueprint for scaling tech teams. Let's dive in.

Speaker C: Hey everyone, I'm Debbie Madden, the host of the Scaling Tech Podcast. And today I couldn't be happier, uh, than to have a wonderful chat with some of my favorite coworkers, Michael, uh, Carlson and Michael Wytak. Hey guys, how you doing?

Speaker D: Doing well. Nice to see you today Debbie.

Speaker C: Awesome.

Speaker A: Happy um, day.

Speaker C: Happy day indeed. Um, so we're going to be talking about, for those that know Stride, you might have heard us throw around this really cool new offering called 100X. Um, it's um, related to software development, generative AI and we're going to really be focusing today on giving you the Inside Scoop on 100x and really importantly, honing in on how this is going to revolutionize legacy code migration using generative AI and, and automation. I can't wait to get started but like let's just level set, let's just start with, I like to start these with like a vocab lesson if you will. Um, so for those that haven't heard of, of 100x, like what, what is stride 100x?

Speaker A: It's a great question. Appreciate m it. Uh, so stride 100x is our new service. Um, and what it does is helps customers re architect and modernize their legacy applications. So I read a stat recently. It's like 70% of the software that's in use at Fortune 500 companies is 20 or more years old, uh, which is crazy. Which means everyone is dealing with these legacy applications. Um, and so we're trying to help folks solve that problem because they're falling over, they're aging out, there are all sorts of challenges with them. We can get into that uh, a little bit later. But we're trying to help them modernize and we're using gen, uh, AI, we're using automation, we're using good old fashioned engineering, uh, to help them Reduce risk and accelerate the delivery of those modernizations that they need to do for their business.

Speaker C: And I believe that we are enabling modernization in a way that wasn't possible really before Genai came. Right? Meaning like, yeah, it's 70% of the code is 20 plus years old because it's not awful. And it slugs along and people almost like you just accept the pain. But it's kind of like now there's finally a better way. Right?

Speaker A: The equation is changing. M. Before you used to have to have um, that you still do, but you used to have to pay a lot of political will, right, to go do one of these projects, right? You need to get a lot of people involved. You needed to work with the business and say, hey, like we're only going to be able to do a fraction of what you want coming up because we got to save part of the team to go do this thing which may or may not directly influence like your objectives for this year. So like it, it was this sort of thing where you're like, well we're going to go do this thing for a couple years. Um, and so what we've been doing with 100x is to try to accelerate that so that it's more palatable, less risky. Um, and it's something that like you can and should do on an ongoing basis. Right. Rearchitecting and modernizing your applications as the business needs arise is like not, not ah, not something that's um, you know, going counter to what the business is trying to do actually like help help the business move forward.

Speaker C: Ease of friction between like we have to stop everything and only update this 40 year old COBOL or C Sharp or Net code base versus okay, we can really kind of do more than one thing at once thanks to some of this um, technology innovation. So. All right, uh, thank you for that. And so how'd you come up with this idea? I know I've been working with you guys over the past year or two. Just really go out, see what people need, see where the pain points are, see what's possible. But how'd you really kind of land on legacy migration using Gen AI and automation?

Speaker A: Well, so we were doing a lot of customer development for, for Stride Conductor. Um, and so we were talking to a lot of people about their pain points and the things that were challenging for them. And Conductor came out as a product uh, that helps people generate tests. We had other folks who needed something that was more of a service in order to kind of help them get out of jail with their Applications. And so we dug deep into that and we learned about um, these applications and how they were preventing people from achieving their goals or they were really fraught or they were really kind of worried about um, making these changes. And we thought, wow, what if we could do something to help solve this problem? Um, I want to rewind the clock a little bit. We were talking to a customer uh, about 18 months ago. So before a lot of this Genai stuff started to take off and he was telling us about he, he had inherited um, an organization. He came in as like a new CIO cto and he had like the, the work the team was doing was, was great. They were doing these sort of modern practices and these applications, but they had like a couple of applications that like very few people even knew like what was going on inside of them, right? Like they like no idea. And then these older languages and older frameworks and folks were sort of moving on or aging out of being the people who were doing that work. And these things were just falling down all the time and they always needed patching and that person was on vacation and he had this massive anxiety heading into his quarterly executive off site each month or each quarter because he had to talk to them about the bugs in these systems. They were so problematic that like the CEO knew the name of the product and knew the name of like the people working on the product, right? Like it was like this thing and like, so he kind of had this choice of like, do I go after this thing? Could be a multi year project. I might not have the same people at the end of this project as I do in the beginning and use all of this political will and maybe it still fails because so many of these projects fail. Or do I just like kind of like hope that the time bomb doesn't tick off, right? It doesn't go off while I am sitting here. And he was sort of getting to like a place where like he, he was getting ready to retire as well. So he was like making this like calculation and I was like, I was like, this is horrible, right? Like you're just in this terrible situation and like, you know, so we were talking with that person and then we started doing this customer development around like the, some of the things that people were hoping we could help them with with, with Gen AI. And like these people just came out of the woodwork like it, like this is everywhere, right? Everybody has this one thing that they don't really talk about. It's business critical. And they're like, dear God, please don't fall over.

Speaker C: Right, right, right.

Speaker A: Or like, okay, this person is on a m. Month long trip in Europe because they've been at the company forever and accrued vacation. And like, if this thing goes down, what are we going to do?

Speaker C: Right, right, right.

Speaker A: Like, you know, finance is about to process a whole bunch of stuff. It's going to go through this system. Is there going to be some bottleneck? Like, what's going to happen? And so like, we're talking to more and more of these people and we're like, okay, like, let's dive into this process. And this is like, this is where, where folks like, like, like Michael, our other colleagues, AFB and Ken Judy, like we're doing work with our customers and just learning like, how are you thinking about these modernization projects? Where are the pain points? Where are the failure points? And can we do things to help accelerate through some of that pain and reduce some of that risk? And that's sort of where this whole thing came from.

Speaker C: Yeah, I mean, I was literally like sighing heavily as you were describing that. Um, I know so many people that live with that pain and it's. Even if they knew someone that they can tap or a team that they could tap, there's so many roadblocks. The, the budget, the. How do we really exactly know what to work on first? How do we really know if we fix something that's not going to break 20 other things? Right. It's not like even all of that pain doesn't even equate to being able to act right. There's like so many, there's so, there's so many like just giant dominoes, like, standing in the way of like now we're going to modernize this thing. Um, so like I'm, I'm really excited that we're tackling this problem because it's, it's real and, and we've seen it. And I know people listening have seen it. Um, so we've talked about some of this already, but um, you know, there's lots of numbers floating around. About 70% of code is, you know, 20 plus years old is for the Fortune 500s. 30% of time is spent on tech debt. You know, there's like, we, we all, like, we can, we can argue Amongst the nuances. It. 20%. Is it 21%. It's a lot, right? Like, it's a lot. But like, what, what are, what are, you know, our clients and the folks that we're talking to kind of really struggling with the most inside this, this legacy software ballpark because Like I, like, like we said, like, there's so many, there's so many giant walls that you bump up against. So. Yeah. What do you guys see the most?

Speaker A: Yeah, and, and Michael, feel free to jump into here too, because you've been talking with a lot of these folks. But like, uh, a lot of the people that we speak with, specifically folks who have legacy C. NET applications, the first thing that's the first domino or the first hurdle that they have to get through is what is this really doing? When this was written, nobody was here. Um, we've developed this toolkit that like, helps them go through the process and like, explicitly, like, starts there. Right? Like, how do we surface what's happening inside of your application?

Speaker C: Yeah, go ahead. Uh, Michael, before you say, I just want to understand. So 100x, like step one is a toolkit that tells us status quo, where stuff is. So tell me, like, how does that work and how long does that take? And like, that seems like magic to me right there. So tell me. Yeah, Michael, go white talk. Tell me what you're going to tell me and then also help me understand the, the, the status quo assessment.

Speaker D: Yeah, I think to give a little bit of a framework for what type of problem we're solving here. If you're looking at what I think most people use Gen AI for on a daily basis in a coding context, you're producing lots of code and you're giving the LLM, like the concept that you want it to represent in code. And you're saying, I, uh, want an API endpoint and it needs to handle customer data. Here's what the customer data looks like. We want to store it, we want to be able to delete it, we want to be able to update it, that sort of thing. And that type of problem is good for active development on a product. And the fewer constraints you have, the more applicable that is. So if you have no constraints, which makes for a really great demo, you can magically produce an API endpoint almost wholesale. Um, and that's really awesome. But the more constraints you start adding to that, um, the more difficult it is to maneuver. And that's really where you are in one of these legacy systems. So the problem's a little bit different. The, the concept that you need to be able to articulate is very nuanced and you can get bitten really badly either by lots of rework or never actually modeling the system correctly when you do the rewrite, um, or the modernization effort, however you're attempting to do it. Um, if you miss things and typically in these situations, your business is depending on the system to run in this way that it has been running, and even in ways that are pathological. Your business is now going to maybe be feeling the pain of long development cycles because it's an old system and engineers aren't around that, um, are super fluent in it or there've been many engineers. So there's just a huge mass of code. So then the business starts solving problems with what exists already, even if it's suboptimal, maybe slightly incorrect, or has lots of rework involved in it. Think like reconciliation jobs that go through to make sure that like before we really send the billing out, like let's check for all the errors that we know happen every single time. Um, and those sorts of, of problems are really problems of understanding that are cross disciplinary. So you have code architects who may be architecting a new system, whatever the rewrite is. You have business analysts who might understand the business, know what they're trying to build. And you might have software engineers who need to contend with the realities that are in the system. And the approach we took is to actually look at the software itself, inspect the code, and we actually trace the code by, uh, specifying an entry point into the code. And this is highly specific to C. NET code, uh, where we have a tracing tool that works with the Roslyn compiler for C. Net. And we can actually hop through the code from that entry point to each of the other nodes that are attached to it. For some of these old applications, that means going all the way from the form that you might see, say in the web UI through the business logic to the database. And then we actually take the database schemas and can visualize those along with the code. So you know, what proportion of your database is getting hit by submitting the form for, you know, adding an item to the shopping cart or for pain, or adding an inventory item, whatever it may be.

Speaker C: Got it.

Speaker D: And that type of, we call it a kind of a tracing process. Um, it narrows the proportion of the code that we need to be concerned with when we do the rewrite and then it allows us to recover some information through Gen AI automation about what the heck is going on here. So we can take essentially an exhaustive list of all of the pieces of code that are between you when you do your action in the application and your database. And then we can submit those to an LLM and get the LLM to tell us, you know, like what's going on here, what are the business requirements, what are the non functional requirements that you can glean from this code and the cycle time for doing that is reduced to generally minutes. Um, for us to be able to do these traces, if we can build your application once and then we can do these traces, you get bootstrapped. What the heck does this thing do that your BA and your architect, your software engineer can start to inspect and then we can talk a little bit more later about like, what are the things we can do with that. But the first thing we can do is like facilitate the important conversation that needs to happen to be able to do something productive for what we call kind of like a vertical slice of your application that you're trying to rewrite.

Speaker A: I mean, yeah, so like, if you, if, if you were sort of getting together and we're like, okay, we're gonna, we need to modernize this application and we're gonna try to do that kind of domain, domain, domain by domain, slice by slice, idea by idea. Typically your architect is gonna go into the spaghetti and start to pull the spaghetti apart, right? So the, like, it's not this like clump anymore, it's, it's this regimented sort of thing. Um, and so what this does is it does that part kind of automatically and in a way that you can then figure out what is actually happening. Like one of our customers, um, was like, hey, we're, we're working on this part of this application. We're trying to dive deep in here. And it starts from a form and sometimes there's a fire icon next the form. And I have no idea where that comes from. And we said, and we said, okay, let's run a trace. And I think, I think it was like hidden in some stored procedure somewhere or like. But like we went to the form, we traced through the form, we came back out, we pulled the requirements out, we said, well you know, the fire icon pops up because of Baba Baba Boo. And not only that, it's this color when this happens and this color when this happens. And he went, I didn't even know it changed color, right? So like what's great is like this process that, you know, somebody would have to go and basically de spaghettify and inspect and then have some initial conversations with their ba or their product person or somebody on the business and then go back and spelunk some more and enrich that information. That's like two, three, four, five weeks depending on how complex something is. And we're able to facilitate that conversation like same day. Um, and so that's the first hurdle that's huge.

Speaker C: I mean, and I think three, four, five weeks is you're being nice. I mean you're talking about somebody going into a system having to go find the humans, go find the documentation, go look in the code. By the time they do all that they have to get signed off, the thing has changed, they're on another project. I mean the risk is the time could be infinity. Like the range on this could be two weeks to infinity. It could be two weeks manually, but it could also never happen. And so what we're saying is we're really kind of what we're doing with this tracing, uh, step one of our 100x offering is this really is game changing. Um, and like once you can understand what's happening then you can then go and take action and, and then the tracing tool, we can have that conversation same day. But am I correct to understand that you can then run that again and again? Right. And not just a one time thing. You can, you can kind of like always have these eyeballs on, on everything over time.

Speaker D: And Michael Carlson used the word like it's, it's automated. It's more than just the automation. It's that it's systematic. Got it. So when you're rerunning it, you're going to get um, not necessarily a deterministic output because you're, you're right, the code may change. For example, um, you know, you might choose a different entry point to trace through. There are parameters that could change it. But you like any tool, get used to the type of output that it produces and the degree of exhaustiveness. And I take kind of a, a term from like the DevOps movement where you're trying to reduce toil, which is like this low value work that people do over and over again. And when people are developing software, this type of design brain is kind of just inherently part of the process that a team goes through to take the concept and put it into code. And people view that as the work. We can do it in small bits. And it gets better because people are collaborating, they're putting their ideas together, they're putting it into the software. But when you zoom out into these modernization efforts, you start to realize that it really is toil, like it's, it's manual labor, um, that people are doing to systematically go through and be exhaustive. And so the fact that you can replicate that makes um, a big deal because you know you can, you can go through each three of these slices of the application and, and use that same type of tooling. And same type of approach over and over again.

Speaker C: Yeah, yeah. Um, yeah. And I mean it sounds like, like it all, like it's still like I've been, I've been learning about this with, with our team for some time now and it still sounds like too good to be true. But I know that it exists and I know that we um, are capable of doing this and we've, we've done, we've done these tracing and exercises for, for many. Um, and I'm just so excited that we're having this conversation because I think there's like this whole world of what's possible like now, 20, 25, not next year, but this year. So thank you for that. And so like where I, I want to like kind of end with two more questions. Like the questions that I get asked most. I talk to tons of CTOs, heads of products, CEOs and everyone's using like the, the co pilots of the world. And so like how is, how is 100x different than. Let's. I'm just going to throw three out there but there's, there's many other options but like, like co pilot Aer Klein and you know that we can't answer like all of them. But just like what, like how do we stand apart in this, you know, in this space? Because I know that people are trying to kind of make heads of tails, like where should they invest to learn? Because like you said, oh, you have to learn the tool. Like you can't learn 100 tools. Right. And so like how are we unique in this, in this space?

Speaker D: Yeah, I mean the first distinction I'll make is that those tools are really good at going from the concept to code.

Speaker A: Okay.

Speaker C: Like you said earlier. Yeah, yeah.

Speaker D: We're essentially doing the reverse process at least in this beginning portion where we're taking the code and we're trying to extract like the, what the heck is going on in terms that people can discuss with one another. There are, you know, cross functional groups of people. So it's not just an engineer who's trying to specify the type of representation uh, that they want and then verify that there's multiple people who are looking for the, you know, completeness, truthfulness, um, and you know, the exhaustiveness of the, of the outputs that um, describe their system. And we can then use those outputs to get those small slices of code. And everyone's aware of kind of where this came from. So you imagine taking a bunch of business requirements that you've been able to extract from a trace of your code. Base and then automatically produce user stories and people can audit those user stories, you can hand those to the team and the team can operate in the way that it mostly operates today. And then one final thing that we're capable of doing really just kind of comes back to the type of tooling you just talked about. Where you now want to make new representations um, is we can produce first drafts of that code for those stories. And, and in that case I think the difference between using our tools versus copilot at our client is not so much about um, the specific tool in those cases, but about the context that you're able to pull in to do it. And that's what we're giving you. It's part of the reason why this is more of a services uh, bend to it instead of a full on product because your context is going to be specific to your business and you may collect or develop that business context in a number of different ways. But we're capable of retrieving that from ah, a data store. And we provide a retrieval, augmented generation or RAG store for the LLM where when you try and make those first cut representations from say a user story, you're pulling from that code context that we talked about, those business requirements that we generated and then people may have edited and then any other documentation that you want to just kind of supplement and we do the type of similarity search that you would see in a number of tools that use a RAG to be able to make that available to the LLM. When you're doing that rewrite, I feel

Speaker C: like I'm going to go ahead and make a prediction that there's going to be a new class of code. So we have like, like new code, modern code and we have legacy code. There's going to be this middle class of code, I think we're going to call it unseen code. All of these products that you're saying first pass at writing things, your copilot there's going to be so much code written and it might do a thing correctly, it might be able to build a feature and that feature might work for some time. Um, some of that code generated that human eyes don't look at. It's going to be great for a long time but a lot of it's not right. And so like I think, I think 100x can also map. I think this is going to happen very quickly. It's like well this legacy code that was written 20 years ago, but then all of this unseen code that's also going to need to be Pulled apart and that also nobody knows what does. Right. Like, it's going to be new, but it's also going to look like the old stuff. It might be written in new languages, but there's going to be a lot of, um, like, like fuzziness. Like, what is that for? And why did we do that?

Speaker D: And, and sometimes it's a prototype, you know, so like, people are using it to actually put the ideas to the test. I came up with a design, I produced this code automatically. It's, you know, some probabilistic representation of the design that I put together. Oh my gosh. It really doesn't facilitate the type of thing that we need to facilitate for this module. Let's go back. This was actually kind of cheap to do. I didn't send a team out to do it for six weeks.

Speaker A: Yeah, there's this sort of, uh, you know, point, uh, off in the distance that Michael and I, when we get, you know, foggy eyed and you know, Muse wax lyrical and talk about, uh, I think this comes probably from like the XP idea of like, if something's good, then you should take it to the extreme and do it all the time. Like, if there's this idea that being able to re architect is something that's going to serve your business better, you should be re architecting all the time. And the tools that we develop, that others develop, that get developed, like, I think are going to get us to a place where you're going to have architectures that are rapidly changing in the future in ways that like, would sound crazy pants to us today. Um, and this is sort of the part of that journey of being able to take advantage of a business of let's crank our spend down or let's increase our render time and having those things that will help us figure out what are we going to re architect or what are the weird requirements that got in here or things that we, you know, features that just like, sort of vestigially live on forever inside of a code base. Like, those things get cleaned up. We can clean things up, we can re architect them, we can change them over time.

Speaker C: Yeah. Awesome. Awesome. So, um, what I want to do, I mean, this has been such a great conversation. Like, I know 100% we could talk for hours and hours. But, um, I want to, I want to kind of wrap things up and I want to say to everyone listening and watching, this is obviously the tip of the iceberg. Like, if you are, um, feeling any sort of pain, if you felt yourself like sighing or your blood pressure rising as you were listening to us talk. It's okay, because we can help, um, and we can help educate you. We can help educate your team. We can help you trace where things act today, whether it's something new or something that was written 20, 30 years ago, whether you're in manufacturing or industrials, automotive logistics, outside those industries as well. Um, we're going to be putting in the show notes, um, a link so you can have a chat with us, so we can show you 100x um, and how it relates to your needs. Um, we'll also be putting a video in there. You can also obviously reach out. You can find, uh, me or Michael or Michael on LinkedIn. You can go to our website. Uh, there's many ways. You know the drill. Um, so, guys, listen, thank you so much for, for all this. Um, um, I always learn new stuff when I talk to you guys, and this was no exception. And thank you to everyone for listening. And Michael, Michael, have a great rest of your day.

Speaker D: You as well.

Speaker C: All right, bye, guys.

Speaker B: Hey, everyone. If you've enjoyed today's episode, remember to subscribe, give it 5 stars, and more importantly, share it with someone that you

Speaker C: think will benefit from listening.

Speaker B: And remember, as always, think about the one to two key takeaways that you can apply today to help you and your team achieve your goals. Until then, keep innovating.