Are Desktop Apps... Dead?! - Principal Engineering Manager AMA

There we go. It's working. We have a wired internet connection now. We can't be stopped. I mean, I guess we could, but it's not going to happen. It's going to it's going to hold strong. We like that. Even Instagram's working. Instagram's actually doing a horizontal layout now, which is crazy. We'll get that rocking and rolling. Um yeah, this is cool. Um so welcome to the live stream. This is an AMA format. I always come with the topic prepared and then uh we can kind of figure out what we want to do with that. So because it's AMA, I'll be talking about the topic and then if you have questions either related to it or you want to talk about other things, just jump into the chat. Happy to try and answer whatever's top of mind for you. So, it's related to software engineering, career development, you want to talk AI, we can talk AI. Um, but yeah, it's going to be nice to actually have a stable connection again because the last couple of times, holy cow, it's been pretty miserable. Um, so I apologize for sort of how brutal that's been. And I also want to apologize that I was getting set up for this stream and when I switch over to my my desktop mode here and I spoke too soon, Instagram went from the horizontal setting to uh portrait back to horizontal. It's doing crazy things, but you're not on Instagram, don't worry. Um, but when I switch over to this desktop mode that I that I use, um, it's just like it's not right. like my face isn't in the corner and I don't know why. So, we'll uh we'll figure that out, I guess. So, anyway, the topic for today is going to be about desktop development, which is a little bit weird, I must admit. Um because I think that probably for a lot of people, they don't think about building desktop software anymore. And that's kind of where this topic came from. This was someone who was essentially asking this on the experienced dev subreddit. So if you're not familiar on these live streams, I take a topic that comes from my newsletter that I write for the weekend. And the topic for the newsletter comes from code commute, which is one of the YouTube channels that I have. And code commute is either user submitted questions. So if you have questions about software engineering, career development, like for this live stream, you can go over to code commute. You can ask stuff. I'll make videos for you. Um, I'll share links to code.com. You can submit stuff anonymously. So, either that or or or or we uh we go to the experience dev subreddit. Garrison, hello. Thank you for for saying that I rock. I appreciate that. Thanks for being here. Um, so yeah, this topic came from the experienced dev subreddit and essentially someone was saying what's up with desktop development, right? So I've been talking about this for a little while on platforms like Twitter and stuff where um, you know, like to get some engagement, get some conversation going, get people talking about it. It's always interesting what people are building, right? So you could ask it. It's it's fun to do this to be in a situation where there's so many developers connected on a particular platform and because I ask this across platforms I see sometimes similar patterns sometimes very different patterns. But if you were to ask a group of developers on social media, hey like do you think desktop development's dead or like do do you see like a place for it? You might have a bunch of people that are like nope like what a waste of time. Why would I ever do that? And you might have a group of other people that are adamant that absolutely you must develop some things for desktop. And I think this is a I think it's very interesting because depending on who you talk to, you'll get different answers. And the best part about this is like it's not it's not a right or wrong thing, right? I think it's only it only becomes a wrong thing to me when you are an absolutist and you talk about things like you know there is no you know desktop development has no place ever. I'm like well it's only going to take one person to give you an example where you might you know benefit from desktop development. Now your argument is kind of wrong like by default right if you're absolute position on it. So, I I like questions like this because when you have people discussing this kind of thing, as long as you're keeping an open mind, then you you will see a different perspective come up, right? You might see people that are like, "Nope." Just making up an example here, like, "No, uh, I don't see a place for desktop development because like anytime I think about something that I would make for a desktop, I would I would just go to a multiplatform solution, right? Or anything that I could make on a desktop, I would just make for, you know, web browser. And then you'd have some people saying,"Well, I would never do that because I need native performance for for desktop for these types of apps." And it's it's interesting because it's like, well, if these if these two things these two opposing views exist, like is one person right and one person's wrong? And I think the answer is it's not the case, right? It's it's not right or wrong. It's like they have a different perspective. So, what can we learn from both perspectives, right? And so because I've talked about this thing before on social media when this thing came up on the experienced dev subreddit, I was like, I think this will be a fun one to talk through. And then uh based on how this goes for the week, I use AI to go over my channel and see what was the most engaged topic from code for the week. And that is the thing that I end up writing about. So let's we get some thoughts together and then I can put a newsletter together and then we talk about it. So yeah, are desktop applications really obsolete? Um I think that one of the arguments kind of in my my hypothetical that I was giving you there is that people will say things like um you know if if I'm going to develop for desktop, I might as well go crossplatform, right? like um so instead of me going and saying I'm going to go pick some desktop tech stack and build they would just jump right into let me go crossplatform and the idea there being like I can't say this for everyone obviously but I think a lot of the time it's well if I'm going to build once I might as well build for something that's going to allow me to be on multiple platforms right why why restrict myself to one and so I think what's important to realize um if you're kind of taking this stance is that just because you are you know picking something that is a cross-platform tech stack uh does not necessarily mean that your costs go away or doesn't necessarily mean that your costs are uh reduced right so in fact it might be the opposite and I'm not saying you know it's a guarantee or not I'm just saying something to think about right so for example um you might say, well, instead of me, you know, building for just Windows, I might as well go use something that's going to let me be uh on Windows, Mac, and Linux, right? So, great. You you very well might be able to put something together that works perfectly fine across those three surface areas building in something common. And that's great. And depending on what you're building, you might also run into just simply more problems because now the way that you're designing things, you may quite literally run into situations where there is technology that does not run native on those particular platforms. And now you must be in a situation where you're saying cool I built build this common thing but I have to also have logic that knows how to um either I'm packaging it completely different for these different platforms to handle this thing or at runtime I'm going to dynamically go down this particular path versus this one based on the platform. So now you're starting to build in additional complexity into the thing that you're building. Um and then Gerson saying in the chat I think blazer maui windforms and .NET framework are dead. Interesting. Wow. Okay. And I'm a front-end nerd. Check out my blog, Brave Developer. But that is the true the pure truth. You think you think Net Okay. Well, .NET Framework, we got to we got to be careful about the terminology here. Uh .NET framework INET framework should hopefully be dead because we have .NET Core. But do you also mean that .NET in general is dead? Because I'd be curious about that. Um yeah, I think when we talk about like it's surprising like Windforms as a tech stack, it's a funny one. Windforms I think uh like in in theory like should have been superseded by um by WPF, right? But like technically there are still people that build Windforms. It's crazy. Um, I think it's crazy and I say this as someone who has spent even even up to this point, I think more than half of my time as a software developer, like as in terms of programming in general, over half of that time has been building desktop applications, which I think is fun. Um, it's also why I like to talk about this one because sometimes people will say like, you know, if you have the stance where like there is no place at all for desktop development, I'm like, well, let's talk. Um, but Windforms, I've spent a lot of time on WPF as well. Um, I even as someone who spent a lot of time in Windforms, I would be pretty hardressed, I think, at this point to to think that like Windforms would be a technology choice I would pick. Be pretty hardressed. I think maybe one ar like I I'm sure there's lots of arguments that people could come up with for this. I think one argument is like if you're not using AI to build things, you might say, uh, let's take Nick from an alternate universe where like all that I did was continue to build in Windforms. I said, I'm doubling down. I'm tripling down on the wind forms. I'm going to keep building Windforms the rest of my life. Um, maybe you have developers that are like, hey, look, based on what we need, like, you know, our customers only run Windows or whatever, whatever situation that is. And so, like, I really know Windforms. It's just more effective for me to do that. Like that's that's an argument. Is it a great one? I don't know. I don't I don't really think so. But that that could be one. Um I would say the same thing maybe about some of these other things, but like Blazer and Maui I think are are so much newer that I don't know, not uh I don't think you could really make the same argument. I think Windforms and WPF you could probably make an argument like that. um net framework being dead again I I think I would say like on on net framework specifically sure um but net framework died with uh you know before net core came out so I I agree with that but it's just based on the being pedantic part I suppose but but yeah Garrison thanks for being here um I do appreciate the comments. I'm going to take a quick moment to double check that my Instagram feed here, it's going crazy because you can't see my screen. Uh but the feed is going from portrait to to landscape like back and forth. It's uh kind of ridiculous. It's like jarring for me and I only have a little preview of it and I'm like, "Oh my god, I can't uh I can't look at this." But I just switched it. We'll see if it actually keeps up. So, um yeah, I think that you know, one of the things to consider is that in terms of costs, um you know, you may be incurring a cost for picking a tech stack that's crossplatform. Um, and you could make the argument, hey, I'm really good and comfortable in that crossplatform technology. Again, it's not a it's not going to be one argument fits all situations. I also think that when it comes to this, like one of the things I was mentioning is thinking about what your product has to do. And that could also mean like um when I say what your product has to do, like thinking about who your users are, I guess. And this is one of those things it's like a I don't know, I'd say like a pretty common trap for for software engineers, right? We I say this as in like I definitely put myself into this group. So when I go to generalize here, like I'm included in this, but we love to basically like overengineer design for all possibilities, that kind of thing. Um and I think that part of that includes things like, hey, look, if I'm going to build something, let me build it across all the platforms. Because sure, all of our users are only on Windows right now, but like also they could be on Linux, they could be on Mac. Um, and don't get me wrong, I realize this probably sounds like a bad argument, but just hear me out. um if your users are literally only on one platform and you know this from demographics and who you're going to be selling to and depending on you know the uh what those demographics are the longevity of the company. So maybe it's company that's brand new, right? You're a startup. You you haven't even launched a product yet. You need to, you know, ship something to stay alive. If you were to figure out that it was going to take you twice as long to ship something crossplatform and get Mac and Linux and stuff handled as well as Windows, then I would say like maybe that's not the right move. Even if that's a maybe a good investment for the future, perhaps uh it's more futurep proof perhaps. I don't know if it's necessarily the move because you might uh genuinely not be around. So, kind of a something to think about. Um Cameron, thanks for being here. Appreciate being on the stream. So, one of the things I would kind of throw out there is that when you're trying to pick like, you know, should we be going to a web platform? Should we be trying to pick something that's going to be crossplatform to go build? I would say genuinely look at where your demographic is, where you're trying to sell to. Does it makes does it make sense from like uh probably from a business and engineering perspective to go build crossplatform, right? Like maybe for example, you are in a situation uh I know we're talking about desktop development, but let's jump over to this idea of like you're building a mobile app, right? Like maybe it makes sense in your situation that you only target specifically iOS or specifically Android. I suspect probably for many app developers like for mobile. I suspect for many the answer is like I probably do want crossplatform, right? Like you maybe don't care for the most part what phone it's on. You're just like I anyone who's using a phone should be able to use this, right? So that might be a really good argument for saying if I'm doing mobile I will just automatically target crossplatform but you have to think about what your product needs to do and like where your audience is. I it probably sounds obvious as I say this, but the reason I'm saying these things is because as we piece all of this together, hopefully you'll see that um when we come back to it, it's not it's not just hey, there's no place for desktop development or there's only you know this other option. It's like you know uh in the in the words of Derek Co. Martin from code opinion like it depends, right? Context is king. What you're doing, the situation and the context really matters. the constraints really matter and just kind of making universal laws for things I think just is a is not a great way to approach things. Uh Gerson says .NET uh 5 plus and TypeScript is cool. Those are handling the whole ecosystem in Microsoft in my opinion. It would be great if Microsoft could support libraries like mediator, mass transit, identity server, swagger. Yeah, it's interesting, right? Like um and obviously as someone who works for Microsoft, I should also mention like I also don't work in parts of Microsoft that um you know I have like sort of like an influence on this kind of thing, but uh I work in the Microsoft 365 side of the house. So on a platform team, so a lot less around like you know the .NET stack and and library support and stuff like that. But um yeah, it's kind of interesting, right? Like I mean Microsoft is probably in a position where they could go scoop up some of the things like this um or just offer better native support. But I I'm also just not like I'm not close to those conversations at all. So I genuinely don't know internally at Microsoft what it looks like for that kind of thing, right? Like obviously um well maybe it's not obvious but like the for for Newtonoft, right? Like James Newton King who made Newtonoft works at Microsoft, right? So like he is able to contribute to plenty of like library type things. Um I I thought that and maybe I'm confused about this. I thought that Paulie support was kind of like getting baked into.net, but I also know that based on what I've seen recently, like Paulie also has like a paid offering. So like maybe I've confused that, but uh there's a lot of stuff where likenet foundation will take in like things that are are huge community projects and stuff. So like I don't know like yeah maybe it would be interesting if mediator mass transit those types of things made their way over. Um, and I thought my brain is turning into mush right now, but for Swagger, I thought there was something else that we were getting that that already kind of replaced Swagger and like my brain's just not on. Um, I say that too because the things I'm exposed to still, um, I see like a bunch of swagger, so like that's not gone for me. But I thought there was something else replacing it. I'd have to search it right now cuz thanks Monday Brain. But yeah, um in terms of trying to understand what your product needs to do and making a decision like I think when I talked about this on code commute, one of the things that came up for me was like like let's think about games, right? Like I think games are a really interesting one uh to go through on this because depending on who you are like I personally when I play games I play them on the computer, right? I play PC games. Do I have a console? Have I owned a console? Yes, of course. Are there games that are on console that are also on PC? Yes, of course. Um, but I would say like if you're thinking about the complexity of something like a video game, if you yourself wanted to make a video game, I would probably encourage you to pick one platform to start with because you would quickly find out that trying to support it properly across a bunch of different hardware, different operating systems, different combinations of hardware, driver, and operating systems across all of that. It's going to be chaos. it's going to be very difficult. Um, and it's going to just create a lot more engineering challenge. And it's not to say that you can't go solve that or you shouldn't go try to solve it. But, and just in terms of reducing complexity, I would say if you're trying to go release something like a game, unless you're really good at doing this and have experience, I would say like reduce the complexity. Pick a platform. Where do you want your target users to play? Right? So like that that would probably be a good thing. There's a lot of game companies that have like started they pick a platform and then they go cool now that we have this working let's do a port to another platform um because they were able to say pick uh you know an engine or something that could work on a different platform and so they get it working for a while and they go great now that it's working we have some income from this game like let's go do a we'll do the the console port of it right so I think there's some options like that to consider um the alternative for Microsoft is open API I but it's not very friendly like the old and trustworthy swagger. Yeah, I don't know. I I like swagger. Um it seemed pretty obvious. But open API. That's right. I don't think that I've switched some of my own projects and stuff away from Swagger yet. That's probably why I'm just like I can't remember what it is. But um and there's there's even stuff that you know from from where I sit at work there's still a bunch of stuff that I see that's on Swagger. So like to me Swagger has not has not died. Um but I I think the yeah the path going forward is is not swagger anymore. So yeah. Um one thing to consider with like what your app needs to do is like if you're going to pick I think one of the one of the alternatives that we see a lot with desktop development versus not is like okay I'm gonna I want to make something that runs on on desktop and in terms of the operating system I'm picking. Is it going to be Windows? This is going to be like maybe you want to do a Mac only thing or Linux. I think if you're like, well, I want it to be crossplatform. Yes, there are tech stacks for it, but one of the other things that comes up is like, well, why don't I just do a a web app, right? Like, doesn't that just solve all of the problems? And I think for a lot of people, depending on what you're trying to build, it very well might, right? If one of the biggest sort of architectural or technology challenges that you need to think about for your app or whatever program you're trying to build is how do I make this work across all of these different surface areas. If if that's the biggest problem and it's not that you have to do much that's complex then yeah like jumping right to web might be great might be but there's also trade-offs for that right. Um, I think in my I'm just going to I can switch over to it for a sec. My face is going to disappear, but like what I wrote down here is like just, you know, a list of some things to consider, right? This isn't the list. This isn't the only things, but some things like what platforms your customers need. Think about this one. I want to talk about this a little bit more. Um, for network connection, right? Local files, devices. Do you actually need to like integrate with things that are part of the device? Is that part of what you need to build? Um fast enough, right? And fast can mean in terms of throughput, latency, that kind of stuff, right? Um and then maintaining it. So like it's one thing if you're able to put something together very quick, right? But just because you can get a demo put together quickly in in whatever stack that happens to be like if someone is going to need to maintain that and part of the maintenance is legitimately going to be like hey we need to maintain this across platforms like I don't know like maybe the demo was easy to put together and whatever but going forward is there a maintenance cost that's associated with that. So the the one thing I wanted to talk about that I had highlighted there that I didn't mention a lot before was like network connectivity and this one uh this is something I was thinking about in the original talk through on this on code commute and the idea of um the idea of video games came up for me because I thought this one was interesting but um if we think about this there's lots of games and I'm sure there's at least someone at least one other person who's is on this stream either now or who will watch the recording and this will resonate for you. But if you are a person who plays games on PC or console, right? One of the things we've seen a huge shift over I don't even know like maybe last 15 10 years something like that is that there's a lot of games that existed purely as a single player game right so you would say you know yes the game has a multiplayer option let's say but like I just want to play just want to play by myself and like if I'm just going to play alone like why do I need to be on the internet right So, like something that stuck out to me when I was thinking about this is like how many how many games have gone purely to like you're always online. You're always online, right? So, there's some games I can think of like um I'm a I'm a big fan of like action role playing games. So, things like Diablo, things like uh Path of Exile, Last Epoch, that kind of stuff. um this this move towards like our games are always online and I think a big part of it is like to you know to help prevent cheating and stuff like that but that actually means that for many people they're like if I'm in a spot that does if for whatever reason I don't have internet which I think is you know more and more rare but if you don't have internet you can't play a single player game like it feels kind of crazy that if you don't have internet you can't play a game that you're just going to play by self, right? So, some things to think about, right? If you if you're building stuff like do you need network connectivity? What does that look like? How does that change the tech stack and how you're approaching building? Another thing that I'd mentioned too is like um this one I'll share from my previous experience because I think it's just an example that I don't think comes up a lot. So, where I used to work before Microsoft was a company called Magnet Forensics and I think there's been a a really big shift in this kind of stuff over the last I don't know even it's been a Microsoft six years now. So maybe the last eight yeah six let's say six to 10 years. Okay. 5 to 10 years. Six to 10 years there's been this big shift in digital forensics um and probably other industries like this. But one of the things that was really common in digital forensics was having airgapped machines. What does that mean? Air gap machines. So quite literally having machines that were not on the internet at all and in some cases not on a network at all. And so this is a really interesting requirement, right? It's an interesting constraint. So if you are thinking about your customers what like what you need to build to facilitate what your customers are going to be using this is something that mattered for us right like we need to build things that it's not that um you know they could never connect to the internet some of our customers absolutely could but we also had customers where like they can't it's just they're the machine they're running on literally cannot do that and so if you were to build in things as a mandatory part of your software to be on the internet, right? So, for example, well, let's just have a hosted option and that means that our customers have to log into a portal. We could build a, you know, a web platform for all the digital forensics. So, we'll just make people log into that. Like, nope, can't work. You'd automatically lose all of the customers that have airgap machines. That would be it if that was the only thing you did, right? that would just simply not work for many of the customers. I think a lot have moved more into that sort of space or they're open to it. But that has historically been a really big challenge in that space. So there's lots of other challenges with that. Right? So if it's an airgapped machine, there's no there's no network connectivity, there's no internet connectivity. Okay. Well, what does that mean for updates? Right? If the only way that you could update your software, just as an example, was through an automatic updater, right? Just just launch the app, it'll check for updates, it'll update on its own, like that's a that's a pretty snazzy way to make a desktop app just constantly be up to date, right? Like, don't worry about it. We'll download it for you. We'll put up something that says, "Hey, new update. Just press this button. We'll take care of it." Like, that's that's a pretty cool experience. you don't have to be bothered to go deal with this. But again, if that's the the solution that you've built and you have to have customers that are on air gap machines with no network, too bad, right? It's just not going to work. So, one of the things that was kind of interesting for us to learn is that we I think we over what's the right overestimated I guess the percentage of our customers that were truly on air gap machines because that was always something that was driven home for us. And I I don't think that was like a bad assumption. I think it was actually good that it made us think about this a lot. But at one point, and this is earlier on in in the company's history, at one point we were like, "Hey, updates are a pain in the butt, right? So people have to go to the website, they have to download the software or it was actually shipped on little USB sticks. And so obviously if it's shipped on a USB stick, we're not going to like send the updates on a USB stick. Like they have the USB stick. They can do their own updates over that stick if they want. But we were like, it would also be good if we could have automatic updates in the app. And I remember having this conversation. And I was like, "Yeah, but like sure, like we have some users that are asking for that or even internally we're like that would be kind of cool, but in the back of our head it's like, yeah, but we also know like that's going to be a problem cuz, you know, imagine all of these users who are so used to, you know, hey, don't worry, our software isn't connected to the internet." Now you're telling me you're going to connect to the you're going to connect to the internet to get updates. Like, no, no, no. You can't we can't trust you connecting to the internet through our software. And what we learned is that and this is this is great. Um we implemented the feature and it was optin and we actually because you get telemetry instantly from people trying to download. We realized there's a ton of people that were absolutely willing to go get automatic updates. So that was actually really interesting for us to go learn that about our customer base. And uh I would also say the same thing about telemetry, right? There's a lot of users. We had to be very careful about this for us as the developers given the nature of the work in digital forensics. It's very very difficult for us to be able to get diagnostic information from customers. They're literally investigating like cases which could be anything from murder or more heinous crimes that that evidence is like must be kept very secure. So like again it would make sense they would be airgapped. It would make sense they don't want to report any telemetry that kind of stuff. And what we realized is that when we allowed people to opt into telemetry we legitimately had plenty of people that were still willing to. So anyway I share all of this. It's a bit of a tangent from the desktop versus not conversation, but I share it because you may have some thoughts about your users and they may be valid, but I think it's also important to be able to challenge these types of things, especially over time. I I suppose now if I were to snap my fingers and be back in the digital forensics space and it's been, you know, six plus years since I've been in digital forensics, I suspect the landscape around that stuff would have changed a lot. So, if someone were to hire me into a digital forensics company and they said, "Nick, we want to leverage all the things that you that you knew in the past from digital forensics and we're going to go with that." I would say like, "Hey, like thank you so much first of all, but I think one of the things that's important to realize is that my experience in that domain after a break from it for six years, I must assume that the landscape has changed some. I must assume that. So let's go validate that first, right? Like it's okay that I can come with these experiences and these these perspectives on it, but let's go validate that. And I think that's important for anyone to be doing about assumptions they make. So as you're having these conversations with yourself, your team around like, hey, we're going to go build something. What should we be targeting? Like is desktop actually viable or not? Does it make sense? Should it be crossplatform? Challenge yourself. Go get the data, right? Don't just make assumptions about it. I think that's important. Um, this next part that I want to talk through is something I talked about on stream a couple of weeks ago. And I this is sort of like a bit of an AI segue, but like I do think that one of the one of the bigger decision points historically for me is like that you know what your team is familiar with should act like should absolutely be a part of of the decision-m process. I'm not saying it must be the the heaviest weighted one. I'm not saying that it's the only one that matters. I'm just saying I absolutely do think it's a factor. Okay. So, like what what does that mean? Right? Like Nick, we're engineers. Why don't we just pick the best the best tech, right? We all know, Nick, that we should just build stuff in Rust. That's it. There's no decision to be made. Just make it Rust. It's fine. Um that's just the best. There's no no other conversation. So why why am I talking about like what your team is comfortable with? The reason I say this is because if I look at um very big differences between things like being at a small startup versus a big company like Microsoft, I I do like reminding people that depending on where you've spent time, like if you've been at a a very early stage startup, you probably know this already. And if not, maybe you got very lucky. But um being able to ship things like quickly, get something out the door, get a product in front of users, get to solving their problem so that you can start getting more users, shipping value. Like that is a very critical thing to do. And I say that because again I don't think a lot of people realize if you've only been at bigger more stable companies stable in in 2026. Yeah. Um more stable I qualified it. Um if you are used to that then you may not realize that um there are literally companies who are like if if we don't get this software shipped right if we don't get this in front of customers we literally may not exist next week right like we don't have money so we don't have a choice we have to be able to factor in what is a quick way to do this and quick doesn't mean like take all the shortcuts, you know, release crappy code. It's it's got to be filled with bugs. It's not what that means. But I do mean that like you might need to pick things that you're using, make technology choices that allow you to move faster. And that could mean that maybe you're picking something that the team is more familiar with. Okay. So, what does this have to do with AI? Well, in one of the recent live streams, I was saying that I I do think this is still a factor, but I think it's becoming less of a factor if you have teams that are much more familiar with uh agentic sort of software development in general. What does that mean? Um to me that means like if you have people that are leaning into like, hey, I'm not going to be the one that's, you know, writing every line of code here. I am willing to use an agent. I can work effectively with agents and you have a team of people who are mostly comfortable doing that. By the way, I I always try to be careful about this. I'm not saying that is the way that you have to build software. I'm just trying to qualify this example. I think if you do have a team that is mostly like that, then that does give you this opportunity where the team is more flexible in terms of what text stack them the tech stack they might use. So, for example, um you might have a team that's like, you know, uh either they're less familiar with sort of like leaning on agents to do a lot of development and or maybe they're just very familiar with particular tech stacks. I I would put my historically would have put myself into this this camp of like I build things in .NET to a fault. Like I will picknet to build in knowing that it's not the best technology. But if you said, "Nick, I need to be able to ship this fast and I need you to do it." Then I would say, "I'm going to use .NET because I can build things in .NET much faster than anything else." Right? And if you had a team of people that was like me or similar, it doesn't have to be .NET, it could be whatever tech stack, then they might say like, "Hey, if you need this to go faster, if we need to iterate fast, then like yeah, like we're going to go pick something that's going to let us do that." Now, if your team is different than that and they're and they're leaning into leveraging agents a lot more for this kind of thing, not that it makes the the argument completely go away, but I do think that you can get more flexibility out of a team that's like, hey, sure, we might know C better than, you know, any other or like using as an ecosystem better than anything else. But like, hey, for whatever reason, like you're saying that this really has to be written in in Go. Like, it has to be or it must be in Python because of some other reason. Okay. Like we're we're going to be using agents to build it anyway. And like sure, there's going to be a bit of a learning curve, maybe a big learning curve, but the point is that we can lean on our ability to leverage agents to build that. we can bring with us all of our software engineering experience and then sort of like augment ourselves with agents. So I think that there still is if you're trying to make a decision about like what tech stack you're going to use for building things out still an argument for like what what is the team comfortable with but I think a big part of that argument change is now like if you're familiar and comfortable using uh agents to build things then you can kind of shift that conversation a little bit. Um, I'm just kind of reading this uh article. I already talked about the some of my experience from the digital forensics company. Did I have anything else on Microsoft? Oh, no. Okay, I already talked about that. Um, there was something else. This might seem like a a different tangent, but there was something else that came up on this on this Reddit uh post that this is all based on. And this person was saying that they like one of the arguments that they saw for doing desktop development. I didn't like I didn't fully understand this when I was reading it, but essentially they were saying like they believe that if they had if they had people like on a platform, right? So like just as an example, if we're going to build some software and we can make it restricted to just just Windows or just to Mac or just whatever, they were talking about this idea that like maybe part of that is like locking people into an ecosystem and they were saying that like they some idea around this like that's going to create loyalty to to the software. And I I remember reading this and going like I'm I just don't think I agree with that as a philosophy. Um so I just kind of wanted to to bring this up because it was part of the original conversation. But the argument for them seemed to be that if we have software that can lock people in, then that would make people more loyal. And I I don't think that that's a like a causation type of uh relationship. I don't think that locking people in makes people more loyal. I think locking people in forces people to be kind of screwed over, right? I think the way that I would frame this is like people become loyal to a, you know, a tech stack, software, whatever it happens to be, they they become loyal to it because they trust they trust in the product or the service. They trust in the people behind it. and they become loyal because they're like, I know that I can rely on this. I can rely on the people behind it to be delivering value. They're delivering quality. They're delivering value. I can trust in this, right? Like I have confidence in this and so I will be loyal, right? If you keep demonstrating that you can continue to ship value, if you keep demonstrating that um you know you have high quality software, that you have good support, like if you keep demonstrating all these things regularly, then I think people become loyal to that. I think that you are potentially mistaking loyalty with like literally being trapped if you were saying, "Hey, let's kind of uh you know, lock people into things." So, um, this kind of came from, I think they were trying to qualify this a little bit more. Um, they were talking about like like, okay, well, what what is what does lock in mean here? They were saying that they they suspect a lot of this movement to subscriptions versus not. It's part of it. So a lot of business models not all but a lot have moved from pay one time and you get the product right this is yours now um they have moved away to like basically SAS right so like you are going to pay a subscription and now we have recurring revenue from this person and so this is where this lock in conversation came from but if you were to have a big price tag and have someone who now owns the software right so you've paid paid for this this thing, now you own it. They were saying that this uh created some type of lock in effect and that was to build loyalty. I was like, I I don't know. I just don't think that's the case. But I do agree with the other part of what their argument was, which was around this idea of like pay once versus subscription. I do think, again, not saying this is right or wrong, it's not for me to say, but I do think there has been a lot more movement to subscription-based models for businesses, right? I don't I don't have the data in front of maybe we when I talked about this on code commute, I'm like saying in the car, I'm like, I don't have a I don't have a computer in front of me because I'm driving in my car, but I do have a computer. So, we can ask Gemini maybe. Um, let's see. Uh, how what do the stats say in terms of software companies moving from pay once for a product to pay a subscription? in terms I already said in terms uh this is with respect to their business model um because I'm curious right like I I I believe that that's been the move um subscription dominance subscription based pricing accounts for roughly 67 to 80% of modern software revenue interesting massive valuation growth companies operating on a subscription. A recurring revenue model grows significantly faster than legacy hardware or perpetual license counterparts. Historically tracking 3.7 times faster. Interesting market size. The global SAS subscription software market is projected across uh roughly 500 billion driving over 50% of the software hybrid holdout despite the heavy tilt toward subscription. So again, there there has been this move. Legacy and on-remise software hasn't vanished. Surveys indicate that up to 60% of organizations still run some legacy systems with perpetual licenses. Okay. So interesting, right? Um but my my thought was like based on this person's framing, they were saying, you know, is desktop development dead? Because it seems like everything has moved away from that. I was saying I think if you are observing that kind of trend probably one of the things that you are observing is related to people or like business is moving to a subscriptionbased model and that doesn't automatically mean like if you have subscription therefore it's not desktop like what's a great example of this uh Adobe right like um I have well actually I've been uninstalled them recently I still have Adobe Reader and I it makes me log to read PDFs. I'm like, "Stop. I'm just going to open it in Chrome." Um, but like I I had the Adobe suite of software, which is desktop software on my computer, and that's SAS, right? Like I have a subscription for it. So, it SAS does not automatically equate to therefore must be something that's not desktop. But I do think there is a and I I should ask Gemini um what the correlation is. But uh I think there is a a correlation with companies moving to SAS subscriptionbased recurring revenue and this model of like and also let's let's get it um is web apps. How does uh recurring revenue and SAS models correlate? I'm trying to like think about how to ask these questions for the first time. Correlate to the distribution of desktop software versus um browserbased software offerings. So I'm curious, right? like is is there a correlation to this? I think there probably is. I don't think it's a causation. I don't think it's a rule, but um that's my assumption, right? So, Gemini is saying the structural shift towards recurring revenue and SAS models has directly inverted the distribution of software. So, historically, software distribution was dominated by locally installed desktop binaries. Today, browserbased distribution is the default engine for modern software. According to enterprise application data, I mean, by the way, you can't see my screen, but uh this is Gemini citing some Medium articles, so I don't know, you could probably dig in deeper to this, but uh browserbased SAS applications comprise roughly 50 to 77 50 to 70% of software distribution access points, while pure desktop distribution has shrunk approximately to uh 25% of the market. So, that's interesting. Um, I'm not like I'm not surprised by that. But again, when I was talking about this topic originally on code, I'm like I'm I'm in a car, man. Like I I think this is probably some type of correlation, but I don't have data. So, yeah, I think that is kind of interesting. Um, so one of the things that's called out on one of these tables here is like, let me just maybe I'll just move this over. One sec. So I'm looking at this table which I think is kind of interesting. So it says browserbased SAS delivery typical valuation multiple five times to 15 times revenue and legacy pure delivery one to three times. Right? But again, I don't I'm not like going through all of the data that this is citing and, you know, uh proving if it's real or not, but I think that's kind of that's kind of interesting, right? This this particular part here. So, yeah, I mean, something to think about, right? I I think that what this person was probably observing when they were asking this is is this move to to SAS. So, um I think that's probably mostly it for this live stream to be honest. I think that I wanted to talk through that because I thought it I mean people engage on that one the most from code commute. I thought that that was an interesting topic because like my majority of my programming career up to this point has been desktop-based. Um, right now for the very first time as I'm building some games on the side, they run in the browser. Like I that's never happened. Um, so one of the games I'm building and actually is a game that I have spent the most time either building or rebuilding has always been um, it's always been in C. It's always been made for desktop. I think at one point in time the only reason it had any type of cross-platform capability was because there was a game framework called XNA. I think this is maybe some people know what that is but that uh that technically would work for Xbox. So I had something that was crossplatform. Um but I mean it's always just been in C to run on Windows because that's all I cared about to be honest for building stuff. And um for the very first time that game is now being rewritten, redeveloped in in a browser. And I wonder if Claude actually has something working here. One sec. Come on, Claude. Do we got We got an example. Maybe we could see my my AI version of this game. Do you guys want to see that? We could do that for the last few minutes. Okay, we'll do that. Um, let's do that. Ready? I haven't seen what it's put together today, so fingers crossed. Okay, so if you want to try it out, it's at local host. No, I'm just kidding. But it's uh it's not online yet, but this is one of the games that I'm making. The game world is called Masterus. And so, Masterus has historically been something that kind of looks like Pokemon, but it's uh I don't know, a lot of like advanced RPG concepts, game mechanics. And so, I've built in the past like a tactical RPG version. I really want to do an action RPG, but I wanted to start getting the game mechanics built in the tactical RPG, and then I'll I'll continue to build out the the action RPG. So, let's see what we got. We'll do new campaign. Come on, shaders. Wow, look at that. If you uh were seeing some of the stuff that I posted on Twitter, then you will know that all of this is built with AI. I'm not trying to say that as in it looks like uh you know the highest quality, but what's cool is that you know it was able to put together like these skeletons and the armor and stuff they're wearing. This is actually all like AI and I showed some of the progression of it which is pretty brutal. Um, I'm in the process right now of redoing all of the character models so that when I'm generating equipment, uh, and I'm going to be making some videos about this on my my main dev leader channel, but um, I'm going to be generating uh, all of the items with uh, I don't know how to pronounce it, try um, it's a a 3D sort of model generator. So you can give it a prompt or give it an image and it will go make 3D assets for you. So um that works really well. I've been very impressed, but I basically needed to kind of start over and say, "Hey, whatever was being built for the assets in here in terms of uh the characters, the rigging, and all that, we're starting over. So you'll notice that like this one looks kind of funny. I can't zoom in anymore, but the the cloth on the back of this guy, like his it sticks out over his butt, like it's rectangular. It's kind of kind of ridiculous, but we can we can start off. We'll place our unit here. We'll begin the battle. And it's a tactical RPG, right? So, out of movement, this is that's water. Oh, so there's water on the ground. So, already I'm like, okay, we got to make got to make this look a little bit better. But I'm gonna move here. So, this was supposed to be water that's placed on the ground. So, the uh actual like what do we call it? I guess the effect of the water. There isn't one. They're just using like highlighted rectangles to indicate that. And I don't think I can reach any other characters here. Can I cast a fireball? Can I do it? I don't think so. No, I can't. So, I'm going to end my turn. Okay. They apparently don't animate when they walk. That's fine. But, can I get I can't get to him. Okay, we'll walk over to here. I'm going to face this way. Okay, now they're surrounding me. That's fine. And so in the top left, it says what the goal is, right? So I I have to defeat every enemy. There's different goals that can happen. So I'll attack him. We got a critical. Cool. Right now, like I was saying, there's no actual animations on on these things. They're going to have to get redone. But nice. We got some loot. I don't know what this uh I think there's like a model that's not loading for this white box. This has been like this since the very beginning, but we what I haven't seen ever before is now we have these uh like light pillars where the loot drops. Okay, so I got to do a quick strike on this guy. Does that not work? There you go. Quick strike. I missed. Oh, come on, man. It's brutal. Okay, so he's gone. I don't know why this happened too, but I can't uh can't pick up the loot anymore. Maybe maybe the AI changed that on me, but it was cool. You used to be able to walk up to the loot on the battlefield and pick it up as it was happening. So then you could go to your gear and then you could equip things as it was happening. Um but it looks like that's not the case now. So, we'll figure that out. Uh, four. Can I hit him? No. Did I miss? What happened? Something's got to be fixed here for sure. Okay. Can I get an arrow? Nice. Okay. So, apparently I can shoot arrows without a bow. We'll get up here. We'll get this guy killed. Nice. Okay, so we got some items. I should make it so that you can highlight them when you're here so you can see them. But we'll go back to the headquarters. Um, so now we can go in here. So there is a bow. What? All of these are bows. What the heck, man? That's silly. Okay. Cool. So, we can equip a bow. So, now our stats change. Um, it looks like for some reason I didn't get any of the gold for that mission, but you can go recruit heroes. It's funny because these portraits, this is when it was trying to equip the armor and stuff that it was making originally. So, it made like oversized like headgear like these cloaks and robes and stuff. It's all everything that you're seeing is like it it generated the the items and this is before I was using this fancier thing. So all of this is still kind of legacy. It was really funny because every piece of headgear instead of like clipping like making it like tighter to the the actual head and then clipping the head from showing through. It was like, "Oh, I have to make it way bigger so that so that the head fits inside." And I'm like, "No, no, no. You got to stop doing that." But um anyway, it'll be better so we can hire some of these these characters. And so you can build basically a party and then kind of go back out and um and go battle. So there's different maps and stuff. But anyway, that's where it's at right now. I'm going to be very excited to show off when um there's a little bit more of the 3D modeling and stuff done. But one of the things I was doing right before this stream was that when it goes and does um like the layout for trees, this one's not so bad cuz it placed a couple of trees or whatever, but there's a forest tile set. And the problem, one of the problems with the forest tile set is that when it's generating and placing the trees, if you look closely, the trees are basically just completely aligned to these different grid cells. And so that's really not a natural way to go make a forest. So, um, I have it basically getting reinstructed how to go place things more naturally so that we don't have this like completely ridiculous looking kind of forest thing going on. But anyway, it's fun, but lots of uh lots of opportunities for this thing to get better because it's uh still pretty rough. This is one of the reasons why when I go to build games like this, like I'm not good I'm not good at all at anything artistic. So for me to even get to a point where it what you're seeing is done like that would have taken me who knows how long. So I would much rather spend time like building cool game mechanics like having fun with that and then I can you know I'm now it's cool because we can use agents and things to help us. But one of the things I will say is that because I am not very experienced at building things in 3D building environments and stuff like that, it's actually very difficult for me to use agents effectively. It literally feels like I'm the meme of like make no mistakes when I talk to AI and then it goes and and makes like really silly maps and stuff and I'm like I don't I told it to make no mistakes. Why is it still doing that? But that's where I'm at with that game. Um, there's another one that's called uh Evo Habitat Zero. I I'm really excited for this one. I think it's cool. But um I'll show that off a little bit more some other time. And I guess with that said, I'll wrap up by uh directing you guys towards different channels and stuff. But uh starting things off, my main channel dev leader, which I'm not sharing my screen. One sec. my main channel, Dev Leader. Um, I I have been saying it for a long time, uh, for months now, but I I am going to start making videos on this channel again. So, I did put out the first one in in seven months on on this channel. So, um, that's here. I have another one scheduled for for this week that'll be coming out. And then I have a bunch more videos that I'm excited to try putting together. And so, uh, I will be doing a lot more content on AI and a lot of the things that I've been learning. So, let me go ahead and grab this. I'll put this into the chat if you are interested in checking it out. But um long story short, because if you don't want to watch my almost 18 minutee video here on on what I'm catching people up on is basically that a lot of the videos I'm going to start making, I'm going to be trying to share what I have been learning with AI and agentic development because one of the reasons that I was not cranking out videos is because uh if you are familiar with my main dev leader channel, a lot of it is like C tutorials. Right. A lot of it it's all based on the fact that I've been you know developer for a long time. I have a lot of things to share on that. But it doesn't to me it makes a lot less sense to focus on just like you know C tutorials. So I want to make sure that I can bring some of what I'm learning from AI uh development back and then I can make other tutorials and things around that. I'd like to be a lot more sort of authentic and genuine in like how that content's coming together. And that might mean, hey, look, we're gonna try some things out. It's going to be an experiment. They might they might fail. That's totally cool. But I'd like to show people that I want to show people how I'm using AI. And that way, if you're picking up on things from that, you're like, I didn't know I could do that, or that's a cool way, I should try it. Great. Like, that's all I could that's all I can ask for, right? So, do check out Dev Leader if you want to see some of the tutorials and AI stuff that I'm going to be putting out. Um, Code Commute is the other channel I mentioned. So, Code Commute is the channel that I do my vlogs on where people submit questions or I go to the Experience Dev subreddit. As you'll notice, I make these videos when I'm driving to and from work or to and from CrossFit. So, uh, if you have questions that you want answered on code commute, let me go ahead and put code commute in the chat and then I will also say like code commute.com has this submit anonymously button for the question submission. So, you can go to code commute, you can submit your questions, um, whatever you want, right? Send me something. I'm happy to try making a video response for you. And I always like to mention to folks that historically, you know, people were saying, "Hey, Code Commute's fun, but like, you know, basically I watch it. I have it in the background and I don't have YouTube Premium, so it kind of sucks. I have to keep my phone open. Could you put it on to Spotify?" And so all of the Code Commute videos go on to Spotify. Let me double check this. Um, it should be This might be a little bit behind it. It syncs every so often. So I think once a week it will try to sync. So might be a couple videos behind for this week and last week. But um yeah, you can check out Code Commute on Spotify as well. And then couple last sort of like sales type things. I do have courses. These courses are on dome train if you're interested. Um I'm going to be trying to come up with some other additional offerings as well. I shared with people before that I didn't rush into making like, you know, AI agentic courses on dome train because it felt uh disingenuous to me. Like it felt like that was that's the wrong thing to do. I'm not in a position if all this stuff's moving so fast that I I jump into just trying to, you know, put a course together, get people to go buy it, I'm like, that feels kind of feels kind of bad, man. Uh but whether it's on a sale nice early Black Friday what man that's cool anyway if you want 40% off the courses. Uh here you go. That's how you do it. Just hang out on the page I guess and it shows up. So um yeah, these courses are like primarily for programming in C and then there's some career development um getting promoted, behavioral interviews, soft skills, that kind of stuff. So hopefully these types of things are helpful for you as a software engineer. And then last but not least is Brando Launchpad. So, uh, Brando is the social media cross-osting platform that I created to be able to help with all of my content creation. And we've been, uh, shifting our business to make sure that we can help other businesses with not only their social media posting, but also making sure that their SEO, AEO, and GEO are on track for their business. So, you can head to Brando Launchpad. You can submit your website there. Um, there's a really I think it's a really cool onboarding flow where we try to learn your website, see what you're up to, and then put together a marketing plan for you. So, with that said, if you are someone who is a business owner, you know, someone who has a business, they need a little bit more help with their marketing and their social media, uh, do check out Brandos Launchpad. This is absolutely something that I spend, you know, all of my time outside of work. that is the thing that I am building and investing my time into. So, um you know, if it's something where like, hey, this this is great, but I wish it could do X and that would be the thing that I need, let me know. Like, reach out to me. I'm on every social media platform. I'd be happy to hear from you. Um because I think for for us, like how we use Launchpad is how we grow Brand Ghost, which is cool, right? We're trying to use it ourselves to be able to to grow and we want to be able to provide that as a service to other people. So, that's what I got, folks. Thanks for being here. And the plan is next Monday, same time, 700 p.m. Pacific. So, I hope to see you all next week. In the meantime, head over to Code Commute. You can check out similar videos that are like this except I'm driving in a car and I don't respond to live messages because live streaming in the car would be kind of crazy. And then otherwise head over to dev leader. You can check out my YouTube videos that will start going up more regularly again. So thanks for being here. I will see you all next week. Take care.