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