How'd you like to listen to dot net rocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month, we'll get you that and a special dot net rocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey guess what, it's dot need rocks. I'm Carl Franklin.
And I'm Richard Gamble.
Steve Smith is with us. We'll be joining him in a minute, but first, you got doggy duty today, Richard.
Eh, yeah, yeah, you know, just timing. I'm about to go away for several weeks to Australia and we and she, who must be obeyed, wants to see the granddaughter, so she's off for the day, which means I'm taking care of the puppy, although I have run the puppy out and she is crashed out in the in the kennel at the moment. So hopefully no interruptions during recording. Well, not that anybody will hear them, because editing.
He well, or if it's cute, we leave it in.
There's nothing cute about p on the floor.
No, okay, all right, well let's get started with better no framework.
Awesome, man, what do you got?
This came from Simon Cropp, our good friend, in the app Phoenix Slack channel.
What are the appears?
Yeah, and this is a learn article at Microsoft. Wow, Jason serializer options.
Wait wait wait wait wait are you talking about framework stuff? Yes, on a better no framework. Absolutely, I am shocked. It's been a while. Huh, it's been a while.
So this is Jason's serializers dot respect nullible annotations.
Oh my god.
So use that in your serializer settings. Turn it, set it to true, and it helps find bugs when the nullibility annotations in dot net serialization contracts don't match what's on the wire, as in, we will get a failure during serialization and de serialization instead of a null refight after serialization or de serialization.
Which is better in every way, right, so much better. Oh my goodness, that's just the longest name ever. Except that is exactly what you want, thank goodness for till it says.
Yeah, And it doesn't look like it's true by default, but it says in the doc it is recommended that new applications always set this property to true, right, but it's not true by default in combination with a closely related respect required constructor parameters property.
Nice.
Look, it's a new option explicit in twenty twenty five. What's that about.
Respect, my authority.
Respect my nobilitybility. No, that totally makes sense. I want this on all the time. You said I have to remember it.
I am sad that I have to remember it too, but.
Have also you know what, They're also got an app or two out there that jump through great hoops to deal with nulls when I didn't have this capability and now I don't want to fix them.
Yeah, it's a noble world. We're just living in it. We're just trying to ever. Oh man, that's great. So who's talking to us today?
Richard Campbell grab to comment off of a show nineteen thirty nine, which we did back in February with our friend Jerry M. Miller talking a bit about vertical slice architecture No and hanging with Steve Smith means we're probably going to go down the architecture pop. There's a bunch of good comments on that show, by the way, a lot of them talking about the bus factor, as in what happens when your developer gets hit by a bus.
But I'm not going to go there, right, I'm going to talk about the comment from an NDDCC, but let's just call him ND Regarding Richard's concern about code duplication in the vertical slice, Yeah, in my opinion, preemptively preventing cod duplication is prevented premature optimization. I thought about this one for a while, and I'm like, you know, okay, yeah, fine, And as the saying goes, with all premature optimization, it is the root of all.
Evil if you don't need it.
And then goes on to say, also with vertical slice and functional style, who knew that transaction script was gaining popularity over the main model? Like what goes around comes around in d right, like just writing the procedures for the things we need also hip, But I think part of that is because our tooling's gotten so better to refractor.
Like even the code duplication part, I'm willing to give on because it's just not that hard to day to recognize, Hey, this is duplicated code in a few spots, and maybe I do need to optimize it now. But he finishes up by saying, simplicity over chasing dependencies and trying to cramb it, all of it, all of it in your head. Legit. Keep it as simple as you need to, but change it when you have to. Boy, that seems like a
setup for a show. I think it's I think I can Steve see Steve's wheels durning right now.
I thought I smelled smoke.
There you go, so Indy, thank you so much for your commented. A copy of music Go Buy is on its way to you. And if you'd like a copy of music code I read a comment on the website at dot NetRocks dot com or on the facebooks. We publish every show there, and if you comment there and e reading the show, we'll send you a copy of music Go Buy.
And you can get music to code by any time you want by going to music too code buy dot net. That's a URL trick, so don't put an hdtps on it.
Nineteen forty nine.
Nineteen forty nine, let's talk about it.
So.
Major events included the establishment of the People's Republic of China.
Yeah, at the end of the Cino War, Yeah.
Signing of the North Atlantic Treaty in NATO, and the Soviet Union's first atomic bomb tests, all contributing to the escalation of the Cold War.
Ah.
Yes, Klaus Fuchs leaking, you know, part of the Manhattan Project. You know, was a phenomenal physicist, did all these great things. Only remember for one thing, leaking the information on the plutonium bomb to the Soviet Yeah.
Well, anyway, the Berlin Airlift concluded. The first televised presidential inauguration took place here in the US. We experienced a recession in nineteen forty nine, with the unemployment rate reaching a peak of seven point nine percent. Also, nineteen eighty four, Georgia Orwell's dystopian novel was published. And anything you want to add to that.
Richard IBM ships their first punch card computer. Wow, the IBMCPC so along with punch card controllers and all this other good stuff. It was a big machine. It's called the IBM, Well called the CBC, but it was actually the sixth.
Or I love talking to boomers about programming with punch cards. We had to use punch kin.
You had a stack like this, yep, and Heaven help you if you drop it. Yeah, you sort all those cards out again, like, oh, you had a bug, you know, but it was you know, we also talked about the Manchester Baby, and of course of mind sition mark one comes out around there, which was the stored programming model as opposed to the punch card program model, where literally just reading the code and executing it, you know, essentially
the storage is in the card. So these were the competing some of the competing designs before we get to a place where we actually have dense storage, because we still don't, every bit of memory is super important.
I have never seen punch cards, but I would hope that they were numbered sequentially.
They are, but you have to number them. And they also say do not fold, spindle or mutilate, right.
I remember that. I actually do remember taking tests in grammar school that were not so much punch cards, but they were you know, filling the ovals, right, and that was definitely do not fold, spindle or mutilate.
You know, fold spindle or mutilate. One more science piece. Will of Libby publishes his paper in forty nine on radio carbon dating WOW, which is the method of measuring the age of typically biological things that have carbon fourteen. While while a plant is living, it actually maintains a certain level of carbon fourteen, and at the moment that plant dies because it gets eaten or anything like that, that carbon and fourteen starts to decay away.
At a constant rate.
And you can measure the ratio of twelve to fourteen to praiirly accurately estimated an age up to about fifty thousand year.
Yeah, very good.
He won the Nobel Prize in nineteen sixty four.
It's very cool. Yeah, all right, Well with that, let's bring Steve on again for the how many time.
I got to count because it's a lot.
It's close to twenty. I think it's like nineteen or something.
I think you think you're up there?
Yeah, wow, I got them all here, one, two, three, seventy.
Yeah, if you include the panels, it's I think this is number nineteen.
Yeah, she's a.
Though, going back to two thousand and seven, so you know, twenty years worth.
Wow. Well, let me read his bio here. Our Dallas is his handle Everywhere is an entrepreneur and software developer with a passion for building quality software as effectively as possible. He's published several courses on plural site in dome Train covering DDD solid design patterns and software architecture. He's a microsoftsp Net MVP and insider, frequent speaker developer conferences, an author,
and a trainer. Steve works with companies through his company, Nimble Pros, and they help teams who want to avoid the trap of technical debt to deliver better software faster. Our Dallas and his team have been described by clients as a force multiplier amplifying the value of existing development teams. His client list includes Microsoft Quick and Loans, WWF and many other satisfied customers. Now is that the World Wildlife Fund or the wrestling It's the WWF. Okay, the World Wildlife Fund.
I think Worldwidelife Fund won that one, and now the wrestling guys are wwe Yeah.
The Windows Workflow Framework also lost that. Our foundation sorry worklow.
Foundation workflow floudation. Yeah, you don't want to you don't want to dip into that fight. You're not even close.
So what's up? What have you been doing?
Just still working on helping clients write better code. A lot of a lot of architecture stuff these days. Working with clients have legacy code they're trying to bring forward from legacy MVC, some even web forms, but seeing less of that these days most folks are either in the cloud or still trying to get to the cloud and using that effectively. And that's a lot of who our
clients are and who we're helping. Starting to see some more greenfield application requests too, and that that's been fun, so you know, it's keeping us busy.
Do you buy my conversation with ND on that comment, basically saying, hey, no, I totally get it that you can swing back towards that sort of transactional mindset to build pieces of an app, don't you don't you know, definitely can overplan a domain model here, like getting tow functionals useful. At some point you're going to end up with a bunch of code you may want to consolidate into a domain model.
I think the key point there that I would drill into isn't so much domain model versus transactional script as don't repeat yourself or duplication is fine, because I think that's that's a balance, right, And most developers have heard don't repeat yourself or once and only once you know the dry principle, and they don't necessarily also realize that every time you eliminate duplication, you introduce coupling, sure, and
so you should be careful of that. I was reminded of a book that I contributed to along with the whole bunch of other authors called ninety seven Things Every Programmer Should Know from I don't know, ten years ago.
I love that it's ninety seven.
Yeah, there were a few of that series of ninety seven things books, right, But Kevilyn Henny put this one together and I contributed one thing, which was don't repeat yourself. And in the same book, Udi de Haan whom you guys know, also submitted one called Beware the Share and had a little, you know, cautionary tale about what happens if you just eliminate duplication wholeheartedly and without understanding the context, right,
and some of the problems you get there. So like in the same book there there's both both sides of the argument of why should you or shouldn't you repeat your code?
Right?
Yeah, you know, And I always if I was going to put one thing in that book, I would say, consider having the lowest ccf ever that you can possibly have, that is commented code factor. How long do you keep commented code in your code base before you should just remove it because you commented it, because probably you replaced it with something that something works, but you keep the comment did code in there.
You're saying, you're saying you want that to be as long as possible or as short as possible.
No, no, no, the factor as low as possible. In other words, don't litter. You know, once you've got the other code working, just get it, get it out. We have you know, we have version control for it. If you want to go back and see.
It, we have version control.
That's right, Yeah, just get it out.
Yeah. So on the duplication thing, like, you definitely can use duplication. Let's say you're doing vertical slice architecture and you want each slice to be independent and not have a lot of shared logic in between them, so that you don't accidentally break slice A while you're working on slice B and you change that bit of commonality and you know it breaks the other one. And so by duplicating it, you know, yay, they're independent from one another.
You can change them independently and they don't impact one another. But that's a trade off, and it depends, and everything has a trade off, and architecture and so the trade off that you're making is that, well, what if I really do need to change that everywhere? Right? You know, what if there really is just one rule for how we want to do this for this system, for this application,
for our business. Uh And and now I've got to make sure that if that that that rule changes that I have to go and touch everywhere that I've made that duplication and fix it everywhere.
Well, and when you break A because you modified for B, then you fix it by abstracting that shared method a little bit more, which makes it less clear for both users. Yes, yes, of it, you know, like it's it's this is iteration you get into. It's like maybe we should have split these.
Right, yeah, you have you have to be care and this is you know, fundamental software engineering, not even so much architecture is like code complete, you know level. How do you design a function? Right? If you have some common code and you and you extract it into a function, and let's say it's on you know, two different pages or API end points or whatever, and then later on, you know, the first one needs a little bit more, right, like, well, in this case, we need one more field, right, So
what do you do? Well, you just pass in a variable that says include extra data a bullion, and then you go into the function and you add an if check and say, well, if this bullion, then include the
extra stuff that that one needs. Right, And that persists and iterates a few times, and now that shared method is just a huge mess with all kinds of logic in it for trying to be everything for everyone, when in that type of scenario, there are a host of other ways you could have attacked that problem that wouldn't have resulted in that huge amount of complexity and dependency on that one shared function that you pulled out because duplication was.
Evil, right, m It's a great trap.
Yeah, And I mean refactoring is just a skill that we have to use constantly. I think in our profession an ideal you have tests to ensure you're not breaking things while you're refactoring. But you know, you should be prepared to be flexible, and you know, whatever decisions you made last week or last month or last year about what made sense, you know, be prepared to revisit those if you see that they no longer apply, they no
longer make sense. And you know, in this case that thing, you extract it out, maybe it's time to inline it and you know, duplicate it again in this case, you know, because things have changed.
Do we feel like the new tooling is getting and I'm thinking about the co pilots are going to help us with this, like I've yet to see it produce something like, hey, do you know this code is effectively duplicated a junior spatules. I don't think it's there yet.
I haven't seen that either. No. Probably if I if I took a whole bunch of my source code, put it into a single text file, passed it into a GPT model or copilot, and said, please tell me about where you see duplication, that might get it with the right prompt and with the right tokens to do that. But I don't see it volunteering that on its own, not yet anyway.
No, No, we're not there. But it is interesting to think in terms of is just less and less of a big deal just because the tools are going to help us deal with it either way.
I don't know. I think I think the issue is going to be the other way. I think all the quote unquote vibe code that's about to start happening, you know where folks are just you know, asking whatever AI tool to code them up whatever it is they need and copy pasting it into their code and compiling it until it works. I think that's going to result in a faster proliferation of duplicate code that no one wrote that came from.
Should we define vicoding just please? Because I don't think we've mentioned on the show yet.
Right, Yeah, that's the first time I've heard of it. But I get it.
Oh good, I'm glad you haven't because you're happier because of it.
Vibe programming.
Okay, so get this now. Look, Andre Carparthy is an important guy. This is the anthropic guy, like he's one of the big thinkers in the space. He got to kind of take him seriously. I think he really wanted this to come into being because he tried several times on different social media to come up different names. He did a whole bit about I'm programming in English now,
like that sort of thing. But the vibe coding term is the one that But it was this idea of, hey, what if you sit with a copilot, describe what you want, let it write the code, compile it, send it back the errors. Don't write any code yourself, just keep iterating where do you get to?
And don't even read the code. Don't even necessarily be able to read the code, right, this is coding for anyone.
Yeah, well that violates every fiber of my what I know to be true.
Yeah no, And I don't think he actually went that way, like he was specifically talking about developer should experience this, and it was like a weekend thing. Like I think it's been blown out from beyond what he was thinking about. It is an interesting exercise, say hey, on a Saturday, experimenting with a new language, as experienced developer, do this process and see where you get to. But it got
turned into programmers are obsolete. Anybody can do this, which is clearly not true because you have no ability to evaluate what you've created.
We were just talking with Vischwaz about this, and I've seen this in the wild that somebody uses chat GPT and says, can you show me how to write Oh, let's just pick a thread safe list collection, right, and it goes through all this you know, Oh, yes, well you're going to have to do this and you have to locks and this and that, and then at the end of it, you know, I saw that, and I just said, why don't why don't you just use a thread safe collection because one exists in the framework. Oh,
I didn't know that, right. So he didn't say I need to use a thread safe collection. What are the options? That's not what he prompted. He said, how do I write a thread safe collection object? So, yeah, there's a situation right there where you have to be a program. You have to be a program like that things out there. Yeah, or at least search for it, you know, the path go down. It takes experienced people to do this. You don't know what you don't know.
Yeah.
I got quoted at a press piece recently when someone asked me by this, where I said, you know, only people who don't know enough about programming to think they can use this would actually consider deploying that stuff. Yeah.
Looking at the definition of vibe coding, which is already on Wikipedia, apparently it was just introduced in February of twenty twenty five. Yeah, and it says a key part of the definition is that the user accepts code without full understanding, right. AI researcher Simon Wilson said, if an LLM wrote every line of your code, but you reviewed tested and understood it all. That's not vibe coding in my book. That's using an LLLM as a typing assistant.
Yeah, there you go. Yeah, like I said, it was taken from Andre's original idea and you turned into this complete madness. Not that I think it was all that good of an idea in the first place, but definitely it's been turned into something fairly see.
Yeah, but I don't think it's going to stop being popular, No, oh, without a doubt. And the trope of programmers are obsolete never gets old. Sure, sure, well, And the holy grail of you know, the fourth or fifth or NTHGL programming language, that is your natural spoken language English or whatever your language choice is. That's been you know, something we've been striving for for years. I mean, that's what basic was supposed to be.
I don't think we've ever been striving for. It just keeps coming up, keeps.
It's like, well, yes, you can certainly do that. You just have to, you know, describe in your natural language everything completely unambiguously so the machine can understand it, right, And you know, it turns out that starts to look a lot like a programming language.
Oddly enough, English being somewhat ambiguous because I both cut the tree down and cut it up.
Yeah, there's lots of those in the English language.
Yeah, I don't think the tools will save us from copy paste coding. And I think vibe coding is like a logical ancestor or ancestor logical child of copy paste coding, but worse because it's just got, you know, auto complete on steroids doing the copy pasting.
For you well, and remarkably language agnostics. So it's like, not only did I understand what I meant to do, but now doing the language I've never experienced, So what could go wrong? But the vibes are good, they are as long as you don't show it to anybody or let anybody run it. But I do appreciate as an experienced developer that I'm just feeling like my refractoring tools have gotten dramatically better. And it brings up this idea of going back to the comment here of yeah, let's
keep going down these transactional pathways for a while. As we get to a feature set that people start to care about, start to emerge the app that matters, knowing that the effort to clean that up into a better domain model has never been easier. That the tooling is going to help me make a better, more organized version of this application in less time.
It is true that the tooling has gotten better, for sure.
Yeah, I guess that's say, that's where I'm going with this, but that we don't have because I think the overar engineering of architecture is a problem.
It can be, It certainly can be. You know, I've got a client that I was working with recently that had a monolithic architecture and one hundred and twenty projects in the solution and just building it took forever, and trying to find anything in there. What just was was crazy. And this was a you know, a ten plus year old application, right, this didn't happen overnight. But like you know, it was a lot and a lot of it was abstractions and there were there were many, many, many projects
that had one interface in them. Wow, and then and then a separate project per implementation of that interface. I'm like, I like some abstraction. I like a little bit of architectural you know, structure. But that was a little bit much for me. Let me let me just say so, Yeah, it's it's always possible to go too far in one direction or the other. And I'm also not a big fan of my entire application is one text file, you know which it could be, right, but I don't.
Like any old days.
Yeah, I don't think just scrolling your mouse wheel is the only way to find code, and I think we have better IDs for that to be able to find things.
Speaking of IDEs Visual Studio versus Visual Studio Code, Fritz keeps wanting me to move over to Visual Studio code, and I just love Visual Studio, but I guess all the kids are using code now so, and Microsoft certainly seems like they're, you know, they're getting behind it a lot.
I still love Visual Studio. A bunch of folks on my team use Rider, a couple do use vs code. I like the fact that dot net coet Core allows us to easily move around between whatever tools we want and whatever os we want, So I think that competition overall is a good thing. Yeah. VS Code is definitely way faster, and it's still true that if I want to just open up a dot CS file to edit it real quick, yeah, I'm going to use Notepad or vs code way before I'm going to open that With Visual Studio.
Sure, yep.
Yeah, but it's sort of the acknowledgment that that software development is also project management, and Visual Studio has the project management. Although now with the do they call it the dot net ad in for Visual Studio code, you could at least see the project you have some concept.
Up, sure, yeah. And it has support for solutions and stuff in there now, yes, which is a little bit closer to what you get with Visual Studio. Yeah.
And I think that was necessary too, because there is a group of younger developers who never lived in idd Land. Like that was the biggest thing I saw, you know, in this contrast, most organizations I'm seeing is like at a certain age they've just never touched a visual studio and they don't want to. But they're still participating in a larger solution, and so code with the right ad in is they got to participate it, right. I hate to distract that by age, but it seems to be
the case. Like I just don't see any energy from Microsoft in recruiting new developers into Visual Studio, Like what's the path for a novice developer in a studio? Because my instinct is that that would be the logical place to go because all the bits are already there. Well, unlike studio code, where you have to compose the various bits into the environment you want. Yeah, the idea that here's it ready to go seems should be compelling. I just don't see any path forward.
Well, I love visual Studio, but then again, I have an I nine, you know, on my guest stop with about one hundred and twenty eight kicks of RAM, so it's past me. But you know, loading it in a vm H.
Well, in the visual part, I mean remember Visual Basic, Like that was the tool for like hobbyists and novice and people coming into programming to start, because it was drag and drop and it was visual and you could just double click on this button to make it do something. Visual studio today is much less about that, you know,
depending on what you're building. I mean, you could still the old wind forms up that way, right, but I think that a vast majority of people using visual Studio are not building wind forms, And the vast majority of those web developers don't have anything like a visual experience. They have a big editor and a bunch of other tools, but but no drag and drop since web forms.
So speaking of that last year, I did a project in vb net, a Windows forms project. Remember I was telling you how fast it is on my I nine. That thing managed to suck every CPU cycle out of my computer and make me wait for minutes before rendering. Minutes just making a ship, just doing a little thing, and like wait a minute, wait a minute, I go be right back.
I just like it when all the fans start to wind up. I got all these heat sensitive fans. Oh I clicked the wrong button because I can hear the fans just going up and go and go up.
The nuclear power plant down the road spins up. It's like the scene and the license.
Yeah, but certainly developing Blazer apps in visual studios just a joy.
Yeah, it's a joy.
I did try a couple of things in visual studio code recently. Fritz and I did a puzz in visual studio code. It's great. It's very colorful. You know, it's got lots of blinky lights.
It's more editor centric then yea. You know the problem with visual studio is it looks like the cockpit of a seven forty seven in there. Yeah, Like I wish there was better tooling for it, like turn off the stuff. I don't need to look at. I'm currently working on this, you know, web centric yeah, Azure app right, Like, there's a whole lot of buttons and toolbars and things that don't need to be there.
Even the most popular Windows applications I'm thinking of, the Adobe suite of applications has those modular windows that you can just turn on and turn off, and so they have the concept of workspaces where this window goes over here, and then the editor window down here.
That started docking undocking MDI thing in front really from Windows three for crying out loud, but it's never gone away.
Yeah.
Well Visual Studio has that capability too, But I see more doves that accidentally move a window and then can't figure out how to get it to redock, right. And I see folks using it intentionally where they have like a certain window layout while they're doing this task and then a different window layout when they're doing a different task.
Yeah, and you really want to have an undo on all of that. Again, I wonder if we could make better tooling to make this easier. It just make people unafree, because that's the thing is you get afraid to touch it.
Right, And we have templates for some things like project templates and things, but they're you know, used once at the start, and that's it. Imagine if you had some templates that folks could share, and you know, you watch some YouTuber and you see, oh, they're using that such and such template for how they laid things out.
I like that.
Let me just go grab it, just like you do with a visual studio code. Plug it today. You know, like that that layout could be something that was shared and used by the community.
Perhaps it seems like a good time take a break. We're about halfway in, so sit tight and we'll be back after these very important messages. Did you know you can easily migrate asp net web apps to Windows containers on Aws. Use the app to Container tool to containerize your iis websites and deploy to AWA managed container services with or without Kubernetes. Find out more about app to container at aws, dot Amazon dot Com, slash dot net,
slash Modernize. And we're back at dot NetRocks. I'm Carl Franklin. That's Richard Campbell either and that's Steve Smith, otherwise known as our Dallas Hey, and we're just keeping out over tooling Visual studio architecture. You know, whatever Steve wants to talk about.
Well, plus, I mean part of this is I want I'm always playing the act. I spent more time as an architect as developer anyway, right, I'm always playing the act of is my architecture impairing my developers? And so some ways I want to let him write code and then reel or reel it in. And so this whole conversation you have about touling is about maybe this is easier now that I don't need to be so strict
with what my how my developers have workflows work. They can give them more freedom knowing the consequences of a refactor or just smaller.
Yeah, I mean a lot of it. Like I'm going to say it depends. We made up t shirts for Nimble Pros that say it depends because that's the answert of everything, and it's a cop out answer.
It's going to need it. It's going to mean another thing in about forty years, you know that, right?
Nice? Yeah, I don't think it's that long, but yes, all right, maybe thirty Like what depends on who the young one on this show is today.
Okay, I think I know where you're going, But yeah, I'm a young one.
Yeah, okay, adult diapers.
Okay, adult diapers.
Explain my chad.
Explain it to me at least, but your audience appreciates it. There you go.
If you've got to explain it, it's not funny.
The thing about that, that answer that every consultant, every architect gives when when the customer asks them, you know, any question like how should we do this? How long
will this take? Is that it's a cop out answer unless you immediately follow it up with what it depends on and what the levers are that the customer can can pull to adjust the outcome that they're looking for, right, uh, and and so in the case of the software architecture and the tooling, I think in many cases, yes, if the developers know what they're doing, you don't have to have as many guardrails for them to do what they
need to do. And if the team is small or if the project is small, all those things are factors
that matter. I think in this case, the bigger the team, the longer term the project, the more complex the domain, the more important it is that folks have a unified direction in mind that you know, everybody understands what the architecture is and why they should work with it not against it, and why they might they might be benefits of having some consistency in the codebase of how things are done, so that if you, let's say, have a web API and you look at you know, five different
endpoints that all do posts to create something, they don't do it five different ways, like because then later on when you decide, hey, every time we post something, you know, we want to have some open telemetry that you know, drops off a metric that says we created this thing. Well, now you got to do that in five different places in five different ways. Like that's that's not efficient and it's error prone.
Yeah, yeah, and absolutely the biggest thing is you're going to miss one. You're going to fix four of them.
Right right, yep, there's a law for that. I forget whose law is. But the law is that so and so's law and so and so's law says that if there are things that need to be changed, I will fix at most N minus one of them.
Yes, well, you can lean on the compiler for a lot of that too, like I had to do that today. Actually, we were working on moving connection strings out of configuration and into a database that because there's a lot of different databases depending on the client right s multi tenant situation, and so instead of everywhere where I'm reading configure, now I have to read this class that's in our state bag. But the easiest way to do that is just remove
where the configuration gets injected. Just remove it. Compiler says you got to hit fix this, this, this, this, and this, and I say, okay, yeah.
Get rid of it.
Yeah, just lean in the compiler.
Lean on the compiler.
Yeah. No, compiler is your friend. It is ultimately the source of truth because it's what's got You're going to run. Everything else's secondary or not run. Yeah, we're not run. As the case. Maybe I think it's one of the reasons that get hep copiloted as well as it did, is because compiler gets to say, yeah, you know, that's the nice thing about a compiler. It is ultimately them the arbiter. Nope, I can't compile this, so thanks for playing.
What I don't want is copilot telling me that I that I'm stupid and I shouldn't do what I just did.
Right.
I like that co pilot offers positive suggestions, like something that works.
It is a very positive tool. You know, if you work on the prompts, you can make it to sarcastic and nasty.
Yeah you probably can.
Yeah you want to, but yeah, you definitely can. I've asked it to respond as if it was the nastiest stack overflow person, and it'll happily do that.
That's interesting.
Wow.
Is that an emotional thing there, Steve? Is that where you are?
I was just seeing how it could do as a substitute for stack overflow with the full experience.
Yeah, okay, so this would be funny. This will be funny if you took a poorly written method just that stands on its own right, returns a string or something, doesn't take any dependencies, and poorly written, poorly commented, give it to chat, GPT or copyl or whatever, and say, write an angry, nasty email to the person that wrote this, lambasting them for being stupid, and just see when.
It comes up. Then we have enough in the other world already.
Yeah, that'd be I think it would be hilarious.
I gotta say, I.
You just wire it up to the Daily WTFA, which which has all kinds of examples of code that you wouldn't want to see.
I find myself ghosting or you know, co co coding with folks that are using tools like Copilot, and the way some of them interact with that tool is shocking. Like if you ever spoke to another person this way, it would be an HR violation. I don't I don't know why, but it's it seems seems to bring up things in people. M hm.
I did find it. It's called Shalloway's law. When en things need to change and N is greater than one, Shalloway will find at most N minus one of these things at most but l Shalloway. Okay, that is certainly, certainly a problem when you have too much repetition, right right, jumping back to architecture.
But you know, and you're putting a shape around this to you, Steve that I really appreciate that. It's like, I want to give you some freedom to get going, get it, you know, maybe get to an MVP or something like that, and then I'm going to bring in architecture because once I get to an end of a certain number, we're gonna have a tough time fixing it.
So it's like, where is that number in that freedom, Like it's obviously not one maybe at ten it's too many, like somewhere in there is a balancing act to reel it in for sure.
Yeah, and there's there's some literature on what end should be when it comes to don't repeat yourself, and usually it's a three strikes you're out rule is the one that I'm most familiar with, where you know, the first duplicate, it's fine, don't worry about it, you know, the second one same. You know, maybe take note by the time there's three of them, Okay, this is something that we need to do something about. H and ten would be
I think, way way too You've waited too long. Yeah, but I think it's important that you also always realize that they need to be something that is logically exactly the same and not just coincidentally duplicate. What I mean by that is, let's say you have some UI that you're componentizing, and in three different components they happen to
use the same DIV structure. You don't necessarily want to pull that div structure out and say this is the one and only way that components will ever look, because now that means if you suddenly come up with a fourth component and it needs a different structure of divs to display what it wants to do. You've totally hamstrung yourself. It was just a coincidence that your first three components happened to look like that, right that you know, the
CSS classes and the layout and other things. Maybe those are structures that you want to repeat and constrain, but don't take it too far, right, And the same is true in the programming logic, just as it would be in the UI.
Yeah. Yeah, and I appreciate that, like that's the shape around this now is somewhere you can get to that number. I think it's a great act because we've all been in environments where folks were so strict nobody could get going right, So I want to give them freeom.
One of the things I've been doing recently in my software, in my architectures that I'm a part of that I really like, is just trying to focus as much of the work down to use cases. And a given use case usually maps to one command that is initiated by the UI, you know, one button click or one API endpoint or something like that. And so because it's so small, it's so simple putting all that logic in one place in one handler or service. But I'm a big fan
of handlers now for a variety of reasons. Makes it so that even a new developer can usually track how things work fairly quickly. And so, you know, whatever patterns, whether you're using vertical slices or clean architecture, demain divertive
development doesn't matter. If you've got a use case per action that the user can invoke and you have one handler for that use case, it makes it so's it's a fairly easy mapping for a developer to know where to go to fix bug or what to do to create a new function a new vertical slice, a new piece of functionality.
Yep, I'm by it.
Yeah, I'll take that.
And so the reason I mentioned that I prefer to have these be handlers as opposed to a service, right because you could have, you know, an XYZ service that has a bunch of methods on it like create the thing, update the thing, delete the thing, et cetera. Those don't compose well into a pipeline. And so lately I've been a huge fan of removing cross cutting concerns by using a design pattern called chiine of responsibility, which is the exact same pattern that asp dot net core uses with
its middleware. So any asp net dov you already know this pattern. It's it's how middleware works. But most developers aren't using it in their own solutions and their own software. And I'm not suggesting that you take all your business logic and implement it as asp net core middleware. That
would be terrible. But if you create your own middleware pipe line, which you can easily do with a tool like mediator, or you can roll your own or there's other tools out there that support this type of behaviors and commands and handlers, what that enables is a use of polymorphism and other patterns like decorators at a huge scale.
Because now instead of having you know, umpteen different services for every different entity you might have in your system, every one of which has a custom, unique interface, or maybe, if you're lucky, a generic interface. Right, if you want to add some functionality, like say some logging to every one of those methods, right, that's a lot of code you're going to have to write. It's a lot of decorators,
a lot of methods you have to wrap. As soon as you say that I'm using the handler model, every single one of your methods looks the same. They all say I handle some type and I return some other type, right, And now you can wrap those in a behavior or a decorator trivially, and you can write one behavior for doing logging, one behavior for doing exception handling, one behavior for doing validation, and it applies everywhere. And the amount of code that that cuts out of your system is
just massive. Like I've seen fifty percent or more reductions in total code base by getting rid of repeated try catch blocks and validation blox and logging blocks and everything else.
But it is also something you don't decide upfront to go change a responsibility, but to say, hey, we've reached this level of complexity, let's go retro this and then going forward we're going to use it.
I mean, you can, but this is one of the things where I've seen so much gain in productivity and design that I'm I'm just that's how I'm writing software now. Yeah, Okay, everything has a use case and a handler, and.
I mean I'm always chilled by the one right way here, Steve right, Oh, sure it's at.
And there's there's some complexity there. I'll tell you what when I'm writing a proof of concept when I'm you know, saying, hey, I want to evaluate three different ways to do this messaging over Azure, right, because Azure has seventy two different ways that you can pass messages around. I'm an to just write that code in some console apps and there's not gonna be use cases or any other structure. But
that's just a proof of concept. I'm gonna throw it away, and I'm probably gonna ask chatch ept to generate most of the code for me, because it's just a proof of concept. I'm gonna throw it away. But once I'm building the real solution and i'm gonna have tests, i'm gonna have version control, and i'm gonna have all the
proper rigor of software engineering. Then I'm also going to want to pull all those cross cutting concerns that I know I'm going to need, right like validation and logging and error handling, et cetera, And I'm gonna pull those out into behavior so I only have to have them in one place in the code from the very beginning, because I don't want to have to write that code over and over and over again on every single endpoint or every single service.
And the obligation of even in the prototype to say, let's just do this all in handlers in case we need to go this way doesn't seem that high, like you got to pick away anyway, right, I appreciate much what you're saying here is like, this is not a big ask early in a project, and then it does open the door so much of other choices.
Yeah, I mean, the only thing that you have to do differently to decide to go this route is that wherever it is that the UI enters your application, instead of injecting an eye whatever service and calling some bespoke method on that service to do the work, assuming you're not just doing it all inline in your UI, which hopefully you're not for anything, you know, non trivial, instead of that service, Instead, you're creating a command or a message or a query or whatever, and then you're using
something to dispatch that command and that dispatch process, whether that's Mediator, Jimmy Boguard's library or Wolverine or mass transit. You know, there's a bunch of these different messaging libraries that will do this for you. You know, that is the change, that's the difference. And then from there you're going to get that behavior pipeline and then you're going to have some handler somewhere that handles that message. Yeah.
No, I appreciate that. It's it's compelling, it sounds wonderful.
Yeah, I've It's not the way I work at all, but it does sound great, and I'd like to be in the habit of writing code like that.
But I mean the big thing here is you tend to walk on your own too, Carl. Where this approach is very team friendly.
Yes, yeah, it is. Yeah, true, because you're not going to have too many merge conflicts because everything comes down to one handler, which literally has one method and it's not really you know, it's not conducive to have three different developers all touching that handler at the same time to fix you know, three different bugs or whatever. So most of the time you're going to be working on separate pieces of the code based so your likelihood of merge conflicts goes way down.
Yeah, this is you know a lot of architectural decisions come down to the sort of Conway's law part of the you know, this is going to look like the team that built it, and as soon as there's you know, I think His original statement was, if we have if we're building a compiler and there's four teams working on it, it'll be a four pass compiler.
That's right.
Funny that you bring up like mass transit and mediator who heard you know, in the midst while we're recording this of this whole controversy about going to from a traditional open source, totally completely free model to a commercial variant as well, because they ye are all working on sustainability.
Yeah, well, I mean there's no such thing as a free lunch. And eventually these solo uh maintainer open source projects that are you know, hugely popular and being used by tons of fortune five hundred and for profit companies for for nothing, which is which is a contract that they make. Yeah, you know, sometimes they're going to get burned out. I mean there's only so much free support and maintenance and new updates and everything that a person can do in their free.
Time and abuse you can take before.
Any abuse that they take. And I have a ton of open source projects too, I get it. You can't always prioritize that over you know, the stuff that puts food on the table. And if you feel and I know I feel a responsibility or or you know, something to your audience, to your users, Like you know, new version of dot net comes out, I want to have this ready to go for folks that are leveraging my packages.
Some security flaw is found, I want to fix that right away, because you know, that's it's got my name on this thing. I want to make sure it's working. But at the same time, I have paying customers, and you know, I have more of an obligation to them than the folks that are using my MIT license stuff on GitHub for free.
You should listen to last week's show we did with Rob mensching on He has a thing called open source maintenance fee. Yeah, I've heard of that, which is yeah, yeah, very very interesting.
Yeah, And there's been a lot of talk on Reddit and all the thought leaders have chimed in on this. As far as you know, folks wanting to get paid for their work, I think most large organizations that have been using and profiting from mass transit or mediator or automapper or any of these tools, before they decide that they want to just rip it out and find some other free thing, they should think long and hard about.
You know, maybe it's worth you know, a thousand dollars a year, right for as much value as it provides.
Yeah, but it almost certainly is.
And guess what how much work do you have to do at that point? How much developer effort is that going to take from you? You know? None? Right, you write that check once. Maybe maybe it's a subscription thing, but you can move on. All your code still works and you're still going to get you know, the updates and support that you've been getting. But now maybe it's a better value proposition.
Or fork it and take care of it yourself, right, Like, that's right, This is exactly the argument.
But I'm with you because because surely that will be cheaper than that.
Without a doubt. Now, and I think the thing that Rob hit on battle means you haven't listened last week's show listened to it is how do we make the path for the developer who's using the free tool to convince leadership? We need to pay our share of this and make that as easy as possible.
Well, here's the thing that I think is still crazy is developers today, at least in the United States, almost are all making six figure salaries for full time positions, let's say, right at Facebooks, and Googles. They're making some multiple of one hundred k probably, and yet how many of them have the authority to spend one hundred dollars a year on a tool that will make their application faster? Almost none of them, right, for most organizations, none, and
are terrified to go get it. Oh yeah, yeah, yeah, like the hoops you have to jump through to get authorization to purchase a component or a dev tool in many of these organizations, not even huge enterprises, but even
just medium sized companies. Right, it might be director level to approve a five hundred dollars purchase and' that's just insane, right, Like, this is why companies are creating and maintaining their own messaging frameworks and email senders and everything else, sometimes not even knowing it, right, you know, like the director level has no idea that they're doing.
It because the prospect of buying software is so terrifying.
Yeah, because buying it is harder, right, So sure, if it's available on new getting it looks like it as you know, a bunch of downloads, then then they'll go that route and maybe unless they've been bitten by that in the past. Otherwise, you know, a lot of developers would rather say how hard could it be? And just code it up themselves and tell their boss that they're just working on issue one two three, you know, for the for the software, but they're not really working on that.
They're working on the component that they need. Yeah, for issue one two three that they could have made hundreds for it have been done in an hour, but now they're going to spend a week on it.
Yeah, and and forever, like it's always going to absorb everything some part of time from now on. Totally with you. I think we need to change the show name. I'm not used to RANTI Steve Smith, and that's one I like it. I'm enthusiastic he's back and he's pissed Steve Smith. Rants are awesome. Yeah, he's feisty. Normally he's our calm trainer guy who just delivers, you know, here's the right way to do things and so forth. That might get
him some opinion today, and he's feisty. I always have opinions, it's true, it's true, and you deliver them eloquently. But yeah, you're a little reved up to day. I appreciate that
because these are good thoughts. Absolutely, like you really get to the core of the thing, which is a good director of it, or that the lead tech person in this space should be the advocate for buy versus build, should be the advocate for a budget protection, and should be willing to go with those things like the fact that we've made it as difficult as it is a problematic, and part of the side effect of that is this crisis in open source.
On that happy note, are we ready wrap up? Or you got something else you want to rant about?
Steve? Did we miss something here?
Steve? Well, I don't think we talked quite as much about different types of architecture as I had thought, But that is totally fine because I think we hit a lot of cool topics.
Now, it's fine. I like this. This bounced back and forth between the coding side and the architecture side is a debate we don't have often enough, so I'm glad we did it, just because I think both those elements are important and there is a balance there. Yeah.
Very good, Well, Steve. Thanks, It's always pleasure talking to you, and I'm sure the next time will be just as pleasurable.
Thank you, awesome, Always a good time. Thanks guys.
Number twenty twenty I think you get the subway sandwich.
You got to punch the card and I get a free dot net Rocks episode.
Thanks again, Stave, and we'll talk to you next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com. Visit our website at d O T N E t R O c k s dot com for RSS feeds, down modes, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two.
Thousand and two.
And make sure you check out our sponsors. They keep us in business. Now go write some code, See you next time. You got JAD Middle Vans