EXTENSIBILITY FIRST: Building .NET Systems That Survive Change with Miguel Castro [MVP]

Yeah, welcome back to the podcast. Today we are joining by someone who has spent decade with solving the kinds of software problems that most developers only encounter once or twice in a career. Miguel Castro is his new dot-net engineer, software architect, ConsulTown, at International Conference Speaker, and one of Microsoft's most respective morrisons in application architecture and invincibility design through his career. He built communication platform, cloud SDKs, AI powered voice transcription systems, automation platforms and enterprise applications that have powered business for years, especially is simply writing code.

It's designing systems that continue working as requirement evolved technologies, change and business grow. If you ever wonder why some enterprise applications become impossible to maintain, while other seems to evolve affordously today's conversation is for you. We explore extensibility software architecture, Azure AI automation, the weather approach, the clean design and what great architecture is often invisible. Miguel, welcome to the show.

Thank you, thank you. How could it be here? Thanks for having me. Yeah.

Where did your journey into software development begin? Oh boy. That would give away how old I am, wouldn't it? I don't know.

I don't know if we want to give away my age, but you have not. I got, I mean, I don't want to turn it into a really long story, though I do enjoy talking about it, but I've been programming since I was 12. So back in the days of, I mean, my first computer was a radio shak, TRS80, and then I went into a Atari 800 and then Apple and I come from those days, you know what I mean? What, or what attract you to adopt that?

Well, I've been in the Microsoft spaces for a very long time. I moved into the Microsoft spaces with VB, like most programmers do actually. When VB1 first came out a long time ago, I was just fascinated by the idea of drag and drop GUI design and putting events behind it, which was back then it was something new, of course. And it just became fascinating and I got into it like a lot of people that are listening right now, you know, you get into it as a hobby first and then it turns into a career.

Now, I was already doing computer programming outside of the Microsoft arena from '86 all the way to, I would guess '90, '89, '90, just before Microsoft entered the VB spaces. And so I was in new to programming and logic and stuff like that. But that was my gateway from my old world into the world of Microsoft and I've been in that world since then, I've never gone another direction. So I've progressed through the same way Microsoft has progressed this products.

I've, my career has progressed parallel with all the products that Microsoft kept releasing. >> Yeah, you stay a long time in enterprise software development. What is the difference from your starting and today? >> Well, we got a new competitor to deal with, of course, and it's got no face, unfortunately.

I'm talking about AI, of course. That's the primary reason today, like really currently today. But just over the years, you know, I would have to give that a lot of thought. Over the years, paradigms and software engineering techniques have just changed constantly as new technologies come out, new ways of doing things are brought into play.

So it's ever evolving, it always has been. I mean, I come from a time where something as simple as functions and subroutines were not around. Everything was top to bottom programming. And that, of course, changed radically as languages evolved to introduce more modularity.

And I just followed things along. And it's almost hard to remember how I was designing systems back then or applications. It is hard to remember, not just because I'm older, but and I'm sure a lot of developers out there will agree with the statement that no, you don't design a system or an application the same way every single time. As soon as you finish it, you immediately think of things that you would have done differently or better.

And then you say that for the next application, you know? - Yeah, and what, what actually makes it, makes for you a great software architecture? - Say again. - What actually makes a great software architecture for you?

What, when we think in modern times? Well, pretty much the topic that we're talking about today is the main one. I mean, there's other important topics. I mean, when you get into larger systems and you gotta do service to composition and break things apart in smaller portions and, you know, with the introduction of microservices and stuff, those are all things that are important in designing a system, but the extensibility aspect of it, to me is it's near and dear to my heart.

It's something that I got fascinated by and I'm more than willing to tell you when in a minute, but I got fascinated by when I first got introduced to that concept of plugins and modularity and stuff like that. And I think that is, to me, that's the foundation for a really well-architected system because once things are extensible, they become maintainable, they become readable. You know what I mean? There's a lot of words that end with able that follow along, so it's kind of at the top of my list.

- One thing a little bit about.net to develop on, okay? I can see three-year, three parts, three parts, I don't know, three different kinds of developers. Yeah, there is one, one they say, okay, we are the.

net developers, we develop something that's work. And there is all the other team, I say, tips, yeah. Writing a clean code team and designing a good system team. What is the different between writing clean code and designing a good system?

- One right on top of the other. I don't think you can write clean code without designing a good system first. I mean, to me, systems are made up of parts of components, which fits well into the world of AI today because you can actually spawn off some of that kind of writing to AI agents, but the, and I don't think AI agents actually write clean code to be honest with you. But that's the, I'm not sure if I understand the question entirely.

The difference between, repeat the question again for a second. - Yeah. What's the difference between writing clean code and designing a good system? - Yeah, you can, you can design a system without writing any code.

I mean, to me, the design part of a, of a project is, you know, architecture and design kind of in, they blend in together. I do all that before I eating write any code. I want to, I want to break it apart as much as I can into the proper layers and components and sections and things like that before I even write any code. That allows me to, when I get to the point of writing code, I'm writing smaller pieces which allow you to maintain clean, you know, a clean style much easier than if you're just, if you jump right into a system without proper design without architecture, everybody out listening is gonna agree.

You can start coding right away. And without a proper design, your code's not gonna end up clean. I don't care how good you are. It's just not gonna work out that way.

So, so the two things do have to, you know, it's gotta be a chicken before the egg or whatever that that saying is, you know, it's gotta, you gotta, you gotta, you gotta, you're a crawl before you walk is a better analogy. You know, do your, do your design and architecture first and then you can start, then it been writing, writing good code is gonna be easier. Now, of course, the, the, the, the, the, the, the, clean code is a very subjective term. What maybe being to me is not gonna be clean to you.

There are, there are certain objective things that are yes or no, this is clean or this is not, but, but it all comes down to style too. And programmers are very personal with their style and with the way they write code and what they consider clean code. And not to say that one is wrong, one is right, but it can become a very argumentative topic. When you talk one program to another, you know what I'm saying?

- Yeah, this is interesting. And I think a little bit about enterprise projects. What's the reason why they become difficult to maintain? - Oh, probably, if I had to nail, I mean, I'm sure there are many reasons and everybody's got their own reasons for it.

But if I had to nail one thing, it's probably that they're not designed in a way that allows enhancement and modification later in an easy way. And that's where the topic of extensibility comes in. At least this has been my experience in my career. When I encounter a system that is, that is tough to enhance and tough to maintain and modify, I don't throw my hands up in here and give up, but I'll throw my hands up in here and curse somebody out.

- And let me ask this a little bit different, but when you're joining existing project, what are the first warning signals that the architecture is in trouble? - Okay, the system does this that and the other. I don't like this part of it. What do I have to do to change this one little part of it?

That's a pretty general question, but that question I think is how I would nail your, the question is just ask me. It's, again, a looting to extensibility. If I find that it's just a pain in the ass to change something, if the answer that I get is, "Oh, we would have to rewrite all of that." That already raises a red flag on how this was designed and architected to begin with.

- Yeah, I think a lot of companies think development, it's a project. And I think in a little bit about can an architecture ever be finished? So there's just something, what's make a project? - Say repeat that again?

- Yeah, I think a little bit about companies. And companies are doing development and they treat it as a project. Can a chic texture ever be finished? So is it right thinking or is there wrong thinking that's of the development of them?

- Yes, yes and no. And that's always the tough question because there is such a thing as over-architecting, but in my opinion, in my experience through my career, everybody approaches it differently, like I said, it's a very personal way of doing things, but in my career architecture can evolve as well. I mean, you need to get a design and architecture of a software system to a certain point to get started on the coding, but that doesn't mean that you have to have the architecture and the design 100% done in order to start writing for it.

But a certain part of the architecture, how components are connected together and how things can be plugged in later, again, alluding to extensibility. I personally like to get that part done out of the way. And then as I start writing components for it, then as I start writing components for it, I may go back and revisit the architecture and there's nothing wrong with revisiting. If you do it step by, it's more of an agile way of doing it.

You know what I mean? Architecture's revisited just like component development is. - Yeah, I think a little bit about, so I'm more the 80% guy. I do the NBP and then I leave the project and let's do the 20% that's really take the 100% of time.

But how do you balance business deadlines against technical excellence? - How do I balance business again, say say that again? - Yeah, business deadlines against technical excellence. - Well then I'm sorry, my phone kept going off and I didn't, I'm gonna have to ask you to repeat that one more time.

- Yeah, yeah, no problem. How do you balance business deadlines against technical excellence? - Ha, ha, ha, deadlines, huh? I hate deadlines, I don't like deadlines.

- I work well with deadlines. I mean, I do all right. It's, you know, that's gonna be a case by case thing, man. It's gonna not only depend on what kind of architecture and design you put together, but it's gonna depend on the quality of your development staff and also the type of companies you work, people you work for.

I've worked for all types of bosses. Most of them have been very, very good, but I remember I was working for a company when I was living in Jersey that came around and told me that they were a very date oriented shop. Okay, I was, what exactly does that mean? That means when we see something we need to write, we set a date first just to when it needs to be done.

And everything is based on that. Okay, well, I don't know anything about the system yet. I don't know what to design, what target, how do all I know is that you want this by this date? That's all I know.

Well, that's just the way we work. That was the answer I got. So I can see excellence coming out of a project like that. It's just, it's a very case by case thing.

I'm not sure if that answers your question. Yeah, I am also not the design fan. Yeah, because, yeah, you got the MVP and then you have, it's running, but yeah, it's, but you know what, that's where having extensibility in mind comes very important because when I architect something, when I design, I notice I keep putting the word architect to design kind of together, just to me, they're almost intertwined. But when I architect the system, I always have extensibility and modularity at the forefront because as I do that, I can start writing things right away.

And if I start writing parts of it right away, I can deliver in an agile way. I can deliver in pieces, you know what I mean? You don't have to wait until the system is 100% and deliver it. The essence of agile itself means you're constantly going back and changing and refactoring and stuff like that, both from a development perspective, a business perspective.

So I don't, I think that deliveries and dates are much better managed when things are broken apart into stages, stages of delivery, just like we have stages of development. You know, in your case, you said you work on minimum viable products first, right? That's the way you attack the product. That's fine.

That to me is more of a proof of concept than anything else. I don't, and I don't like to take a proof of concept product or delivery and turn it into the product. I literally keep that as a proof of concept. It's a very quick and dirty thing that I would put together just to show the technologies and the functionalities that would be available in a full blown system.

You understand what I mean? Yeah. It's dangerous. I mean, I'm not criticizing you in any way, of course.

MVP, an MVP is definitely necessary. A minimum viable product is totally necessary in a lot of shots, like totally get that. But I do feel you got to be careful because I can't tell you how many times it's happened to me that I deliver an MVP or a POC, a proof of concept product. And the boss says, oh, well, that's very close to what we need.

So that means you can get the rent done in just a couple of weeks, right? No, it doesn't work that way. This is literally just a proof of concept. It just happens to look really good.

So, don't mistake it for a polished, finished product because it's not. I think especially in enterprise, and you have also other publics, like security and so on. Oh, God. And this is something you do.

It's like I called like a click dummy. And yeah, the guys or the sea level or the day they don't understand what happened and why do is it looks so fine and do is a little bit of work. But yeah, there's a lot of other stuff you have to do. How so?

Yeah, there's one of the biggest misconceptions. Yeah, the leadership have on software architecture. But what is the biggest misconceptions the developers have about software architecture from their perspective? The biggest misconceptions developers have about architecture?

I'm not really sure, never given a question like that, any kind of thought. I mean, I'm inclined to immediately say every, it's going to be different for everybody. I mean, my personal one, I don't know if it's a misconception. I mean, I have a pretty good idea of what I want in an architecture, what I want to see.

A lot of times, I just don't see that. So I'm not sure if I understand the root of the question or how to properly answer it. Yeah, then it's OK. I think a little bit about, yeah, I see, I have more to do with the leadership.

And I understand what misconceptions they have. Yeah, so I think it's called also be possible to develop ourselves some, yeah, misconceptions about software architecture, but, yeah, were not that that is fine. Well, I think when you're, when your team of architects, or when your architects is completely disconnected from the developers, when it's not the same person, see, I'm used to doing all the work myself. I've been a one-man shop for a very, very long time.

And I kind of like it that way. But I mean, I have worked on teams before. I've never worked on a team where the architecture is that separated from the development, enough to cause any kind of misconceptions. But I think I can see that happening if those two sides are very, very separated, because there's a lot of people that think that architecture is completely separated from the technology and it's not.

It's decoupled from the technology quite a bit, but it's not entirely separated. And I think there can be a big disconnect when you've got a team of architects or an architect that designs something that the tech stack that is going to be used to write it may not be able to handle, you know what I mean? Or maybe the staff or the skill level of the development staff think that'd be able to handle. And I think that could introduce clashes and misconceptions and things like that.

I think those two sides really need to stay in close communication as close as possible if they are not the same person. In my case, it's always been the same person. Or somebody that I've worked very, very closely with and continue will continue to work closely with on an ongoing basis. That communication line needs to be maintained open during the entire time.

I have a look a little bit about your publications and your writings. And there's one topic also we have in the headline. It's extensive extensibility. Why has extensibility become, I say one of your favorite, architectural, the topics?

Okay, so that's where the real, real nerd in me comes out, right? Because when I got started in .NET, this is obviously back in .NET 1.

0. And I was fascinated by the way web forms worked. Now before that, I was doing classic ASP, classic ASP development using Microsoft Transaction Server as the object broker. And then of course, a lot of eb6 components in the background.

And a classic ASP's got bbScript built into it or JavaScript built into it. And that's how you generate the HTML within it or make it as dynamic as we were able to make it back then. This was obviously before the days of XMLHTPP later to be known as Ajax. But when I got started in web forms, which was the web platform that ASP.

NET offered at that time, the only one. I took to it with a lot of, I liked it, I liked it quite a bit. I took to the concept of writing web controls quite easily and I was fascinated by it. That became a topic that I did a lot of speaking about and a lot of writing about is writing custom web controls.

And web controls are a point of extensibility because they're modular pieces of a web site or web page. Web controls don't have to be something as small as a text box and a label and a button. I was writing web controls that were full blown components, like little mini forms that can be plug and played into multiple different forms. And I found that fun, fascinating and fun.

And then later came ASP.NET. NBC. And I was very curious as to how that was going to differ.

And that was easy to learn. I was a seasoned programmer by then. I started researching and looking into exactly how that worked because it wrote on top of ASP.NET.

Right? Now at that point, I got a very clear understanding that ASP.NET does not equal web forms. ASP.

NET is the architecture and the framework on top of web forms. And when I started digging around and re-reversing engineering, a lot of the stuff in web forms and how web forms and NBC worked. It became very apparent that ASP.NET is the underlying architecture on both web forms and ASP.

NET. I mean, I mean, I mean, I mean, NBC. So then I researched until case how exactly does ASP.NET take a request, a URL and turn it into the eventual output, which is just a bunch of HTML, right?

There's a lot of things in the middle there. And that's where I learned the concept of a pipeline and plugging things into a pipeline. And in reverse engineering and reading and learning a lot about this stuff, I learned exactly how a request is step by step turned into a web page in web forms. And then I learned how that happens in NBC and all that happens on the same pipeline, on the same real railroad track, if you will, right?

And all Microsoft did was unplug some of the parts that turn a request into from a web form into HTML and plug in other things to handle the request and turn it into a web page using an NBC kind of architecture. And that, lining out how that worked was one of the most fascinating and enlightening moments that I had. I learned how to write HTTP modules and HTTP handlers and all that kind of stuff. And it just fascinated me and I just really got into how would I apply this same kind of technique, the same kind of architecture to another system, to something I can, if I'm designing something for a client, for a customer, that was always doing consulting.

And I got, that's how I got into it. And to this day, that's how I approach systems, you know, can I, maybe not literally a backbone like ASP.net, but a backbone and pipeline kind of, kind of mentality. How can I design the system where, you know, everything has to go from point A to point Z.

So to get from point A to point Z, what, what steps do I take and can I make these steps where I can remove one and put in another one, change the way something works, looks or behaves later on. And that's a very broad description, but I think you make it the point, you know what I mean? Writing modular stuff like that were, were if a client, to me, it became incredibly important after a delivery because I saw a client like the system I delivered. They have no idea how things work behind the cutters, of course.

They never do. But then they said, oh, this is very cool. But this little piece right here, can we change this to do this? And then I would turn around and have a change like that very, very quickly.

And of course, they would be very happy. And the work was easier for me because it would literally be just unplugging one part that I did and putting in something else and not changing any of the underlying architecture or frameworks that orchestrates the entire thing. And that, you know, that turned into just a really love for designing the extensible software. And I got into different kinds of extensibility patterns in, in, I even, I did a plural side course on developing extensible software where I go over several different patterns and, and give examples in everything.

And it just, it became a really cool way of writing systems because it not only was cool to deliver it and see the clients happy that I was able to deliver in minimal time and make changes in minimal time, but it was, it was rewarding for me. It actually bettered the way I write code and the way I architect it back to the clean code that you were talking about. I found myself writing cleaner code because now it was managing smaller parts of code. It's always easy to go clean when you're managing small, you know, and, and, and we'll just, it just, it just, I kept evolving, evolving from there.

And that's just the way that I do things today. Yeah, this was, was really, really good, really good overview. When you have to, to, to, expand the ability designed to explain in simple words as I told you, 12 year old boy, or girl, how will you explain it? Oh, boy, yeah, that's like, that's like asking JTPT to, to, to, to, to write the, show me the, the US declaration of independence or five year old can understand it, right?

Oh, no, but it took it to a good question. I never really thought about it like that because I'm used to talking to developers, not five year olds, but, but it's all, I mean, if I, if I, if I can change it, if I can introduce them to that world using analogies that they understand, I guess it would be building blocks. I give them building blocks, you know, build, build a castle out of these building blocks. They would build a castle for me.

And then I say, well, I don't, I don't like the top, the tower of that castle because the princess can't come out of the window. Um, change that, change that, the top of that tower. Well, they don't got to rewrite the entire, redo the entire castle. They just got to take the tower off and put a different kind of tower on it.

You know what I mean? Yeah. So that would be the best analogy I can give to, to a little, yeah. I, I, I, I love bricks and, uh, yeah, I understand the, uh, with my 12 year old mind.

In my, I'm, I'm a, I'm a big, I'm a big Lego fan. I build a lot of Legos. So in my world, that would be the equivalent of Lego, right? I don't like the way this, the front of this building comes out.

And I'm plugging and put something else on there. Yeah. Yeah. Yeah.

Uh, Lego is also, uh, it's also a great topic. But, but yeah. Um, it'll get me started, man. I can talk about Legos all day.

Guarantee that a woman will never talk to me again, of course. Yeah. Yeah. I have, by another, not, not Lego, but also bricks, uh, uh, uh, star destroyer for two weeks, my, my girlfriend also, not so willing to, to talk to me actually, um, if she's, we'll package with 20,000 bricks, but yeah.

Yeah. Yeah. The, the, the, it's, uh, yeah, when you, when you get a nerd, you get a nerd. Yeah.

Um, when, when, uh, shoulders develop a design for extension and, and they're also, uh, cases when they should do it not or they should yet. I, I understood when she developed a design for, uh, repeat that again. Wanna make sure I get what you call it? Well, when she, when she'll develop our design for extensions and when she, they shouldn't, when they don't do it.

Um, I think that the size of the system is probably the best way to answer that question. You're not gonna, the more, the more the, the more time you spend on archord, when you design something for modularity and extensibility, it's gonna take a little more time and make no mistake about that. So if you want, if the system that you're eventually needing to deliver is very, very small, it's a quick and dirty application, you don't need to, it would be overengineering to, to go through through all the, all the, the, the thought, the thought process of how would I modularize this and make it extensible?

Um, it's small enough where it'd be easy to maintain. I think the size of the system is very relevant as, as, as, as, as it's, as it's clear that what has to be delivered is a large scale system. Um, then, then it becomes more important and then, you know, the minute you ask yourself the questions, okay, where do you see this changing in the future or being enhanced in the future? If there are several answers to that question, that's a give away that we need to put some thought into making sure this is a well designed, extensible and modular system.

Um, now you may not always get the honest answer to that question, because I'm sure a lot of developers out there having countered given a task by a boss and them saying, and if they ask, well, what about this case here? And then the answer is, I don't worry about that it only happens once a year. Well, to me, when something happens once a year, I got to count for it like if it happens every week. That's just the way I, I, I refuse to leave something out because it only happens once a year, because that once a year is going to be a pain in the ass when that comes back.

And if there's a lot of those things like that, then, then the modular and extensible design needs to be considered as early in the game as possible. So it's very relevant to, it's very, it's very related to the size of the system that you're putting together. Or, or, let me add to that, or what is the, what is the potential of this system, which is now very small, is just a little application right now, where do you see these, what do you see this going in the future? And again, the honesty of the answer is going to be very relevant because most of the time, you're not going to get an honest answer from a, from a boss because they just wanted to live it quickly.

But, you know, when they come back and say, or over that system, you designed six months ago, that little application, you know, the, the, the, the, the people that I gave to like it, they want to turn into this, this, and that. And now all of a sudden it just became something big. So those are the questions that, that, that I tend to ask. And like I said, I don't always get an honest response to it.

Yeah. You say design patterns. So which design patterns do you really most and which patterns are, I say, overused? Overused.

Well, as far as the, the first part of that question, the design patterns that, to me, in my design, in my type of, of development, most of the extensibility designs that I do all stem from a strategy pattern or something similar to the strategy pattern or something that is derived from it. To me, the strategy pattern is at the heart of embracing abstractions. The whole point of extensibility is to be able to plug one thing in and, and plug in another, plug in another one. And that kind of plug in mentality is only going to work if the backbone that you're plugging into is going to have the same interface, the same way of talking to an old component as it does to a new component.

And that's abstraction. And that's at the heart of the strategy pattern. That's, to me, that's at the heart of extensibility. Everything from there can, everything can progress from there.

There are other patterns like the chain of responsibility pattern, which is kind of at the, at the, the heart of that combined with strategy is at the heart of, of what I call the event, the external events pattern. A lot of people are probably questioning what the hell that I just mean by external events. Let me put it in a way that, that, that, that developers can't understand because it's a pattern that I actually love and I use quite a bit. It's not really one of the 23 golf patterns, but it's the exact same pattern that ASP.

NET uses when it writes, when it gives you HTTP modules. So the pattern, for those of you listening, if you're familiar with IH-GDP module and how to write an HTTP module, that's pretty much at the heart of how ASP.NET turns a request. Into a series of a bunch of HTML, whether it's in web forms or whether it's in NBC or whether it's in API.

You know, web, web API is the exact same pipeline as NBC and web forms. It starts with the request. The only difference is that it's delivering JSON data instead of HTML. So the different points on the railroad track are very different, but the interface behind the scenes is going to be the same.

Well, you know, I can, I can turn, I can give you a mini, a mini ASP.NET framework example. I can, I can deliver a mini one. It would be useless because of course I'd be rewriting the re-reabending the wheel, but I can, I can do a mini one to show you how something like that would work by using the same pattern that Microsoft use, which is the HTTP module pattern.

One of my favorite patterns. And I tend to use that quite a bit. The latest system that I just delivered to to my last customer, use that extensively. You know, if you wanted to write, if you wanted to write a plug-in for this system, here is the interface and the events.

And these are the kind of, these are the events you can tap into. And I call it the external event pattern because the host, the backbone system is going to be. Checking for events subscriber and calling an event, but the writing of that event comes from a plug-in that you add later in a different assembly, not from hard wired. Very strongly coupled event.

It's a very loosely coupled thing, which is why I tend to call it the external events. But that's that the, which, which that is a strategy pattern. Those are the main ones that I base things on. Everything is based on abstraction.

When it comes to extensibility and plug-ins and modules, it's all based on abstraction. If you're not familiar, I mean, if you're not comfortable with the concept of abstraction, it's something that you need to get comfortable with. Anybody that has done developer dependency injection understands abstraction very well because it's at the root of that. Awesome.

Yeah, we have a lot of buzzwords now, but can you a little bit, X, Barsport, what's the wrong word? But we have plug-ins, events, dependency injections and also interface. How did all this work together? Well, I mean, that'll depend on what you're putting together really.

I mean, dependency injection is based on the whole concept of abstraction, which in the world of dot net abstractions mean interfaces. They mean interfaces and abstract classes too, but primarily interfaces. So that's how DI works together with interfaces. It's based on that.

It's at its very root. Same thing with plug-ins. If I'm going to write a plug-in, I have to embrace the abstraction because my main system is going to be calling a plug-in and the whole idea of an extensible plug-in is that it doesn't know what that plug-in is going to do. It just knows what it has available to do.

The method in the properties that it has available to it and what the implementation behind the scenes is, it has no idea. That's at the very heart of doing modularity and extensibility. I think I might have answered your question or might have gone off on a different tangent. You tell me, did I address that properly?

Yeah, really, really good. I think a little bit about extensibility. Can you share an example where extensibility is safe and entry product? Yeah, let me see if I can think of a good one just recent.

One that's fresh in my head from the last system that I did. Let's see. Okay, you mentioned, and my intro, you mentioned the transcriber system that I wrote. I wrote it just to do live transcriptions.

Live transcriptions from phone calls in a call center. Literally, as the phone call is happening, they see the live transcription on the screen. We've all seen that on Zoom, Google Meet. They all have transcription, live transcription built into it.

But I had to do it on a custom system because this client had their own UI, their own that they used to manage the call center. It wasn't using anybody else's UI that had built in transcription. I had to do this myself and this was before AI was even around, to be honest with you. I learned how to use Microsoft's cognitive services to do a transcription.

I wrote a transcription system that worked beautifully. As it was used, let me correct that. As I was writing it, I tried to think ahead. Now, I went with this customer for 15 years, just one client.

So I got to know them very, very, excuse me. I got to know them very well and was able to always anticipate what I think they may be asking for in the future. Which, you normally, a lot of people can't do that with short-term customers. But I was with them, including myself, but I was with them for long enough where I kind of knew how they think.

And I was writing the system and a lot of things popped into my mind that as the transcription is coming through and the customer service agent is watching this happen and seeing the transcription between their customer and their own voice. I can see different things being asked for to make their job significantly simpler. The two that came to mind, the first one that came to mind is the ability to search the knowledge base, the company's knowledge base. And I knew that would eventually come up because in talking to some of the agents, they told me that that's actually one of the processes they use.

As they're talking to a customer, they're on another monitor searching the knowledge base, the company knowledge base, to see if that customer's problem has come up in the past and is there an immediate solution. So that was one thing. Later on, when AI came into play, we got the ability to use CHGPT. And I learned how to use the CHGPT API.

So think about it. You got two things now that can share the abstraction. So I think this is actually a pretty decent example. You got a conversation from a, you got two conversations, two streams.

You got the agent and you got the customer, right? Now I'm only interested in the customer conversation for the purposes of the answer to your question. So I got the customer explaining things over the phone and I'm transcribing this. So I have this in writing.

So I want to take this now and automatically send it somewhere for some kind of processing. Now think of, think of how abstract I just worded that. Okay. I want to send this transcript or would you send it to or whatever.

Part of this transcript, I want to send it somewhere for processing. And I want to have results of that processing come back so the agent can see it on another monitor or somewhere else on the screen. Well, that very abstract description is what I took into consideration when I was designing and writing the transcription system. Because later, much later, I was able to, to, what I did is that I put in a hook, in extensibility terms, we say hooks, I put in a hook so that I can put a plug in at this point later.

It's time that a, that a sentence or a couple of sentences came in on the customer stream. I would take the words of that sentence, the text and I would, I would very abstractly send that out somewhere. Now I didn't have any somewhere to send it out to, but that's what I was coding for. I'm in an abstract way.

I'm sending that part of the conversation somewhere that later on, I'm going to plug what that somewhere is. And I delivered the transcription system and it worked very nicely. Sure, shit, the, can I say that? Sure as hell, the customer came back, that my boss came back with, you know, how do we get the, the, the, the FAQ, the frequently asked questions, the knowledge base involved in this.

And I knew that was going to come up. So the first use that I had for that hook, that plug in point, that, that's all that hook is, is a plug in point, an extensibility point is I took those, that, that text that was coming little by little from the customer and I send it to the knowledge base and see what comes back. And if something came back, then I displayed it on the screen and the agent side, the customer service agent side, customer service representative, but the customer actually did not just the agent did.

So the agent was able to read, it results from a knowledge base in real time as the customer was speaking to them because of a plug in point that I, that I set aside ahead of time so that I can use for the knowledge base search later on. Later, I modified, or I added another extensibility plug in where I would send the customer text to chat GP and turn it into a question of source and see what comes back. So that's, that's kind of a rough overview on, on how I am, how I did implement it, something like that into one of my systems, but it worked out really, really well.

And you know, you put, you put a switch behind it, you can turn it off and on, right? So if, if the agent doesn't want to, doesn't want to, doesn't care about the knowledge base, they don't want, they don't want to see all this stuff come back. They just click it off. And now I'm no longer sending the text over, but I can turn it back on anytime.

Does that make sense? Yeah, it's made it makes, it's a really, really good explaining. I want also a little bit talk about enterprise platforms. You are designing SDKs, communication platforms, automation systems.

What, what do these projects begin? Where do the projects begin? Actually from a bad dream that the boss had. No, seriously, I mean, that's how it works, right?

I can't tell you how many things I've done for my, my customer over the 15 years that I've been with them, where I get approached with, you know, hey, this occurred to me last night. I thought about doing this in the nest. I'm not sure how we can do this, but it would be very, very cool. So figure out a way to do it.

And it was, it was a great job because of that. I was given a lot of freedom, a lot of leeway, but how to repeat the original question again. I want to make sure I, yeah, where do you start with or how do projects begin? This was my questions from, from that dreams from, from your, what, well, obviously the, the main question is, what exactly are you looking for?

But the one that I always, I twist that question into what do you envision doing when this is done and delivered and working perfectly? What is your, what is your vision? You know, I, if, if the customer can tell me, I'd like to be able to come in and do this and have this return to me. And this is the ideal situation.

That, that's, that's a primary thing because I dig deeper from that point. I don't like to, I don't like to start any kind of application design or architecture without knowing what the, the desired result from a customer's perspective is, because that can, that can lead to mistakes. The latest thing that I did for my, for my company was automate a series of manual accounting processes that would occur at 430 in the morning. And they were all done manually.

And it would have to be done that early because it has to be done when bank information on credit cards and checks comes in and has to be done by a certain time. So that was the time that they would do it at 430 in the morning. And they were looking for a way to, to automate this. So I asked that question, what do you, you know, what do you envision in an ideal situation?

What, what are you looking to happen? Obviously, the first answer was, we don't want to get up at 430 in the morning anymore. So now, okay, now let me, let me walk, walk me through what the manual process is. And that's actually very key when I design something, especially when I'm doing automation.

Look me in detail as much as you can, what the manual process to doing this. So I can get a good understanding on how I'm going to automate it. If, if something can be done manually, more often than not, I can have it done automatically. It's, it's, I know, I know that's very vague and it's very broad.

But that's at the end's essence of what I, what I ask when I'm getting ready to design a new project. What are you looking for? What is your ideal outcome of what you would like to see when all this is done? If this was done tomorrow, how do you envision yourself using it?

And then now walk me through how do you do it now? Because that will allow me to isolate possible ways that you could be doing it better. Not to tell somebody how to do their job when it's outside the realm of computers, but, but it, it, it helps me understand things step by step. So then when I go into automating it, I know exactly what I'm getting into and what, what, what, what things I have to look for.

You know, a good, a good analogy to this that's not in the world of, of.net. And, and I deal with this all the time is I, I have a Tesla and my Tesla here in the States were allowed to use full self drive. I know that you in Stockholm or not, which, which, you have no idea what you're missing then because you get, you get it.

It's like, I have a chauffeur. Yeah, it's true. But, you know, you always, people that get into my car and they, and they, they, they get fascinated by how well this works and they ask me how it works. Now, I can't tell you exactly how full self drive works step by step, but I can, I can, I can generalize how I would approach it.

Now, I'm in nowhere near qualified to write something like, like, a, like a, a, a, a, a, a, a full self drive for, for a vehicle that's going to go out on the road. But think about it when you're, when you're doing something when you're, when you're driving, you know, you got to get from here to there and what decision tree are you going to undertake? What decision point are you going to undertake to get from here to there? How, like, I just changed lanes.

What made me change that lane? Well, I looked to my left and I noticed it was clear and it was clear up ahead of me so I changed left. Okay, right, that down. That's what an automated system is going to do.

You know, I, that, that, I stopped at that red light. Why did I stop at that red light? Well, because I saw the light and it turned red and I stopped because I know that's the law. Well, I write that down.

That's what my automation system is going to do. And that's in a very, very simplistic way. What a full self drive system like Tesla or Waymo or any of those are doing. They're making decisions, you know, based on the, the possible, the, based on what, what do they got to do to make that decision?

You got to look around and see what's around and then take it from there step by step. Obviously, we look at one direction at a time where a car like mine looks at nine different directions at a time. So things are done much faster. But, but that, that kind of decision making, you know, what, what does, what will it take to get from A to Z in your system and your system or whatever?

Give me as much detail as you can so that I can try to design at that point or duplicate from there in a more automated fashion. And that's, that's typically my approach to something. Some client like that, a lot of people do not, they're like, well, why do I got to spend this amount of time with you? That's what we hired you for.

Well, no, you really want me to take this into my own hands and decide how you're going to do it. The whole point of you hiring me is that I want to do it the way you want, you know what I mean? I'll write it the way I want, but I want the outcome, the, the end game to be what you are looking for. Yeah, awesome.

So for this, this was really, really, really great session. And I think we have to do another session because for another topics. This was really, really, I really enjoy it. And let's jump into the rapid fire round.

I only give you short questions and you give a short answer. Okay. All right. I just want to make sure that everybody out there knows that I have no idea what you're going to say.

No, no, however, you're going to completely, you're going to completely take me by surprise here. And I know I'm not going to like it, but go ahead. Rest or graph QL. Say that again.

Rest or graph QL. I would say rest because I am not a graph QL person. I've had minimum exposure to graph QL. It's cool.

I kind of bring back memories of the old O data days. Remember, O data. In rest, we have O data in Microsoft. Graph QL reminds me of that because you can do queering and everything right from a request.

But I'm much more comfortable in standard rest. As most that net people are, I believe. The clean architecture or vertical slice. Say that again.

Clean architecture or vertical slice. I don't think the two are mutually exclusive. I think a clean architecture can result in many vertical slices. Okay.

As a function or containers. Functions or containers. Or you said as your functions. Yeah.

I'll come to complete a different things though. I mean, containers can contain full blown apps. Azure functions are just that. They're smaller functions to do whether it's a job of a microservice or an even smaller job in that.

A C# feature you call live about. A C# feature I cannot live without. I can't believe that I'm going to say this because I didn't feel this way at the beginning, but I've gotten very, very accustomed to making async code much easier because I used to be a big user of the begin and pattern in the old days. My very first magazine article was written about the begin and pattern.

And of course, async await replaced all of that. And at first, I was trying to figure out, okay, is this being overused? Am I using it in the right place? And now most most things that I do are going to be a sync enabled in one way or another.

So if I have to give you one answer, it would probably be that without getting it more quiet. Most underrated. That feature. Most underrated.

Yeah. Most. Most of the read. And that feature extension methods.

Okay. Tap source spaces. We'll see that again. Depths or spaces.

What's the first word? I heard spaces. What's the word? Depths or spaces.

Taps TPS. Yeah. I'm not sure I know what that is. Okay.

That movie. What's your favorite drink when you're coding? My favorite what? Favorite drink when you're coding coffee and the drink.

Actually, I have it right in front of me right now. The only soda I drink is, I don't drink anything with Asperatee in it. So I drink a diet soda from a company here in the states called Zavia, which is sweetened with a natural herb sweetened called Stavia. I don't know how popular that is overseas, but that's what I'm that in water to be honest with you.

I'm a one cup of coffee per day person. I've never been a huge coffee drinker. I drink it because I have a physical addiction to caffeine and I'll get a headache if I don't have one cup a day. I coding yes or no.

Now I'm going to say yes and I don't know how controversy that answer is going to be. Can I elaborate on that answer a little bit? Can you do more detail? So I was one of those that at the beginning was not really worried that AI is going to replace my job because I've been doing this for 40 years.

But it's just gotten really, really good, really, really good. And I've now taken the stance that, you know, if you can't, if you can't beat it, join it, right? I don't fight with AI anymore, but I use it. I use it extensively.

And I think that AI still can't fully design or architect the system based on client requirements of the way I could or the way a human can. But once you've got all that architecture, things that we spoke of during the last hour out of the way, doing the component part of it, the small pieces of it, I have no problem farming that out to AI just in the interest of getting it done quickly. I try to keep the, I try to keep the requests of AI that are going to be code oriented as small as possible because it maintain, it keeps things maintainable and it gives me less to check over because I still have to check a lot of stuff over.

I find AI making a lot of mistakes here and there. So I still want to check it over. But if I can put components together quickly, I'm all for it. Who wouldn't be all for it?

I think you'd be a fool to fight that and to do it yourself because once a client, once a customer or a company catch wind of the fact that I could have done this a lot faster, they're going to question why I took the slow route. And I don't want that to come into question. So I'm for it now. If it's done the right way, if it's used the right way, I am in favor of it.

Awesome. Yeah, then I say, we go, thank you so much for joining me today. I think, yeah, I had so much more questions, but we are a little bit running out of time. But I think it was extreme good overview, especially once the topic about great architect architecture and accessibility.

Access, it's not errors. It's so hot today. Yeah. So I would say thank you and all the, yeah, all the listeners find your links and info in the show notes and yeah, have a great day.

Let me just give one last piece of information for those that are listening. I did a plural side course called Developing Extensible Software that I think of all the courses that I did. It's the one that is most relevant today. In the plural site in their infinite wisdom, and I use that very sarcastically, has retired the course.

They've retired all my courses because they feel that they're dated. This particular course, I don't feel it's dated because it's architecture based. So how could it be dated? But even retired courses are still available on plural site.

They just don't come up in the immediate list. But if anybody has a plural site subscription in the search my name, the course you're looking for is called Developing Extensible Software. And I think you'll find it quite enjoyable. It was a lot of fun to put together.

And it will, it will give you a lot of details into the stuff that we've talked about today. Yeah. Awesome. Yeah.

Then normally I give you the last words. Those are my last words, man. Thank you everybody for listening. Yeah.

Thank you so much for spending your time with me and yeah, have a great rest day. Thank you. You got it. Bye.