Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
AI-Powered Migration plus Raw Experience with Mike Rousos
5 Plays15 days ago
On this episode of Hanselminutes, Scott Hanselman talks with cloud migration and app modernization expert Mike Rousos about the challenges and opportunities of bringing decades-old applications into the modern era. They discuss practical strategies for app modernization, how AI and GitHub Copilot are reshaping developer workflows, and what it takes to transform legacy software into systems ready for the future.
This episode is sponsored by Tuple and CodeRabbit
Check out https://tuple.app/hanselminutes for the best remote pair programming app on macOS and Windows
For effortless AI code reviews, go to https://coderabbit.ai/
Recommended
Transcript
Intro to Tuple vs. Business Tools
00:00:00
Speaker
Hey friends, it's Scott. I want to take a moment in the middle of the show here and just thank our sponsor, Tuple. I'm chatting with Johnny Marler from Tuple. You know, Johnny, why do most screen sharing tools suck so much for developers? Like business folks, they love a good Teams call or a Zoom call, but for programmers, it just doesn't feel the same.
00:00:18
Speaker
Yeah, I think it's you know business people are doing something completely different than developers. you know They'll get on a call and they'll share slides or share a doc and just use it to talk.
00:00:29
Speaker
But you know when we're developers, we're actually creating something together. So it's really nice to have that tool that's specifically tailor-made for that process. um I know if you're a programmer and you've done any pairing, we've all been there where you know you're trying to dictate, hey, no, change that function, no, and not that line, that line, or you're trying to to verbalize a CLI command is space or dash or was it forward or backslash? it you know when When I'm pairing, I need, I don't know about you, but I need all my brain cells.
00:00:58
Speaker
um and I don't want to be wasting them, like trying to verbalize that communication. So um Tuple just makes all that easy. You get one click annotation tools. You can share control by default. There's no hidden settings that you have to go through.
00:01:12
Speaker
And there's no like Chrome or like UI that's covering up your IDE. It's just It's just made for programming and I think once once you try to pull it's really hard to go back to generic screen sharing tools.
00:01:24
Speaker
It's really hard to go back. Actually, that is super true. You can check it out at tuple.app. It is the best tailor made remote pair programming app for both Mac OS and Windows.
Customer Engagement at Microsoft
00:01:36
Speaker
Hi, I'm Scott Hanselman. This is another episode of Hansel minutes today. I'm chatting with Mike Russo's. He's a principal software engineer in customer engagement at Microsoft. How's going? It's going all right.
00:01:46
Speaker
Thanks, Scott. Thanks for having me. Yeah, man. You know, most of our interactions are a little one-sided because you work with customers and then you write up these like epic write-ups and explain what you did. and Spending time with the customer is like so important. And I've always complained that like a lot of PMs and engineers at Microsoft don't spend any time with the customer at all.
00:02:10
Speaker
So then like where where are they pulling there their knowledge from? so how does customer engagement work? you're like You go there or you are assigned to a customer for a period of time because you're not like consultant, but you are also consulting. So help me understand how that works.
00:02:26
Speaker
Yeah, it's a pretty unique role. So like you said, I'm part of the customer engagement organization inside of Core AI Platform, and it's a customer facing part of the engineering group. So, you know, we're part of the product group, but our role is to interact with with customers directly.
00:02:45
Speaker
as they're getting started with new technologies that we're developing. So I focus on.NET. We also have engineers who focus on Java, but for for me, that primarily means helping customers get started with new versions of.NET, getting started deploying those applications into Azure PaaS environments,
00:03:00
Speaker
And just anything related to sort of whatever you know the product group is working on, making sure that we're on the ground with customers, understanding firsthand what that experience is like.
00:03:12
Speaker
So it is very much like being a consultant, except that you know, we don't charge anything. We just show up. our our The way we get paid is in learning. We show up, we help make sure that customers are successful getting started with these these products.
00:03:27
Speaker
And then we we bring back to the product group, hey, here's where it worked. Here's where it didn't. This is what we need to fix in VNext. This is what we need to clarify in documentation. Here are bugs we need to address, whatever.
00:03:38
Speaker
And it's our way of making sure that we get that that customer feedback that you're talking about that's so important. So there was a thing many years ago called MCS, Microsoft Consulting Service. You know, and you pay hundred bucks an hour and they come to you and they like are staff aug, staff augmentation.
00:03:55
Speaker
But you're not that. You're going there and you're learning and they're on the bleeding edge. They're doing daily builds of.NET or you're debugging something obscure in the jitter or the GC. Yes. That sounds like a pretty sweet gig.
00:04:07
Speaker
How would a customer get that though? How do they get a free Microsoft guy to show up? So the the way it happens is primarily we work with account teams. So, you know, someone in the account organization who who works with these customers day in and day out would come and talk to someone on our end and say, hey, we've got a customer who's got this interesting situation. They're trying to upgrade to.NET 10 and they're running into this, know, unusual bug, or they want to try this brand new tool that's and in private preview or public preview.
00:04:38
Speaker
And then We only have a handful of engineers on my team, so we have to be a little bit selective, but we'll try and identify the ones with the biggest learning opportunity. And we're a little different from MCS because we don't actually do the work for the customer. We may create like prototypes and show them how it would happen, but we're we're very much more just sort of advisory. But yeah, if if the account team comes to us and says, hey, we've got this interesting scenario, then...
00:05:02
Speaker
if if If it seems like an opportunity for us to to validate something about the product or learn something interesting, well we'll jump in. Recently, a lot of that's been related to our tooling around upgrade and migration and stuff, because that's kind of what's been new that we've been working
Large-scale Migration Challenges
00:05:17
Speaker
on. But, you know, whatever the product group's working on is what we'll we'll look for. And I like that you're saying that you're picking it because the problem is interesting.
00:05:26
Speaker
Yeah. That sounds hard. Let's go over there. Yeah. Yeah, yeah, for sure. The last big write up that you wrote was really cool because it was a big company that name that would recognize the name of that was migrating dozens of web apps.
00:05:41
Speaker
We're both on dotnet core, which is now 10 versions old. um Also dotnet framework, which is 1520 years old yeah and they were on premises like it's 2025 and they're running on bare metal.
00:05:54
Speaker
Yeah, they wanted to move it into the cloud. So that's like a triple migration in the sense of it's like they want to get to the latest dotnet. They want to get off of metal. They want to make sure that they're using the latest modernization. That's not something you can vibe. but You can't just tell GitHub Copilot.
00:06:10
Speaker
No, we've tried. but it's Yeah, that's, you know, it's a lot of work. And you're exactly right that you know they needed to to modernize in multiple different ways, right? Because when customers come to us and say, hey, we need to migrate, the first conversation is, well, what do you mean by that?
00:06:27
Speaker
Because sometimes it means, hey, we got this stuff on.NET 5, we need to go to.NET 9. Sometimes it's.NET Framework,.NET Framework 4.8 or.NET Framework 3.5 coming up to either.NET Framework 4.8.1 or up to.NET 9.
00:06:41
Speaker
Sometimes it's moving into Azure. It's like, hey, we we're on premise, we want to get into Azure App Service. Sometimes it's it's refactoring. it's We've got this giant monolith. We need to be more service oriented.
00:06:53
Speaker
And yeah, in this case, this particular customer, was it was kind of a little bit of all of that. So but we really had to kind of break it down and tackle it a little piece at a time. Why do they upgrade? like This might be a dumb question, but why not just leave it? It works fine. so you It's actually a really good question. and and Actually, there have been times when I've told customers, you know maybe you don't need to to upgrade everything all at once right away. but There are benefits to upgrading, right? Like, and again, depending on what we mean by upgrade, the the the upgrading to the latest version of.NET is, um that one's primarily going to be about performance, about supportability, about cross-plat support.
00:07:31
Speaker
You know, if a lot of times, you know, so so this customer we're just working with, they had stuff targeting.NET 5. That's an easy upgrade because.NET 5 is out of support. like yep You got to get up to.NET 8 or 9 if you want to be in support. Coming from framework,.NET 4.8 is in support, will be you know indefinitely. So there's no supportability reason you have to upgrade.
00:07:50
Speaker
But if you have ah a project that's undergoing active development, there's a lot of benefits to getting onto.NET 9. Obviously, huge performance wins. You get the opportunity of running cross-platform if that's useful. You get access to the latest you know language and runtime features. The ecosystem is continually evolving. A lot of NuGet packages now don't even support.NET Framework. So if you want to take advantage of all of that, you need to be on.NET 9. I've even heard customers say they want to upgrade just because it makes it easier to hire developers.
00:08:17
Speaker
you know If they go out and say, hey we want you to come work on this.NET Framework 3.5 web forms thing, it's like, yeah, crickets, no one applies. But if it's, hey, this is.NET 9, this is Blazor, it's like, cool, now now people want to do it.
00:08:28
Speaker
So you know there's a lot of benefits there.
Benefits of Upgrading and Migrating
00:08:31
Speaker
If you've got an app that, man, it's just doing its thing and you don't ever touch it, then and framework's all right. But for for stuff that you're working on day in and day out, like that there's a lot of benefits to yeah being modern.
00:08:42
Speaker
Yeah, getting it into the cloud is one kind of an upgrade, right? Just simply moving it off of some spinning Rust hard drive. Like I did that to my blog many years ago. It was running on.NET 4 and then 4.8, but it was running in a Windows VM on an unsupported version of Windows Server. And it's just a blog. Like, why am I...
00:09:01
Speaker
why am I managing a virtual machine yeah and and letting it reboot and run Windows Update when I could just throw it into something like App Service or an App Service environment? yeah absolutely. I mean, so so that migration and into Azure is sort of that other type of modernization we were talking about. And that one, it really is all about where the costs are where the risk is. Cause yeah, if you've got this VM that you were running your blog on, you have to keep that up to date. You have to patch windows. You have to worry about all of that maintenance of the, of the, of the server.
00:09:34
Speaker
Whereas you go into App Service, that's taken care of for you. All you have to do is you know focus on the thing you want to do, which is create the blog. And so, yeah, the the customer that you were talking about that we were working with most recently, that that that was their motivation. They had worked with our account team to understand the the cost benefits of being in Azure PaaS and not having to worry about maintaining this data center, not need to worry about all of that maintenance work that now becomes Azure's responsibility.
00:10:00
Speaker
And so they had this effort, like you said, to to migrate quite a large number of apps ah in order to take advantage of Azure Platform as a Service offerings. In this case, it was App Service Environment.
00:10:11
Speaker
Yeah. And on the perf side, you've done a lot of really interesting perf stuff where you've even brought in like the.NET team or like Mayoni who worked on the GC and like debug stuff. When you say there's a perf improvement from going to like.NET framework 4X to 9 or 10,.NET 9 or 10, it really can't be over. Like I'm not trying to like oversell it, but like it's,
00:10:34
Speaker
crazy fast even going like five six five to eight eight to ten we've all read the steven tobe like the steven tobe giant like super long blog but like ballpark it for me here if you just moved some nice clean razor pages from four over to to nine or ten how many improvements are you getting in performance and what kind of bump are you going to see That's hard to say. It really depends on the scenario. It it will typically be noticeable.
00:11:02
Speaker
I'll say that. I mean, the details are going to depend from scenario to scenario. and And I will also say that when we work with customers, we tell them it's not only upgrading to.NET 8 or 9 or 10, but it's also profiling, and understanding where your your bottlenecks are. Because I have had scenarios where customers have upgraded from.NET Framework 4,.NET five or whatever to dotnet nine. Then they come back and say, ah it's it's the same speed. We go and we look, it's like, well, it's because you know you've got this bottleneck in your code. Right. It's the same no em bad SQL query.
00:11:32
Speaker
Yeah, exactly. Yeah. You've got the SQL query that takes forever. Yeah. Network latency is a thing. unx and Yeah. but The way I explain it to customers is that when you upgrade to.NET Core, especially something modern like 9 or 10, the ceiling for what performance is possible goes way up.
00:11:48
Speaker
Now it's a question of, is your code set up to take advantage of that? But you know you've got all sorts of tools now in Visual Studio to easily profile that and help you identify where those where those issues are. And once you address them, then yes, you you do get those wins that...
00:12:02
Speaker
I don't know what the number would be, but it's a you will notice it and say, wow, this is better. You will notice it in all caps. like It starts up faster, it compiles faster, it deploys faster.
00:12:15
Speaker
um you know The way I try to explain it to someone is that it's it feels lighter weight. like Being able to go from this 30 gig Windows VM that ran my blog to spinning it up in ah in a Docker container on a Raspberry Pi just made me realize that like, wow, this is actually a nice little app that I've got here.
00:12:33
Speaker
I'm glad I put the work into moving it to the future. Yeah, absolutely. Yeah. yeahp Now we're not going to mention this company's name and I don't want to test shame them, but you know, they had 50 plus apps that they were migrating and only one of them had automated tests. One had tests.
00:12:49
Speaker
Yep, that was one of the big problems. That's not cool, man. They'd upgrade these apps and then go to try and validate that they were working. And the other thing that complicated it was oftentimes the the the people who own the applications don't have time to do these upgrades. So you end up with a central like operations or IT t or cloud system.
00:13:08
Speaker
you know, best practice team or someone owning these these sorts of, yeah you know, upgrades. And now this person who's never seen the app before is responsible for making sure that it works on.NET 8, that it works in Azure, and they don't even know what the app's supposed to do.
00:13:22
Speaker
So one of the challenges we often help people with is to understand, hey, you got to make sure you've got a way of Validating that this is good. you know if If you don't have tests up front, hey record some stuff with Playwright. Use GitHub Copilot to generate some tests, something so that once you're done with this work, you can go back and say, okay, yes, it's it's functioning the way it's supposed to because you know, the, the, the modernization itself is one chunk of time, but then often the, the validation of the app takes just as long. And so yeah can do things to, to help with that, it's, you know, obviously accelerates the whole process.
00:13:57
Speaker
I've always talked about fear driven development F F FDD, which is like, if there's a part of the code you're really afraid of, like for me, for, for like the Hanselman it's Hanselman.com the blog.
00:14:09
Speaker
on Azure Friday, it's the routing. Like the routing is the thing. Cause I have a, I have like probably 40 custom routes for little stuff that you don't think about because you just, you Google, you hit my blog you go, Hey, the RSS feed, ah the, the response types, the MIME types that get returned.
00:14:26
Speaker
um I need to make sure that all the yeah URLs work. I've got really sophisticated routing. I've even got an old IIS X, uh, ah What's it? um IIS rewrite dot XML. yeah And I'm using the middleware for that. Right. So I've got a 20 year old XML file to do regular expression level routing and I'm afraid of it.
00:14:45
Speaker
I'm afraid of it. So when I migrated before I did the migration, I wrote like 20 tests about the parts that I was the most afraid of. And those now are the things that make me feel better. So like start with like, you know, start with the hot path.
00:15:01
Speaker
But for me, I start with the fear. Like, yeah what am I going to break? Write a test around it. And you keep writing tests until you're not afraid anymore. Yeah. Yep. I love that. that's ah That's a great way to do it, to say, hey, what what's the thing that's going to keep me up at night?
00:15:14
Speaker
Get the tests in there. And you know that IIS rewriting you talked about, I don't know exactly how you did it, but I know that some parts of you know are IIS, you know, redirect and rewrite functionality is different in app service. That's one that customers run into every now and then. I had a customer who took their app.
00:15:33
Speaker
They thought, oh, well, app service is just like IIS. So I'm just going to pick my app up. I want to make this super lightweight and easy. So I'm not going to, you know, change the.NET target. I'm just picking up, dropping an app service. Boom, 500 when they went to the the website and we looked into it And there was a few things like that where, you know, the you know, a certain IIS module isn't enabled by default for the the rewriting or whatever it was. And they had to set a few options, set a few settings, and we managed to get things working without too much trouble. But yeah, that that's the sort of thing that every now and then you run into. So if you've got those tests that say, hey, I need to try hit this this path and make sure that it resolves correctly, that that's how you know that you're not run running into something like that. There's all these little assumptions that we made and then they'll bump, you'll you'll hit them. Like one of the ones I hit was forward slashes versus back slashes. Oh, yeah.
00:16:23
Speaker
Right? Like, oh, this harmless little text file. It'll be fine. Hard coded. So you go to Raspberry Pi. Yep. And then system.directory.io.pathseparator and the next thing you know. Or I had time zones where we were loading time zones out of the registry and registries don't exist on Linux and then you're off and running.
00:16:42
Speaker
Absolutely. Yeah, don't know. I mean, the the time zone stuff's all managed by the operating system. And so it's going to it's going to be a little different.
Code Rabbit and AI in Modernization
00:16:48
Speaker
Hey, friends, this is Scott. I want to thank our new sponsor, Code Rabbit. You know, we're shipping more code than ever. And that means there's more code reviews than ever.
00:16:57
Speaker
So that must mean that all these code reviews are going to slow me down. Is that right, Aravind? Not exactly, Scott. but v That's where we also come in. CodeRabbit exactly cuts your code review time into half and your bugs into half.
00:17:12
Speaker
ah We give you the feedback right in your PR context and helping your developers move faster ah while they are also generating code more faster. ah We offer one-click fixes and spot all the bugs and refactor issues, deliver deliver it on your own Git workflow, and help you move really faster in the AI era.
00:17:34
Speaker
CodeRabbit offers free AI code reviews directly in your code editor. Fix those bugs, find those defects, especially the ones that were introduced by Vibe Coding, and it all does it without breaking your flow state.
00:17:46
Speaker
So you will be able to ship more code than ever. I encourage you to check it out at coderabbit.ai and sign up for a free trial now. So these are all examples of stuff that you know because you've been doing this for so long. Like this is stuff you know because you're an expert.
00:18:01
Speaker
Here's the question, though. where does Honestly, where does AI fit into this? like I don't think AI is going to replace 30 years of knowledge, but it does do a lot of tedious stuff. and and So help me understand where expertise fits and where GitHub Copilot modernization fits.
00:18:20
Speaker
Yeah, for sure. Because we do have GitHub Copilot-based tools now that help with these experiences. you know Just about a week ago, GA'd the GitHub Copilot app modernization tool, which is part of Visual Studio. And for your.NET apps, it will help you upgrade between versions of.NET, help you get them ready to run in Azure. But it is sort of an interaction between you know GitHub Copilot and you know documentation, guidance, static analysis tools can help that can help spot these sorts of things.
00:18:52
Speaker
We have an older tool called ah Azure Migrate Application and Code Assessment, which is just a static analysis tool, but it'll go through your whole solution. It'll find all of the.NET APIs you're calling that might behave differently in in an Azure PaaS environment and put them in a list, in a report, so you can go look at it and be like, hmm, is this going to matter? Do I need to change anything?
00:19:11
Speaker
And it helps you not have those blind spots. I think the place where GitHub Copilot really helps is sort of after that initial and analysis happens. Like after you've already sort of done the scan to say, okay, where might there be problems?
00:19:26
Speaker
Copilot's really good at helping you understand things. It can take a big report and say, here are the things that really matter. Or if you're not sure what to do about something, you know, GitHub Copilot can help you figure out what the right next steps are. So whether that's just going into chat in VS Code or Visual Studio and asking Copilot, hey, this report says that I'm, you know, using the registry and that's not going to work when I'm when i'm running in Azure Container Apps, what should I do?
00:19:53
Speaker
You know, GitHub Copilot's really great at coming up with alternatives, helping you brainstorm. And then also this this tooling that we have now, it's brand new, the, you know, some some portions that are still in preview, but being able to have a tool that can use a knowledge base that's provided by a built-in MCP server and use that knowledge base to understand how some of these transformations have to happen, well, then it can take that code, do some of the transformation for you and get you ready to You know, do whatever it is you need to do in the new world.
00:20:23
Speaker
That's a great point. I think that a lot of people think that LLM based migration is copy pasting 10,000 lines into a thing and like figure it out. Mm hmm. There's a programmatic aspect to it. There's tools, there's MCP servers.
00:20:38
Speaker
there was There was a really solid migration experience long before AI was a thing. Most of my migrations were done with the actual.NET Migrate command line tool.
00:20:50
Speaker
yeah That still exists, right? So like putting the LLM around the edge cases is helpful, but it's gonna be calling into actual tools, Roslyn analyzers that know how to do stuff, right? yeah Yeah.
00:21:02
Speaker
Was that the tool that was sort of on the command line? You'd you'd give it a.NET framework project? yeah would there was ah Yeah, exactly. There was a command line one that was kind of a do it, you know, it update your CS proj and then it moved into Visual Studio and they gave it a visual thing.
00:21:17
Speaker
And then now the one in Visual Studio has a prompt. And I think that there's tools and tooling wrapped around it wrapped around that. Yeah. And that's the direction we're going is to have Copilot sort of be part of the process. Not that it does everything, but that it it orchestrates, it fills in gaps.
00:21:32
Speaker
but I asked which tool it was because I think that was a tool that our team created actually. yeah. Output from a customer engagement. Thank know, for that. Yeah. Quite a few years ago, we were working with the customer and they actually created a framework that that made it easy to generate you know a certain style of web app.
00:21:48
Speaker
And customers would like use their things that they could easily create their their CMS app or whatever it was. And they were in a situation where they wanted to upgrade their framework to.NET Core.
00:21:59
Speaker
They also hosted apps for customers sometimes. They want to start hosting these apps on Linux.
Modernization Tools and Techniques
00:22:03
Speaker
So they said, hey, we need our customers to upgrade from ASP.NET to ASP.NET Core, but that's a difficult upgrade. And we have hundreds of customers. How can we...
00:22:12
Speaker
get our customers upgrade more quickly. And so our team actually started prototyping with them. Hey, let's see what we can do programmatically here. And we came up with the first version of the.NET upgrade assistant, which at this point been through like multiple rebirths, but that was kind of its beginning.
00:22:27
Speaker
And they were able to get their customers more quickly upgraded, which meant they could then upgrade their own product. But yeah, so just a fun little connection there. But yeah, as you said, it's still available as a command line tool today, but now we've got the GitHub Copilot app modernization tool, which eventually will sort of fill that same gap, you know, through that combination of, hey, we've got rules about how to transform a CS project SDK style. We've got a knowledge base that tells us how to this, but then we've also got the power of the LLM fitting it all together.
00:22:58
Speaker
ah The LLM is able to, you know, intelligently react when something unexpected happens, when we get a build error, we get, ah you know, something doesn't restore from NuGet, the LLM is able to jump in.
00:23:09
Speaker
You just said something I think is really important. You said unexpectedly. Yeah. And this is the thing I think people don't realize is that I think I'm starting to realize it. And it is that LLMs deal with ambiguity.
00:23:22
Speaker
Yes. But if it's deterministic, it needs to stay deterministic. So there are things like what you need to do to upgrade a CSproj, what you need to do to you know make your startup.cs work correctly. These aren't these aren't opinions.
00:23:35
Speaker
They are best practices. Right. Yeah. Right. But then everybody's got some edge case. Everybody's got them something ambiguous and that's where the LLM adds, adds value. So I think it's the mix of a proper migration tool. That's, that's like hardened for lack of a better word based on experience.
00:23:53
Speaker
And then they're like, oh, this is weird. Yes. Send that to that. And there's always something weird, you know, for the longest time, you know, before we had, you know, co-pilot, We were trying to do the best we could with these static tools and they were okay. They got you 80% of the way there or whatever, but there's always something unusual. It doesn't, like guaranteed, you you sit down with a customer, you try to modernize their app, you're going to hit something weird.
00:24:18
Speaker
You know maybe I worked with a customer who had created this whole plugin model using system.addin, which doesn't exist in.NET Core. Well, you don't see that very often, but it's out there. you know, I've got another customer who who had this fancy remoting setup. There's, you know, there's always, there's someone I work with at Microsoft, one of my colleagues, she she had a great expression for this. She said, helping customers and partners modernize apps is like a herd of unicorns.
00:24:43
Speaker
There's a ton of them, but they're each individual. And like, man, that's the best way to describe it because that that really is how it is. But yeah, that's where Copilot can help. It's, hey, we've got this tool that's going to do the 75% that's all the same. We know how to do this.
00:24:56
Speaker
Now for this last quarter, let's have the LLM use its intelligence to maybe fix some things, maybe just point you in the right direction, maybe just be a sounding board so that you can go and have a good brainstorming conversation as you figure out the right path forward.
00:25:09
Speaker
Yeah, but the LLMs are not going to solve bad infrastructure. They're not going to solve a lousy application experience where you can't even build the thing reliably. Yeah, yeah.
00:25:22
Speaker
You know, I imagine that if they don't have a build server, then that's going to be a challenge. or they don't have any tests, that's going to be a challenge. I don't think you'd want to YOLO or Vibe migrate something.
00:25:34
Speaker
Well, no, but what you would do is you would YOLO or Vibe a part of it. Let's say you've got an app that, yeah you know like this customer you're talking about at beginning of the of the show where they've got no tests, they've got 50 apps, 100 apps, whatever.
00:25:49
Speaker
yeah Maybe the place you start is you say, hey, Copilot, write some documentation for me about how these projects work because they're not well documented. Okay, cool. We spend a day doing that.
00:26:00
Speaker
Day two, Copilot, use these documents as input. Now help me create a good set of unit tests or some integration tests that are going to validate that these work. Cool. Okay, now that part's done. And you sort of incrementally walk through this process. Not that you just tell Copilot, hey, here's 100,000 lines of code. It's got to run in Azure this afternoon. But you you break it down and Copilot helps with each piece along the way. And that's where you really get the benefits of the, of the LLMs, I think.
00:26:25
Speaker
Yeah. I think that's a great point. People try to do what's called a one shot yeah and, and then they're, then they find it wanting and they're like, well, this is just an eager, energetic intern that is just going to mess everything up.
00:26:35
Speaker
For sure. I'd say, make me a plan, you know, look at the plan, validate the plan with knowledge, execute on the plan and go from there. um I think also, though, that if you've if you're at a company like this big one that we talk about that has 50 different projects, they might have unique things that are shared amongst the 50 projects. Absolutely. Can I then go into Copilot and say, hey, I'm here at Company X and they all do this weird thing. Here's some custom instructions that I want you to think about during the migration.
00:27:03
Speaker
Yeah, absolutely. That's... GitHub Copilot chat does have the ability to accept instructions files that describe how it needs to solve a particular problem. That's where you could put something like that.
00:27:13
Speaker
Or even with our tooling, the the the tooling has the ability to accept additional instructions files that guide or even learn from what you do. One of the cool things that the app modernization tool does is sometimes it'll get stuck. It'll try to fix a build error three or four times, and then it it pauses and asks the developer to help.
00:27:32
Speaker
After the developer addresses the issue, the app modernization tool looks at the diff to see what how the developer solved it. And then we store that locally in your.vs folder so that later on in that same solution, if we hit a similar problem, Copilot can say, oh, wait, this is like that one that I had to ask for help for two hours ago. Let me see how they fixed it. And so, yeah, I think that in general, you know, as you're working through these things, having the ability to tell Copilot,
00:28:00
Speaker
you know, here in our organization, we have this pattern. This is what you need to do about it is is super valuable. even Even things that aren't that specific to particular customers. One of the things I've learned using GitHub Copilot myself is that it always wants to use the latest and greatest tools.
00:28:14
Speaker
So if I'm working with an old.NET framework app, trying to get it to run an app service, It's going to try do things like, oh, I'm calling.NET Build to build it. Well,.NET Build isn't going to work with an ASP.NET MVC app. And so I have instructions files that I've collected that I just drop in and say, okay, this is my instructions file for when I'm working with.NET Framework to remind Copilot, this is a targeting an older version of.NET. You need to use MS Build.
00:28:37
Speaker
ah When you install NuGet packages, this is what that looks like. Don't just assume you can add a package reference because we're still using packages config and Yeah, so having the ability to guide the LLM is is is pretty key.
00:28:50
Speaker
You developed a thing, i think, called x to Y dependency transformation. yeah Yeah, that was something our team came up with. Yeah, so that's one of the engineers of my team, Manfred, came up with that originally, and we've all sort of adopted it.
00:29:03
Speaker
What we discovered is that there are certain... patterns of of prompts that work well for for Copilot. Copilot responds well to having a lot of structure in its prompts.
00:29:14
Speaker
It responds very well to having a detailed task list of of steps it needs to walk through, like having like a to-do.md or a progress.md. So we found these best practices that made Copilot effective at code transformation.
00:29:27
Speaker
So what the X to Y transformation is, is it's really just a codification of that where we have a template that has all of these sorts of best practices embedded in it.
AI's Role in Developer Productivity
00:29:38
Speaker
So then when you want to transform your code, let's say you've got a problem, you need to update your code to log with library why instead of library X. Instead of just saying to Copilot, please update my code to use library Y instead of library X, what you do is you tell Copilot, use this template that has a lot of best practices in it to create a prompt that will move my code from from X to why Make sure you you know follow this template that has all of these best practices in it.
00:30:09
Speaker
And so Copilot now makes you the prompt. Copilot doesn't make the change. Copilot makes the prompt. Then in a new session, you have Copilot execute that prompt and it's got all these best practices like, hey, it's got to use this this task list. It has clear success criteria defined.
00:30:24
Speaker
All of these things that we've learned over the past you know year or two that make Copilot effective get put into that prompt so that it just works a lot more effectively than you just running in and like you said, just one-shotting it saying, hey, get rid of X, put in Y. like Yeah, it might work.
00:30:40
Speaker
But if if you use this sort of two-phase approach, it it works better in our experience. Now we've heard people say 10 X more productive and other people have been like, no, I'm not more productive at all.
00:30:52
Speaker
It seems like it it's very wildly ranging. Like yes I feel when I'm doing it, I'm probably 25 to 50% more productive.
00:31:03
Speaker
Sure. But then like right now I'm not coding. So like I'm not more productive. Like a lot of people don't code full on hands on keyboard 40 hours a week. yeahp You know, I maybe get,
00:31:13
Speaker
I don't know, 12 hours a week, I'm actually coding. yeah So an extra 50%, that's great. That's giving me like a whole half a day. what What are you hearing like anecdotally from folks about whether or not they're faster in migrating with Copilot?
00:31:27
Speaker
it It really depends on the... on the customer because it it varies. But yeah, generally customers are telling me that they're 25% faster or whatever it is. It does depend on the kind of work they're doing.
00:31:40
Speaker
One of the things I saw recently with a customer was that it was the senior developers who were telling me these 25, 50% numbers And the junior developers were like, no, it didn't make me faster. And when dig in there's I think there's a few factors that go into that. First of all, one junior developer told me, I don't use Copilot because I don't know what to ask it. I said, well, that's interesting. like You sort of have to know enough about your problem space to know how something like GitHub Copilot chat is going to help you.
00:32:07
Speaker
But also it depends on the kind of work you're doing. um You know, if you're doing, you know, I think Copilot always can be involved, but how much it's help depends on on what it is that you're working on. If you're you're debugging something, yeah, you'll bump some ideas off of it. It helps a little bit, but you know maybe maybe the the savings is more limited. If you're youre generating a lot of code that you know you can describe how it's supposed to work, you can give a nice you know spec for it, hey, Copilot can go off and it can do a whole day's worth of work in 20 minutes if if it's the right kind of work.
00:32:42
Speaker
Yeah. I think that's a great point. And the thing that you said that i resonates the most, and I think Mark Grosinovich and I have a paper coming out on this, is that If you're junior and you don't even know what to ask, yeah that's a really tough spot to be in.
00:32:56
Speaker
So while we're having all these conversations about what it means for AI, for the software engineering like discipline, we need to be thinking about how to bring early in career people in Because the qualifications right now for migrating 20-year-old code is be an old programmer. Yeah. Yeah.
00:33:16
Speaker
And that's not very fair to everybody. You know, it's not, you know, like, how do you know that? Well, back in the early days, know, like that's not, so how do we bring, how do we use AI to augment the knowledge of the early in career person? Cause I'd love to have a 25 year old or someone who's got five years experience go on a customer engagement with you and have success, yeah but also have the AI teach them and accelerate their learning.
00:33:43
Speaker
And that, that I think, is a tough spot to be in. Yeah, no no doubt. Yeah, I mean, that's that's a challenge. Let me know when that paper's ready. I'd love to read it because it's something I don't know that I have an answer to, but I'm sure as as AI improves, it'll be better able to help help people understand its capabilities, what what they need to know. But yeah, it's a hard problem that I think We're going to have to you know iterate on until we figure out a good path forward. Well, I think it all comes down to exposure.
00:34:12
Speaker
like you you You can't be successful unless you get exposed to these things. So you you as a customer engagement person are getting to spend time with customers. So you know more than you know you and your team know more than anybody yeah what it's like out there in the in the real world.
00:34:29
Speaker
I still remember what it was like to not work for Microsoft. So I have so much empathy when I go into a customer and I'm like, oh, man. i I know what this code looks like and I know how it happened. And I know, and know all the, I know all the office politics that got us. right Yeah. Yeah. You've been there. you You know how you end up with that sort of a solution. and Yeah. It's going to be very satisfying to get it, to get it in production. and And a lot of those apps that you did in this engagement are in production now.
00:34:57
Speaker
Yeah, they are. Yeah. And that's one of the things we love to see is just sort of the, you know crossing the finish line, getting something running in Azure, running on.NET 10, or, you know, if it's a perf question, you know seeing that, you know, 2x perf gain or whatever it is to say like, wow, yeah, that's, you know, hey, there's real value there. And it's, yeah, that's, yeah, that's always how software development is, though. When when you run your app and you actually see it do the thing that it's supposed to do, it's, you know, that that's the time when you when you love this job.
00:35:24
Speaker
Fantastic. Well, thanks so much, Mike Russo, for hanging out with me today. Yeah, my pleasure. Thank you, Scott. This has been another episode of Hansel Minutes, and we'll see you again next week.