Erik Engheim is an Author, Educator, Speaker, and Software Developer. He joins the show alongside Shawn to talk about " The Rise of Monolithic Software". He starts off as he talks about his past experiences as a developer and the path that brought him to this point in time. Moreover, he shares his perspective on Monolithic Software and what it is all about. 

Hello and welcome to another episode of adventures in dot net. I'm Shawn Clabough your host and with me today, our guest straight from Norway. Eric Engheim. Welcome Eric.

 

Thank you. Good to be on the show, Shawn, or the podcast.

 

Yeah, yeah. So thanks for coming on. But before we get started in the main topic today, why don't you tell us a little bit about yourself, kind of what you do, how you got into development, and what kind of things you're working on now.

 

got into development when I was a teenager on an Amiga basically and I think it's I think a lot of people can relate to this is they play computer games and and maybe they play some computer games where you can be a bit more creative and build your own things and then it kind of just spins on from there we're like oh well if you can if you can program you can really get going combination of being interested in science in general and Just games and I want to get into game programming and that stayed with me for a long time But But I she was gonna study I ended up doing Because I was very interested in you know a little bit of a typical geek you know interested in the science fiction and You know space exploration all these things I had a period of very interested in artificial intelligence back when that wasn't going anywhere, right? Today it's a very different world. But I wanted to get into building robots, so I kind of started in the sort of robotics line in my undergrad and did neural networks and things like that. Never really ended up doing anything with it, so it's very annoying to see what's happening now. It's so big because I couldn't find any really job with that. years ago or so.

 

Yeah, that brings back some fond memories there talking about Amiga. And I remember playing the original Lemmings game. You know, yeah,

 

Oh yeah, yeah exactly,

 

over and over

 

yeah.

 

and over again. Yeah, doing that. And then talking about robots, it made me... Did you remember the Heath Kitt robot? It was kind of a kit.

 

No. Yeah, I mean, this is also, it's a little bit of context also is useful is growing up in Norway is, in particular when I did, you know, in the 80s is very challenging for someone who's kind of a tech geek. I grew up in a kind of small town, blue color kind of industrial town. Where my memories of kind of growing up is, it's a bit like just all the factories that were closing down one year after the other. So I didn't really have all that many people that had the share of interest and you couldn't really get material. So just getting hold of learning material was a challenge. So I had a very strange path in how I learned things. I was lucky in that, and I think I missed out about the computers today, is that the Amiga 1000 that I got, it came with a programming manual. Now I bought it at Uso, I'm not sure if that's normal, but I had the impression that computers year towards programming and they came with manuals and so on but they weren't really very user-friendly. I mean they were kind of like look-up things. So I had to try to learn Amiga Basic by kind of something that felt more like an encyclopedia. And my English wasn't very good either. So that was certainly challenging. I think I learned a lot of programming from actually just reading computer magazines. That's an area that we're kind of blessed is that because it's a small country, there's a kind of a strong sort of magazine culture, I'm not sure what to call it, but we have this chain of stores that's kind of all over the country that would import newspapers and magazines from different countries. So, you know, I always had from one of the kid, I'd access to German or French or American and I could walk from my house about 20 minutes or so down to the magazine store and I'd look at all these magazines. So I followed a lot of these kind of things in magazines to learn how to program. And then it'd be like occasionally, you know, I'd be on a trip abroad and I might locate some bookstore. But I actually learned, one of the first things I learned was actually 65 with two assembly code. to programming book on my local library, right? All the stuff they had was kind of outdated, right? Because you weren't, people weren't, you know, this is more of the Amiga days, right? So people weren't really doing 65.2 programming. But I was actually learning and writing 65.2 codes, but just on piece of paper. I didn't have anything to run it on.

 

Yeah, the Amiga used what the 68,000 if I remember right.

 

Yeah, yeah, and I had problems finding documentation for that. So I did get into 68K assembly code, but it was kind of a reference instruction set manual. It didn't really tell things that you have to know in assembly code such as, you know, where are the important memory addresses and so on so that you can interact with APIs or graphics memory. You know, you saw the Miga guys were doing all these cool graphics tricks by writing, you know, some very clever assembly code and I wanted to do that, but I had no idea how to do that. I should work with later with people that did that, but yeah, they were luckier than me. They just got whole of the rights literature and I just didn't know how to do it.

 

Yeah, the boing ball and all sorts of things like that. Yeah. Did you ever take your case apart?

 

Yeah, unfortunately, I shouldn't have done that.

 

Did you have the case with the signatures inside and the paw print?

 

Yeah,

 

Yeah.

 

yeah, yeah. And it was like built like a tank. I remember it was so much like kind of steel and stuff in there and and Millions of screws. It was a lot quite a lot of effort to get in there It was late when I had it because we had started having problems with the Not not the hard drive the floppy drive disc drive It had already started where we put a stick in there when we were reading from it We had to push a stick in and hold it while reading because it was really not working very well and then I was started opening it but you know I shouldn't have done that then it was a beyond repair afterwards

 

Yeah. Well, so you stayed with tech and development and things like that since then. What kind of things have you worked on for most of your career?

 

Yeah, so I've mainly been an application developer, desktop application developer, and maybe that's why I have a sort of bit of an old school perspective on tech development. I was never really got into the website of things that much. I did start in Accenture, and I would have probably been this typical web Java guy if I'd stay there. But this was just the dot-com bubble. was about half a year away from finishing my undergrad and they were just hiring like crazy. So they had the biggest hire I think in at any time. I think this is the biggest hire in Norway that a center had done. And we were something like a hundred people in the Oslo office hired us in time. We're all kind of similar age and so on. It was really fun. It was like being in a class, you know, with a light-minded people and we're doing all this training together and so on. started was we were already obsolete the first day that we put our foot in the office because the economy has just tanked. So eventually they get rid of most of us. And that's how I ended up in the oil industry that's really been my career the longest which is kind of the tech side of the oil and Norwegian And I really love that because I had a passion for Science and you know natural science and physics and so on and I got to work with Geologists and physicists and a lot of these Different people and you know while it wasn't a computer game. It was so cool like we work with 3d and stuff So you know I was It's very satisfied With that And I had a sort of, in between, when after I worked with that, I went abroad to do a master's degree. I was in the United States and the Netherlands. And then I came back and I continued another kind of similar kind of oil service company. So I'd done a lot of C++ programming. They had some scripting and stuff like in Python. Didn't do that much with that. quite early passionate about user interface design and software architecture. So I was an a software architect for a while on the software and I also was actually head of the user experience. They didn't have any, the one really taken care of that. And I was, I used to start on my own initiative doing all these tests, because the software was, you know, overly to mobile phone stuff, been making iOS applications, Android applications and stuff like that. Because I thought I've been, had, I was so many years in the oil industry, I thought, and I was working with tech that stretched back to the early 1990s. I think the application I worked on, it started in 1991 or something around the time with the first Jurassic Park and, you know, that OpenGL first got out. The software had a history back on IRIX machines. And so I was really in this sort of little bubble world of, you know, old school tech. And I thought, I can't stay here too long or I'll never be able to do anything else. And I had been doing Objective C programming because I'm a big Mac fan for a long time. And then iOS, you know, really hit it. And I was like, oh, wow, they're using a technology, an obscure technology that I already happened to know, would be beneficial for anything. So you know it's a chance of sort of doing something that I had some passion about. So I worked in different companies doing that, making iOS applications. And now the last couple of years I've been much more into content creation, making videos or writing. is a program language where a few have heard about. It's called Julia. So I'm coming out with a book actually about Julia. I called Julia as the second language that's, I think, is just a couple of weeks away now. But I made a video course on Julia programming before. I was one of the early ones that did that. It's kind of a, you know, a little bit of a, you know, a little bit of a, you know, It's something that's probably going to be relevant in the future because it's very well designed for machine learning, big data and that kind of stuff, which is the very hot thing these days. And something like Python, which is the 800 pound gorilla, is... isn't really that well designed for it, to be honest. Right, it just kind of accidentally fell into that space. But I think something like Julia is, you know, does actually made for really high performance the kind of stuff you would need for this kind of stuff. So yeah, we'll see. But that's been a kind of also a passion for a while. I did that probably started like nine or 10 years ago. Also, I didn't really think that would ever become anything. Even if it's small, it's still grown a lot. So you know, it's enough that I've been able to have, you know, Julia training and write material and create cotton and so on for that. So yeah,

 

Okay.

 

I think that's roughly what I've been up to the last 20, 25 years or so, I guess. Yeah.

 

So nice. So our main topic for today, we're talking about monolithic software, you know, and kind of how, you know, it's kind of taken over a lot of things that have started out, I think, not having that in mind, and then have kind of grown to that kind of a structure and things like that. So why don't you first kind of define what monolithic software would mean?

 

Yeah, so I'm not really, I mean, I'm not like this kind of typical architecture guy in this, so, but I see it's just at different levels, right? I mean, it could be monolithic, kind of, from the perspective of development, you know, are you building? you know, large pieces of executables, you know, you can think sort of, you know, microkernel versus monolithic kernel, that kind of stuff. But I also see it, I mean, I also think a lot about from the user perspective, because I've done a lot of user interface stuff. And I think that there is, you can also talk about monolithic software and non-monolithic software from a user perspective. When you're using the software, are you using multiple smaller well-defined pieces of software that can interoperate well? Or are you using this like huge integrated system like a big software that could in principle be quite modular internally, right? I mean, it could be made in all sorts of plugins, but what you actually are presented as a user is quite monolithic. different ways. And I'm ideally would want to see things being partitioned at both the development level and kind of at the user level. And I think that also would help both users and developers. And of course this exists in many spaces. I mean, the hottest and most talked about is probably right with microservices. I don't really know microservices that well certainly seen it from a desktop development perspective because I worked on very large desktop software and I have a passion for the UNIX philosophy with the small tools that you combine. And I just seen it with software I used over many years, such as Xcode for development, the dots gone from being split into many pieces of software that you kind of could work well with together much more integrated whole. And then certainly there are benefits to integration. But I think that there is I think that people are very tempted to do, you know, they want to gain one thing and then they forget all the things they lose, right? It's not like everything's going to be better if you're all just distributed or split into small components. I think there are downsides to it. It's just the trade-off you have to make, right? And I think we're going too much towards the monolithic trade-off and thinking that's always the better choice.

 

Yeah, I think of monolithic of kind of my front end development. I think of building a spa. You know, everyone wanted a single page application that pretty much had everything that the application was ever going to do and all the different modules in one spa that you build and compile together. And then people quickly learned that that becomes really unmanageable. And so they started calling things mini spas. would be its own spa and another section be its own spa and think that that trying to really recognizing that building everything together that things that are unrelated probably shouldn't be built into the same package and distributed that way because there's things that people

 

Yeah.

 

aren't using all the time and why load that.

 

Yeah, exactly. And I think that if you read about usability and try to sort of understand a lot, and I think maybe more tech people should do that. We know that humans have an easier time understanding things when there's not too many things to see at the same time. A common trick in user interface design is to hide the information or the functionality that isn't relevant right now. So a lot of good user interface design And so that, you know, you're, for the context or the kind of work you're doing right now, you only see the tools that are relevant to that. And as you're changing what you're doing, you click on a particular button or change the task, then more new things become available or visible that's related to that task. And I think you can extend that into what you're the functionality of several applications put into one, then you create too many things in at the same, there's too much context, right? There is, I noticed that for instance with Xcode. So Xcode used to be a kind of managing your project and doing source code editing. And then there was a separate tool for user interface design and you basically do the version control separate. user interface stuff, right? I'll just click on the user interface application and now everything I see in the menu, all the buttons I see, they're all user interface design related and that's the only thing I have to relate to. But now in modern Xcode, it's sharing and competing in the menu bar and everything else with functionality that has nothing to do with say user interface design, even though you know I might be currently mentally just focused on user interface design. I don't care about all the other stuff, there and I still have to relate to it. So yeah, I guess that's a bit of that similar kind of thing that you're talking about.

 

Yeah, it's almost like people forgot about, you know, separation of concerns in their development and their organization of their of their applications and their code. And, and I don't think everybody really means to do it that way. I think, you know, the initial scope is defined that, okay, the scope isn't that big, we'll just put it all in this in this one application. decide to add more and more and more to it, then they just add to the existing thing rather than saying, okay, is this really tightly closely related to what we had before? Or should this be a separate module? And then maybe have the interfaces, like you said, change depending on which module you're in, or they just going to integrate everything in together and make one big monolith.

 

Yeah, and I think that's, I've seen when some of the big software I worked with is, I remember there were things that was actually separate and I thought, well, that's cool. And then they, they integrated it. And one of the reasons I remember the motivation for that was they find it so tricky to debug, right? You're, something goes wrong in one sort of separate thing and you're stepping through there is a communication boundary to a separate application. And so now they're like, oh, well, what if it's just all in one? You can just step all the way through the code to the very bottom. And I think my argument against that would be that really what people are missing is they need to have good tools for monitoring and understanding the communications. If you write a sort of web application with the REST API now, you have such great tools that you can monitor the communications between the service and the application. I noticed that when I was doing mobile phone development and that was a new world for me. I was using this Charles, Charles Rear's proxy, whatever application, and you can then and your web service. And you could do things like record that communication, replay it, and I thought, hey, that gives lots of cool new opportunities in terms of debugging and understanding the application. And this kind of communication is quite invisible if you're just dealing with a monolithic software. So I think the problem was, the stuff I worked with before was, it was kind of a custom protocol, which meant didn't have this sort of rich plethora of tools, to monitor that communication. And maybe that's what you need to think about when you think that your distributed system with multiple components doesn't work well because you can't just step through. Well maybe you need to just take some time and write good diagnostic tools for monitoring the communication. And I think I'm a very big fan of that in general, write the tools for helping We don't consider that writing tools for your process and your development process should also be a natural part of application development. I've been inspired a lot by that. I'm looking at the game developers. They seem to make lots of tools for their development process. I'm surprised at the more traditional application development that I've been in. It doesn't seem to have a habit of doing that.

 

Do you

 

That's my speculate.

 

find that web applications tend to be less monolithic than desktop or mobile or? What's your thoughts on that?

 

I don't know, I'm not really very well experienced with web applications. I mean, I guess that's one benefit of web rights, you get that natural separation with the service in the back, right? I guess that with the mobile stuff, it seems to kind of get a good separation because of the stack that you're using to create a mobile application and the stack that you're using, the text stack you're using to create the web service are naturally very separate. So you create a clear separation between the business logic and your visualization. I'm not sure exactly how it would be when you're now with modern web and stuff because And so there's much more mixing and I guess, you know, in a lot of ways that's seen as a positive. It also means maybe you don't get quite the sort of same clear separation. Yeah, I'm very torn on what I think about. It seems like there's a big problem with monolithic software in the web too, even though we have that separation. Yeah, I'm not sure. I think that's, yeah, it's at different levels. Cause on one end of the tech stack, right? Because you have the separation between the user interface, the web part and the service behind, that gives you some modularization. But if you, some of the stuff that I wrote about, right, and splitting applications is about on your desktop, having multiple smaller applications that are communicating with each other to sort of create a sort of bigger virtual application, if you will. where you can work together with multiple applications. And in a rich desktop environment, that's possible because they typically have good facilities for applications interacting with each other. With the web, you kill that entirely, right? Web applications aren't really made very well to their little sandbox, right? They're not really made to communicate with each other on the desktop. So if you want to create a whole little ecosystem applications that you're running and that you want them to work sort of together, I don't think that's going to work so well. So you kind of gain modularization at one level and you kind of lose it at another, I guess. I guess that's a lot of what I wrote about that I'm complaining about. That's a bit of a, you know, I feel like a bit of

 

Thank you.

 

I just need to get on with the program. But yeah, I do definitely miss this kind of, the more small applications, specialized applications with pretty simple interfaces that you can use together with each other, you know, I drag and drop something and I can select an item maybe in one application, drag and drop it to another and it does something with it there. Yeah, there's different ways like that. It seems like it doesn't really work so well with web stuff. It really, I feel it really pushes you in a kind of monolithic direction. When I do development, I like to kind of have my own separate Git client. I ideal have my separate user interface design application, my own editor, maybe even like a separate application for sort of project management or something. I've waited for that for a long time to have a file manager that just generally just works really great so that I could actually use for project management, but I haven't really seen that yet.

 

Yeah, so my thoughts are

 

Yeah.

 

that web applications nowadays are just a different form of end tier development. And each tier can still be its own monolith if you build it that way. So you can get each

 

Yeah.

 

tier, it can be much too big and much too tightly coupled and just mixed functionality if you let it get that way. I also have to think there's got to be some benefits to building things as a monolith.

 

Yeah, I mean I think there is it's a kind of convenient to do it and I I guess there's also a drive there From a business perspective, right? Whether you're a facebook or google or whatever You like that that that sweet lock-in and You know you're building this very strong ecosystem that people can plug in their things and so there's certainly a Modularization at some level because if you didn't you couldn't have other people But it's very exclusive, right? Because if you make some plug-in or something for the Facebook platform, you're not going to be able to put it in on some Azure or Google App Engine or something else, right? You are kind of locked into different platforms. And so we're really just back at the old complaint, like, oh, well, this Windows app doesn't run on my Mac, and it's so bad with platform-specific tools. now just at the web now that the platforms aren't called Windows and Linux and Mac now they're just called Facebook and Google and Microsoft, Azure or you know whatever have you and so it's just sort of rinse repeat on the same thing and I guess we're just one will just keep getting back of it because there's the same business rationale driving or platform that is more profit in that. I've seen that with, I think I mentioned that in my article about when I started doing app development, I had this super naive idea that we would make this generic banking application, because I was doing some banking stuff first and I thought I could then use this banking application for any of my banks, right? All the standardized banking product or whatever and I didn't realize, oh wait, it's not how it works. reinventing the wheel, making the same banking application, but with, you know, their logos and their particular idiosyncrasies. And so it was weird, you know, sitting there and kind of building the same application over and over again. Like, seemed like a waste. Yeah, I can't help it, sort of like, I get a little bit political about this stuff, you know, I'm not just writing about and politics and so on. And then there's something that sort of, I get thinking that sometimes maybe government should have been a bit more active in some areas to set standards and so on. Cause I just noticed with, I thought a lot about this when I was in the 2000s when I was in the United States. And I remember how crazy it was with the cell phones there cause there was CDMA, there was GSM, I think there was something like four different standards at that time. There was some analog in addition to the digital. I don't even remember all the stuff that was then. And then each vendor had their own kind of lock-in and their own cell phone towers. So I was going to look at how do I find a cell phone that covers the areas I'm going to be in. And that also happens to be in the company that sells the kind of cell phone that I want to Norway and that felt like this like impossible puzzle to solve. And then I remember thinking you know like how complex a mess that was compared to what we had in Europe where they had standardized on GSM right so that was all over the continent and you just had different companies, everyone can make different phones and services right but they're all applying to the same about email, SMTP, or pop through, or whatever, or all these different protocols, right, that dominated the internet before, where you have different companies can provide the end service or run the server or create the clients. And so you, as a consumer, get a lot more choice as long as you get this standard open protocol. And I think that, I guess, the old internet was more idealistic, but also be influenced by more sort of political decisions right that you saw in the year where there was a more deliberate attempt to establish one standard that everybody would stick to. I know, sometimes I can't

 

Yeah,

 

help but think

 

no

 

that they should be something

 

us

 

like

 

in the US,

 

that.

 

you know, we like to make things complicated.

 

All right.

 

You know, can't be simple and straightforward.

 

Yeah, I guess that, I mean, there's advantages, of course, in that you can experiment with a lot of different things. But I guess it's like there's, in the US, there's a very strong skepticism towards having government involved in anything. And so that, of course, I guess, sort of creates some barriers to kind of having that role for government to set some kind of standards, because people aren't going to trust the government for, you know, they're going to think they're coming with a bad standard. come up with a standard, I don't

 

Yeah,

 

know.

 

we kind of say, you know, let the market choose, not the government and things like that, but you know, it's not always the most efficient.

 

Yeah, it's like trade-offs, right? It's a hard choice, right? And then wouldn't be sort of a category. This is a problem I had in tech also often is that I really kind of felt strongly that we should go in this and that direction. I never really know for sure. And it's that I think, I'm not sure if you have thought about that, but I keep thinking about that. Nobody ever got fired for choosing IBM. And I'm a lot like that often where I really believe in something entirely different from what we're doing, but it's different enough that I don't want to stick my head out and end up being wrong. So I'm just going to go with the safe choice, you know, basically let's just buy IBM because they're never going to blame me for doing that.

 

Yeah. Well, you know, back in the 80s, you know, we had VHS versus Betamax, and then we had, uh, HDDVD versus Blu-ray. So...

 

Yeah.

 

things like that go on.

 

Yeah. Don't you think that? It's like in the industry, it's the same kind of stuff just keeps coming back again and again and again and a kind of different slightly altered version, but it's still kind of, if you squint, it's kind of the same thing you've seen this before.

 

Yeah, I mean, I always wonder, you know, why are there so many different programming languages or for front-end development? Why are there so many different, you know, frameworks to build applications, you know? They are all really kind of getting to the same end goal to have something that users can use, but you

 

Thank

 

know,

 

you.

 

unless it's really specialized for a specific environment, you know, do we really need all these?

 

I mean, I'm a lover of programming languages, so I was like, ah, the more the merrier, but I guess that it would have been nice if these different languages were interoperating better. And that was, I remember when.NET came out, it felt like, oh, this is a dream. Now you can just choose whatever your favorite language is, and it doesn't matter. It didn't quite work out that, I guess. completely dominating and it wasn't what I had expected. I think I had in the sort of naive thought that everybody would just use their favorite little language because now that choice didn't matter but of course people have to still read source code and then cooperate with that and it has to be training and so on so yeah it doesn't really solve it didn't give sort of

 

Yeah, I'm thinking another downside to monolithic applications is that tech debt issue. When you look back and you look at, okay, what's it going to take to modernize this application and bring it up into, say you're using the older.NET framework, the full framework? So I have applications using.net web farms. Well, I can't bring that up into.net core or.net five, six or seven because it doesn't, it's not compatible. So now I have all this tech debt there and because it was pretty much a monolithic application, the amount of work it's going to take to actually update it. It's like, I can't do it very easily piece by piece.

 

Yeah, that's an excellent point. I don't think I mentioned that in anything of the articles I wrote, but that is definitely one of my sort of pet's PVs. I've been fretting a lot about that particular point. Because I work, as I said, I work on really old software from the 1990s. And I thought, we really need to modernize this stuff. three million line C++ application where that's all tangled up. If it had been modularized from the start with regular communication interfaces, whether those had been, I don't know, kind of UNIX pipes or socket communication or something like that, then you could have If it was a small manageable application, I could have rewritten to Rust or Go or whatever modern new language or technology and the rest could have just stained C++ and you don't have that choice right now with a big model like Salthur. Then you would have to do a major refactoring which is But yeah, it really gets you stuck on an old technology stack for sure and that's really been on my mind a lot. I thought about that all the time when I was working in the software. If only we had been modularized, we could have changed some of these pieces. And yeah, you could do so many things then, right? You could even write in some kind of script language. It's possible. The other thing, and I noticed this in a company I worked with later, which I did very modularized software development, and I thought it was really neat to see how that played out, because applications are much smaller. You could, each individual piece is much more well-defined. These are the inputs, these are the outputs. you know, for native developers, it's a big thing, right? It's kind of a simulator for code, and it can catch kind of illegal memory access and all these different things. But it works really bad for very large applications, right? Because you're running a simulator, and you get two big performance problems. But so I would rarely use it when I was working on this huge monolithic software, because it was so slow and painful to use. when I was in this new company where they were building much more modularized software. Each little module was very easy to load up and test. And so, you know, the ability to do proper testing and really use a much richer variety of testing tools suddenly become much more, you know, easier to achieve. So yeah, if you go modular, there's just so many advantages, you know, making your testing tools, yeah, so much, so many benefits.

 

So what's the solution? Is microservices the solution? I think to me, microservices is kind of the hot technology of today. And in a few years, there's going to be something else that people say, no,

 

Bye.

 

microservices wasn't that great.

 

Yeah, isn't the problem with... the silver bullet thinking. I remember, so I was kind of in the early part in this oil business with all this scrum and lean thinking, and I remember reading about that and as we were kind of introducing it, thinking, ah, this is such a great idea. So, and I really believe in iterative development. This is what happens with microservices as well, probably. Certainly seen that with pretty much any technology trend. Is that what starts out being just advise and good rules of thumb and philosophies, they turn into something akin to scripture. You know, now they're not suggestions, they're commandments. So, you know, you're doing scrum and you decide, well, it would be more practical for us to do runs in, I don't know, three weeks or four weeks. And somebody comes in and says like, no, that's against the scrum rule. Like it has to be two weeks. That's the perfect and the most optimal in what the prophet says. And so many things get, behind things, you know, is lost. It becomes more important to follow very particular rules than to actually do something sensible. And I don't know whether microservices is well enough, but just kind of following from the sideline and looking at the discussion and sometimes reading articles, I get the impression that there's a little bit of that element there where things have gone wrong, people instead of trying to approach it in a pragmatic sense, they turn it into scripture, a holy scripture, where you know there's these things you have to do. I've seen that with a stark example of that is our member reading that's, there was this, I'm not sure if you remember the code smells, but I don't remember the author, I'm very bad with names, but there was a thing about different code code comments. And I think that in this original writing, it made sense, right? There's a lot of comments about some code. That suggests that probably you should look into, maybe you know you didn't write this code very cleanly or nicely if you need to write so many comments. But it seems like people have When it's really about the code, right, it's not the comments that's bad, it's just the fact that you needed to write comments might suggest that your code isn't so great. And so I had experience with, I quite liked the sort of document and write, you know, my code because I feel that code says something about how something is done and works. It doesn't say why it's like that. And I think that's where comments are useful. code that I written and he deliberately removed all the comments because he's like that's a code smell comments is a code smell you got remove it's like do you know what a code smell was supposed to mean

 

Ha ha

 

it's

 

ha!

 

not it doesn't mean they're bad it's just to mean it's just for you to stop and think and I don't know I feel like that's the that kind of thing just happens too much people just rule. I don't know, maybe there's

 

Yeah.

 

a reason authoritarianism is sort of often keeps having appeal to people at all ages.

 

Yeah, I'm with you there. I really think comments should be the why, not the what. The code

 

Yeah.

 

is the what. If you write self-documenting code, that's the what. And because quite often a comment that explains what can be wrong compared to what the code is actually doing. So, but if I have to put something in code off, then I'll put a comment in there of why I had to put it that way.

 

Yeah, and I've seen that, I'm not sure what you thought, but when you're taking over projects, it's very frustrating and you see all this very strange technical choices and you're wondering, well, why are we those choices made? And you don't know, right? Because people don't write comments or anything. Yeah, it's become this sort of, oh no, you're not supposed to do that Yeah, but I don't know why they, you know, I remember having a project that I took over and they were doing a multi-threaded verification of whether a text field contained an email address. And I kept debugging those crazy race conditions and I kept debugging and I, you know, midway ended spending hours on this stuff. we need to be this complex large multi-threaded thing to just check if this is a valid email. Like, how hard is that? And I just threw out the whole library and just wrote a regular expression and I was done in a fraction of the time that I had already spent debugging all the race conditions. So, you know, I just realized, yeah, sometimes people just do weird stuff. I see There's a propensity now in modern software development, I think, and here I feel like I'm the old school guy, is new guys are like, oh, I have a problem, I gotta find a library for that. So instead of thinking, you know, what are the fundamental issues you're trying to solve? People are just like, oh, I'll just download a 20 megabyte library that does a dozen things and one of those dozen things is the one little thing I happen to need to know, which is my, I don't know, email verification or something. that in iOS applications, right, they are their single user that simplifies things a lot. And yet people are thinking as if they're building a big multi-user web application. So you would have, I remember I had a case where it was just reading and writing about to read that, that can load just partial parts of the object graph into memory so that it can deal with very large amounts of memory. And the glue code for all of that was more than when I just threw all that out and replaced it with just some simple standard file reading and writing code. You know, just read a regular file. Why do they put this, in the beginning also, I thought there's a reason they put this big object graph database thing in there. They eventually just realized like, no, there wasn't a reason. It's just how software development works today. People just grab the biggest, coolest piece of software to solve whatever tiny little problem they have. Now you got a maintenance nightmare afterwards because that tiny little, is now his huge thing with 20 dependencies to all sorts of large projects. So, yeah, there's a little bit of my grumpy

 

Yeah.

 

ranting there.

 

Yeah, not a problem. So is there anything else that you'd like to go over before we wrap up?

 

Uh... No, not about, I guess, this topic I, you mentioned like, If there's like other, you know, what's, you know, other interests or something like that. I don't know.

 

Yeah, okay. So I guess we'll move on to picks then. And my pick this week is gonna be the latest season of The Mandalorian. So yeah,

 

Oh.

 

that's been out. I think we've got three episodes of The Mandalorian out now. Some people are saying it's not as good as the first couple seasons, things like that, but I think it's building. I think it'll get better as the season goes along. My wife tends to really like the show. you know, Grugu. So we'd like to see him be a little more involved. He hasn't done a whole lot so far this season, but if you didn't know that the latest season was out, definitely check out the season three of the Mandalorian.

 

I haven't watched any of this stuff. I've been thinking about watching Andor actually. Just because I... yeah, it looked like kind of different kind of Star Wars, something that would appeal to me. Yeah, I haven't actually... I watched a lot of TV shows, but now lately, art. I've been very fascinated by how that works. I was, I got into trying like chat GPD and stuff like that at first, because I do writing and I thought this is going to either going to make me obsolete or it's going to accelerate my workflow. And I felt like it didn't really do any of those things. I do think that the code pilot is very kind of has high potential. I just don't think it's really helping me for that

 

Well, there's

 

thing.

 

a

 

But

 

new version that just came

 

I,

 

out this week, so chat JPD4.

 

yeah, yeah, I gotta try that out. Have you tried that

 

No,

 

yet?

 

I watched a couple of videos. Guy on YouTube was just used it to throw together some code, and it was vastly improved from what version three was. So

 

Oh

 

he

 

man,

 

basically

 

so

 

just

 

we are...

 

asked it to write code to do such and such and such and such. And for the most part, it did the best practice way of building these things. his YouTube channels and things like that for doing.NET development and C sharp. So he did one on the latest version of chat GPT.

 

Yeah, I guess, yeah. I guess one of my, I'm not sure what you're thinking about is that, but I feel the AI stuff is impressive, but they're kind of like a new tool and you need to master this tool like any other tool. There's a particular way of using it. So I noticed that with AIR, for instance, that I got into this about two or three weeks ago and I've been doing a lot of it. And I noticed that, you know, I'm way better at it now was then. But it's definitely a skill to develop, right? You need to understand how to communicate with the tool and how. So there's a way in like the limitations that exist for AI. And I think this AI art is very similar to chat GPT, I think, in the sense that they both can create stunningly impressive stuff that you think like regular people typically can. And think they're more impressed than they are and then you see like oh they just totally screw up this kind of pretty simple thing for a human. They kind of screw up in a little bit sort of this unexpected odd ways that you might not have thought about like AI art for instance. It's really bad at making hands. It just makes horror hands. That's just kind of this weird thing that everybody it starts to know. But

 

So

 

there's

 

is there a

 

other

 

generator,

 

things.

 

AIR generator that you're liking now?

 

Yes, I'm using stable diffusion because that's what's open source and there's a whole ecosystem. It's almost like Linux in a way, you know, like people build all sorts of stuff around it. People take, right, they have to be trained right with a model that contains all the weights for the neural network. fusion model and then they can train that further on more images to specialize in on particular types of image creation. So you might want to make armor, and so you just train it on a bunch of armor, and now you can create all sorts of cool looking armor. So I got into this originally because I was interested in making game assets. And you can input a variety of, say, you have different units in a game or something, or you can input, you can train a model on that. And then you can specify, you know, I want some new units this or that way. And it's gonna make it in some kind of a style recognizable because you're using a specialized model. So, yeah, it helps having this kind of ecosystem. People make ads, all sorts of ads on to it.

 

Yeah, you mentioned hard time doing hands. I've been trying to use some AI upscaling for videos to, you know, redo some old videotapes and things like that that I have. And it does not do a great job at faces.

 

Ah, yeah. There are special, yeah, you have problems with that typically, but there's typically ability to use special face fix up software. So they developed, there's been software earlier before AIR, that was developed to just clean up faces. And so people would often just do that, they'll get a sort of decent image up afterwards on that. Well, I think maybe there's integrated. But yeah, I guess it's probably that's how it's gonna go. Eventually with a lot of these things, you have a specialized tools for each thing. So you can be, okay, do the hand fix up here, do the face fix up there, you know, stuff like that. Maybe a chatGPT can have something similar. But I don't know, is that chatGPT, is that close source or can anybody fork it?

 

positive. But yeah. So yeah, I imagine that probably works better with static images, things like that versus video, what I'm trying to do.

 

Yeah,

 

So

 

that sounds very difficult.

 

yeah, especially if there's, you know, multiple faces within the same video. So yeah. Okay. So far, listeners have questions, or they want to reach out and get in touch with you. What's the best way to do that?

 

reach out to me. Well, I'm a lot on Twitter, so that's the kind of, I know there's people contacting me there.

 

Okay, what's your Twitter handle?

 

And I'm on, it should be, I think what's Eric, Eric Ingheim,

 

You

 

my

 

don't

 

whole

 

tweet

 

name.

 

yourself very much,

 

Sorry,

 

do

 

I

 

you?

 

don't really think about what my Twitter handle is, just, Yeah, it's my whole name, so that's Eric Engheim, and it's Eric with a K. I know for Americans, I think I consistently, when I write emails with people, I always get sort of like, hi Eric with a C.

 

Mm-hmm.

 

So yeah, it's a K, it's the Norwegian way. Yeah, Engheim probably, hard to screw up because you wouldn't know how to write it anyway without you seeing it. with a K E N G H E I M. That's my Twitter handle.

 

Okay, great. All right, and if our listeners want to reach out and get touched with me, they have feedback for the show, have something that we'd like to cover, they can reach me on Twitter, I am at.NET Superhero.

 

huh

 

Yeah, so thanks Eric. It was a great discussion

 

Thanks

 

about

 

for your time, John.

 

software and being in funny deadies and old stuff and bring back good memories

 

Yeah.

 

there.

 

Yeah. Yeah, that's cool.

 

All right, and we'll catch everybody else on the next episode of adventures in.net.