May 7, 2025 • 53 mins
How do you balance architecture and code? Carl and Richard talk to Steve Smith about various architectural strategies and the swing back-and-forth against over-designing architecture and getting code written. Steve talks about how architecture changes depending on the size and number of teams, how the latest tools can help with architectural choices, and the challenge of effective refactoring when things need to change. Lots of great conversation!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
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
(00:21):
dot com. Hey guess what, it's dot need rocks. I'm
Carl Franklin.
Speaker 2 (00:38):
And I'm Richard Gamble.
Speaker 1 (00:39):
Steve Smith is with us. We'll be joining him in
a minute, but first, you got doggy duty today, Richard.
Speaker 2 (00:46):
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,
(01:08):
not that anybody will hear them, because editing.
Speaker 1 (01:11):
He well, or if it's cute, we leave it in.
Speaker 2 (01:16):
There's nothing cute about p on the floor.
Speaker 1 (01:18):
No, okay, all right, well let's get started with better
no framework.
Speaker 2 (01:23):
Awesome, man, what do you got?
Speaker 1 (01:32):
This came from Simon Cropp, our good friend, in the
app Phoenix Slack channel.
Speaker 2 (01:37):
What are the appears?
Speaker 1 (01:38):
Yeah, and this is a learn article at Microsoft. Wow,
Jason serializer options.
Speaker 2 (01:45):
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.
Speaker 1 (01:58):
So this is Jason's serializers dot respect nullible annotations.
Speaker 2 (02:04):
Oh my god.
Speaker 1 (02:04):
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.
Speaker 2 (02:25):
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.
Speaker 1 (02:36):
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.
Speaker 3 (02:55):
Nice.
Speaker 2 (02:55):
Look, it's a new option explicit in twenty twenty five.
What's that about.
Speaker 1 (03:02):
Respect, my authority.
Speaker 2 (03:04):
Respect my nobilitybility. No, that totally makes sense. I want
this on all the time. You said I have to
remember it.
Speaker 1 (03:14):
I am sad that I have to remember it too, but.
Speaker 2 (03:16):
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.
Speaker 1 (03:27):
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?
Speaker 2 (03:36):
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
(04:00):
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.
Speaker 1 (04:20):
Evil if you don't need it.
Speaker 2 (04:22):
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,
(04:45):
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.
Speaker 1 (05:06):
I thought I smelled smoke.
Speaker 2 (05:08):
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.
Speaker 1 (05:21):
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.
Speaker 2 (05:33):
Nineteen forty nine.
Speaker 1 (05:34):
Nineteen forty nine, let's talk about it.
Speaker 3 (05:36):
So.
Speaker 1 (05:36):
Major events included the establishment of the People's Republic of China.
Speaker 2 (05:40):
Yeah, at the end of the Cino War, Yeah.
Speaker 1 (05:43):
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.
Speaker 3 (05:52):
Ah.
Speaker 2 (05:52):
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.
Speaker 1 (06:08):
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,
(06:29):
Georgia Orwell's dystopian novel was published. And anything you want
to add to that.
Speaker 2 (06:35):
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.
Speaker 1 (06:51):
Or I love talking to boomers about programming with punch cards.
We had to use punch kin.
Speaker 2 (06:57):
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
(07:19):
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.
Speaker 1 (07:35):
I have never seen punch cards, but I would hope
that they were numbered sequentially.
Speaker 2 (07:40):
They are, but you have to number them. And they
also say do not fold, spindle or mutilate, right.
Speaker 1 (07:45):
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.
Speaker 2 (07:58):
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
(08:18):
plant dies because it gets eaten or anything like that,
that carbon and fourteen starts to decay away.
Speaker 1 (08:23):
At a constant rate.
Speaker 2 (08:24):
And you can measure the ratio of twelve to fourteen
to praiirly accurately estimated an age up to about fifty
thousand year.
Speaker 1 (08:32):
Yeah, very good.
Speaker 2 (08:32):
He won the Nobel Prize in nineteen sixty four.
Speaker 1 (08:34):
It's very cool. Yeah, all right, Well with that, let's
bring Steve on again for the how many time.
Speaker 2 (08:39):
I got to count because it's a lot.
Speaker 3 (08:42):
It's close to twenty. I think it's like nineteen or something.
Speaker 2 (08:44):
I think you think you're up there?
Speaker 1 (08:45):
Yeah, wow, I got them all here, one, two, three, seventy.
Speaker 2 (08:51):
Yeah, if you include the panels, it's I think this
is number nineteen.
Speaker 1 (08:55):
Yeah, she's a.
Speaker 2 (08:56):
Though, going back to two thousand and seven, so you know,
twenty years worth.
Speaker 1 (09:00):
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
(09:22):
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
(09:43):
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.
Speaker 2 (10:02):
I think Worldwidelife Fund won that one, and now the
wrestling guys are wwe Yeah.
Speaker 3 (10:07):
The Windows Workflow Framework also lost that. Our foundation sorry worklow.
Speaker 2 (10:14):
Foundation workflow floudation. Yeah, you don't want to you don't
want to dip into that fight. You're not even close.
Speaker 1 (10:21):
So what's up? What have you been doing?
Speaker 3 (10:23):
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
(10:44):
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.
Speaker 2 (10:54):
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
(11:16):
into a domain model.
Speaker 3 (11:17):
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
(11:39):
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.
Speaker 2 (11:57):
I love that it's ninety seven.
Speaker 3 (11:58):
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
(12:18):
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?
Speaker 2 (12:32):
Right?
Speaker 1 (12:33):
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
(12:55):
it with something that something works, but you keep the
comment did code in there.
Speaker 3 (13:01):
You're saying, you're saying you want that to be as
long as possible or as short as possible.
Speaker 1 (13:05):
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.
Speaker 3 (13:17):
It, we have version control.
Speaker 1 (13:18):
That's right, Yeah, just get it out.
Speaker 3 (13:19):
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
(13:41):
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
(14:02):
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.
Speaker 2 (14:16):
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.
Speaker 3 (14:33):
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,
(14:56):
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
(15:16):
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.
Speaker 2 (15:31):
Evil, right, m It's a great trap.
Speaker 3 (15:33):
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
(15:55):
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.
Speaker 2 (16:07):
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.
Speaker 3 (16:22):
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,
(16:43):
not yet anyway.
Speaker 2 (16:44):
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.
Speaker 3 (16:54):
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
(17:16):
a faster proliferation of duplicate code that no one wrote
that came from.
Speaker 2 (17:23):
Should we define vicoding just please? Because I don't think
we've mentioned on the show yet.
Speaker 1 (17:27):
Right, Yeah, that's the first time I've heard of it.
But I get it.
Speaker 2 (17:29):
Oh good, I'm glad you haven't because you're happier because
of it.
Speaker 1 (17:33):
Vibe programming.
Speaker 2 (17:35):
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,
(17:57):
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?
Speaker 3 (18:15):
And don't even read the code. Don't even necessarily be
able to read the code, right, this is coding for anyone.
Speaker 1 (18:20):
Yeah, well that violates every fiber of my what I
know to be true.
Speaker 2 (18:26):
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
(18:48):
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.
Speaker 1 (18:58):
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
(19:18):
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
(19:41):
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,
(20:02):
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.
Speaker 3 (20:09):
Yeah.
Speaker 2 (20:09):
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.
Speaker 3 (20:18):
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.
Speaker 2 (20:40):
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.
Speaker 3 (20:52):
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
(21:12):
striving for for years. I mean, that's what basic was
supposed to be.
Speaker 2 (21:15):
I don't think we've ever been striving for. It just
keeps coming up, keeps.
Speaker 3 (21:20):
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.
Speaker 2 (21:33):
Oddly enough, English being somewhat ambiguous because I both cut
the tree down and cut it up.
Speaker 1 (21:41):
Yeah, there's lots of those in the English language.
Speaker 3 (21:45):
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.
Speaker 2 (22:02):
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
(22:26):
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
(22:47):
going to help me make a better, more organized version
of this application in less time.
Speaker 3 (22:52):
It is true that the tooling has gotten better, for sure.
Speaker 2 (22:54):
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.
Speaker 3 (23:02):
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,
(23:24):
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
(23:47):
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.
Speaker 1 (23:55):
Like any old days.
Speaker 3 (23:56):
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.
Speaker 1 (24:04):
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.
Speaker 3 (24:22):
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
(24:44):
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.
Speaker 1 (24:52):
Sure, yep.
Speaker 2 (24:53):
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.
Speaker 3 (25:10):
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.
Speaker 2 (25:16):
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
(25:37):
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
(25:59):
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.
Speaker 1 (26:05):
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.
Speaker 3 (26:21):
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,
(26:42):
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.
Speaker 1 (27:02):
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,
(27:25):
and like wait a minute, wait a minute, I go
be right back.
Speaker 2 (27:28):
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.
Speaker 3 (27:42):
The nuclear power plant down the road spins up. It's
like the scene and the license.
Speaker 1 (27:48):
Yeah, but certainly developing Blazer apps in visual studios just
a joy.
Speaker 2 (27:52):
Yeah, it's a joy.
Speaker 1 (27:54):
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.
Speaker 2 (28:05):
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
(28:26):
don't need to be there.
Speaker 1 (28:26):
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.
Speaker 2 (28:42):
That started docking undocking MDI thing in front really from
Windows three for crying out loud, but it's never gone away.
Speaker 1 (28:49):
Yeah.
Speaker 3 (28:49):
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.
Speaker 2 (29:06):
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.
Speaker 3 (29:17):
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.
Speaker 2 (29:30):
I like that.
Speaker 3 (29:30):
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.
Speaker 1 (29:39):
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
(30:02):
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
(30:22):
as our Dallas Hey, and we're just keeping out over
tooling Visual studio architecture. You know, whatever Steve wants to
talk about.
Speaker 2 (30:31):
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
(30:54):
with what my how my developers have workflows work. They
can give them more freedom knowing the consequences of a
refactor or just smaller.
Speaker 3 (31:02):
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.
Speaker 1 (31:11):
It's going to need it. It's going to mean another
thing in about forty years, you know that, right?
Speaker 2 (31:16):
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.
Speaker 3 (31:30):
Okay, I think I know where you're going, But yeah,
I'm a young one.
Speaker 1 (31:33):
Yeah, okay, adult diapers.
Speaker 2 (31:36):
Okay, adult diapers.
Speaker 1 (31:38):
Explain my chad.
Speaker 3 (31:40):
Explain it to me at least, but your audience appreciates it.
There you go.
Speaker 1 (31:43):
If you've got to explain it, it's not funny.
Speaker 3 (31:47):
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,
(32:09):
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,
(32:31):
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
(32:53):
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.
Speaker 2 (33:14):
Yeah, yeah, and absolutely the biggest thing is you're going
to miss one. You're going to fix four of them.
Speaker 3 (33:19):
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.
Speaker 1 (33:32):
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,
(33:54):
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,
(34:15):
and I say, okay, yeah.
Speaker 2 (34:17):
Get rid of it.
Speaker 3 (34:18):
Yeah, just lean in the compiler.
Speaker 1 (34:20):
Lean on the compiler.
Speaker 2 (34:22):
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
(34:42):
the arbiter. Nope, I can't compile this, so thanks for playing.
Speaker 1 (34:48):
What I don't want is copilot telling me that I
that I'm stupid and I shouldn't do what I just did.
Speaker 3 (34:54):
Right.
Speaker 1 (34:55):
I like that co pilot offers positive suggestions, like something
that works.
Speaker 2 (35:00):
It is a very positive tool. You know, if you
work on the prompts, you can make it to sarcastic
and nasty.
Speaker 1 (35:05):
Yeah you probably can.
Speaker 3 (35:06):
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.
Speaker 1 (35:17):
That's interesting.
Speaker 3 (35:19):
Wow.
Speaker 2 (35:20):
Is that an emotional thing there, Steve? Is that where
you are?
Speaker 3 (35:24):
I was just seeing how it could do as a
substitute for stack overflow with the full experience.
Speaker 1 (35:30):
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,
(35:56):
lambasting them for being stupid, and just see when.
Speaker 2 (35:59):
It comes up. Then we have enough in the other
world already.
Speaker 1 (36:03):
Yeah, that'd be I think it would be hilarious.
Speaker 2 (36:06):
I gotta say, I.
Speaker 3 (36:07):
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.
Speaker 2 (36:15):
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.
Speaker 3 (36:34):
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.
Speaker 2 (36:54):
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,
(37:17):
like somewhere in there is a balancing act to reel
it in for sure.
Speaker 3 (37:22):
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
(37:44):
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
(38:08):
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
(38:31):
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.
Speaker 2 (38:43):
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.
Speaker 3 (39:00):
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,
(39:23):
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
(39:45):
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.
Speaker 2 (40:05):
Yep, I'm by it.
Speaker 1 (40:06):
Yeah, I'll take that.
Speaker 3 (40:07):
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
(40:30):
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.
(40:52):
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
(41:12):
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
(41:34):
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
(41:58):
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.
Speaker 2 (42:19):
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.
Speaker 3 (42:29):
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.
Speaker 2 (42:41):
I mean I'm always chilled by the one right way here,
Steve right, Oh, sure it's at.
Speaker 3 (42:46):
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,
(43:06):
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
(43:28):
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.
Speaker 2 (43:41):
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.
Speaker 3 (44:00):
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
(44:22):
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
(44:42):
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.
Speaker 2 (44:51):
No, I appreciate that. It's it's compelling, it sounds wonderful.
Speaker 1 (44:55):
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.
Speaker 2 (45:01):
But I mean the big thing here is you tend
to walk on your own too, Carl. Where this approach
is very team friendly.
Speaker 3 (45:09):
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
(45:30):
separate pieces of the code based so your likelihood of
merge conflicts goes way down.
Speaker 2 (45:34):
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.
Speaker 3 (45:50):
That's right.
Speaker 2 (45:51):
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.
Speaker 3 (46:06):
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
(46:27):
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.
Speaker 2 (46:32):
Time and abuse you can take before.
Speaker 3 (46:35):
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
(46:57):
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
(47:18):
on GitHub for free.
Speaker 1 (47:18):
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.
Speaker 3 (47:32):
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
(47:52):
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.
Speaker 2 (48:00):
Yeah, but it almost certainly is.
Speaker 3 (48:02):
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.
Speaker 2 (48:24):
Or fork it and take care of it yourself, right, Like,
that's right, This is exactly the argument.
Speaker 3 (48:28):
But I'm with you because because surely that will be
cheaper than that.
Speaker 2 (48:32):
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.
Speaker 3 (48:48):
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
(49:10):
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
(49:33):
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.
Speaker 2 (49:52):
It because the prospect of buying software is so terrifying.
Speaker 3 (49:55):
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
(50:16):
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.
Speaker 2 (50:27):
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
(50:49):
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
(51:11):
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.
Speaker 1 (51:25):
On that happy note, are we ready wrap up? Or
you got something else you want to rant about?
Speaker 2 (51:29):
Steve? Did we miss something here?
Speaker 3 (51:30):
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.
Speaker 2 (51:37):
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.
Speaker 1 (51:49):
Very good, Well, Steve. Thanks, It's always pleasure talking to you,
and I'm sure the next time will be just as pleasurable.
Speaker 3 (51:55):
Thank you, awesome, Always a good time. Thanks guys.
Speaker 2 (51:57):
Number twenty twenty I think you get the subway sandwich.
Speaker 3 (52:04):
You got to punch the card and I get a
free dot net Rocks episode.
Speaker 1 (52:12):
Thanks again, Stave, and we'll talk to you next time
on dot net rocks. Dot net Rocks is brought to
(52:39):
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,
(53:02):
and access to the full archives going back to show
number one, recorded in September two.
Speaker 3 (53:07):
Thousand and two.
Speaker 1 (53:08):
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
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
(00:21):
dot com. Hey guess what, it's dot need rocks. I'm
Carl Franklin.
Speaker 2 (00:38):
And I'm Richard Gamble.
Speaker 1 (00:39):
Steve Smith is with us. We'll be joining him in
a minute, but first, you got doggy duty today, Richard.
Speaker 2 (00:46):
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,
(01:08):
not that anybody will hear them, because editing.
Speaker 1 (01:11):
He well, or if it's cute, we leave it in.
Speaker 2 (01:16):
There's nothing cute about p on the floor.
Speaker 1 (01:18):
No, okay, all right, well let's get started with better
no framework.
Speaker 2 (01:23):
Awesome, man, what do you got?
Speaker 1 (01:32):
This came from Simon Cropp, our good friend, in the
app Phoenix Slack channel.
Speaker 2 (01:37):
What are the appears?
Speaker 1 (01:38):
Yeah, and this is a learn article at Microsoft. Wow,
Jason serializer options.
Speaker 2 (01:45):
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.
Speaker 1 (01:58):
So this is Jason's serializers dot respect nullible annotations.
Speaker 2 (02:04):
Oh my god.
Speaker 1 (02:04):
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.
Speaker 2 (02:25):
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.
Speaker 1 (02:36):
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.
Speaker 3 (02:55):
Nice.
Speaker 2 (02:55):
Look, it's a new option explicit in twenty twenty five.
What's that about.
Speaker 1 (03:02):
Respect, my authority.
Speaker 2 (03:04):
Respect my nobilitybility. No, that totally makes sense. I want
this on all the time. You said I have to
remember it.
Speaker 1 (03:14):
I am sad that I have to remember it too, but.
Speaker 2 (03:16):
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.
Speaker 1 (03:27):
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?
Speaker 2 (03:36):
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
(04:00):
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.
Speaker 1 (04:20):
Evil if you don't need it.
Speaker 2 (04:22):
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,
(04:45):
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.
Speaker 1 (05:06):
I thought I smelled smoke.
Speaker 2 (05:08):
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.
Speaker 1 (05:21):
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.
Speaker 2 (05:33):
Nineteen forty nine.
Speaker 1 (05:34):
Nineteen forty nine, let's talk about it.
Speaker 3 (05:36):
So.
Speaker 1 (05:36):
Major events included the establishment of the People's Republic of China.
Speaker 2 (05:40):
Yeah, at the end of the Cino War, Yeah.
Speaker 1 (05:43):
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.
Speaker 3 (05:52):
Ah.
Speaker 2 (05:52):
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.
Speaker 1 (06:08):
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,
(06:29):
Georgia Orwell's dystopian novel was published. And anything you want
to add to that.
Speaker 2 (06:35):
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.
Speaker 1 (06:51):
Or I love talking to boomers about programming with punch cards.
We had to use punch kin.
Speaker 2 (06:57):
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
(07:19):
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.
Speaker 1 (07:35):
I have never seen punch cards, but I would hope
that they were numbered sequentially.
Speaker 2 (07:40):
They are, but you have to number them. And they
also say do not fold, spindle or mutilate, right.
Speaker 1 (07:45):
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.
Speaker 2 (07:58):
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
(08:18):
plant dies because it gets eaten or anything like that,
that carbon and fourteen starts to decay away.
Speaker 1 (08:23):
At a constant rate.
Speaker 2 (08:24):
And you can measure the ratio of twelve to fourteen
to praiirly accurately estimated an age up to about fifty
thousand year.
Speaker 1 (08:32):
Yeah, very good.
Speaker 2 (08:32):
He won the Nobel Prize in nineteen sixty four.
Speaker 1 (08:34):
It's very cool. Yeah, all right, Well with that, let's
bring Steve on again for the how many time.
Speaker 2 (08:39):
I got to count because it's a lot.
Speaker 3 (08:42):
It's close to twenty. I think it's like nineteen or something.
Speaker 2 (08:44):
I think you think you're up there?
Speaker 1 (08:45):
Yeah, wow, I got them all here, one, two, three, seventy.
Speaker 2 (08:51):
Yeah, if you include the panels, it's I think this
is number nineteen.
Speaker 1 (08:55):
Yeah, she's a.
Speaker 2 (08:56):
Though, going back to two thousand and seven, so you know,
twenty years worth.
Speaker 1 (09:00):
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
(09:22):
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
(09:43):
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.
Speaker 2 (10:02):
I think Worldwidelife Fund won that one, and now the
wrestling guys are wwe Yeah.
Speaker 3 (10:07):
The Windows Workflow Framework also lost that. Our foundation sorry worklow.
Speaker 2 (10:14):
Foundation workflow floudation. Yeah, you don't want to you don't
want to dip into that fight. You're not even close.
Speaker 1 (10:21):
So what's up? What have you been doing?
Speaker 3 (10:23):
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
(10:44):
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.
Speaker 2 (10:54):
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
(11:16):
into a domain model.
Speaker 3 (11:17):
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
(11:39):
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.
Speaker 2 (11:57):
I love that it's ninety seven.
Speaker 3 (11:58):
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
(12:18):
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?
Speaker 2 (12:32):
Right?
Speaker 1 (12:33):
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
(12:55):
it with something that something works, but you keep the
comment did code in there.
Speaker 3 (13:01):
You're saying, you're saying you want that to be as
long as possible or as short as possible.
Speaker 1 (13:05):
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.
Speaker 3 (13:17):
It, we have version control.
Speaker 1 (13:18):
That's right, Yeah, just get it out.
Speaker 3 (13:19):
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
(13:41):
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
(14:02):
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.
Speaker 2 (14:16):
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.
Speaker 3 (14:33):
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,
(14:56):
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
(15:16):
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.
Speaker 2 (15:31):
Evil, right, m It's a great trap.
Speaker 3 (15:33):
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
(15:55):
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.
Speaker 2 (16:07):
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.
Speaker 3 (16:22):
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,
(16:43):
not yet anyway.
Speaker 2 (16:44):
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.
Speaker 3 (16:54):
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
(17:16):
a faster proliferation of duplicate code that no one wrote
that came from.
Speaker 2 (17:23):
Should we define vicoding just please? Because I don't think
we've mentioned on the show yet.
Speaker 1 (17:27):
Right, Yeah, that's the first time I've heard of it.
But I get it.
Speaker 2 (17:29):
Oh good, I'm glad you haven't because you're happier because
of it.
Speaker 1 (17:33):
Vibe programming.
Speaker 2 (17:35):
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,
(17:57):
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?
Speaker 3 (18:15):
And don't even read the code. Don't even necessarily be
able to read the code, right, this is coding for anyone.
Speaker 1 (18:20):
Yeah, well that violates every fiber of my what I
know to be true.
Speaker 2 (18:26):
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
(18:48):
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.
Speaker 1 (18:58):
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
(19:18):
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
(19:41):
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,
(20:02):
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.
Speaker 3 (20:09):
Yeah.
Speaker 2 (20:09):
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.
Speaker 3 (20:18):
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.
Speaker 2 (20:40):
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.
Speaker 3 (20:52):
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
(21:12):
striving for for years. I mean, that's what basic was
supposed to be.
Speaker 2 (21:15):
I don't think we've ever been striving for. It just
keeps coming up, keeps.
Speaker 3 (21:20):
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.
Speaker 2 (21:33):
Oddly enough, English being somewhat ambiguous because I both cut
the tree down and cut it up.
Speaker 1 (21:41):
Yeah, there's lots of those in the English language.
Speaker 3 (21:45):
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.
Speaker 2 (22:02):
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
(22:26):
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
(22:47):
going to help me make a better, more organized version
of this application in less time.
Speaker 3 (22:52):
It is true that the tooling has gotten better, for sure.
Speaker 2 (22:54):
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.
Speaker 3 (23:02):
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,
(23:24):
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
(23:47):
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.
Speaker 1 (23:55):
Like any old days.
Speaker 3 (23:56):
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.
Speaker 1 (24:04):
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.
Speaker 3 (24:22):
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
(24:44):
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.
Speaker 1 (24:52):
Sure, yep.
Speaker 2 (24:53):
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.
Speaker 3 (25:10):
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.
Speaker 2 (25:16):
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
(25:37):
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
(25:59):
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.
Speaker 1 (26:05):
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.
Speaker 3 (26:21):
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,
(26:42):
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.
Speaker 1 (27:02):
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,
(27:25):
and like wait a minute, wait a minute, I go
be right back.
Speaker 2 (27:28):
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.
Speaker 3 (27:42):
The nuclear power plant down the road spins up. It's
like the scene and the license.
Speaker 1 (27:48):
Yeah, but certainly developing Blazer apps in visual studios just
a joy.
Speaker 2 (27:52):
Yeah, it's a joy.
Speaker 1 (27:54):
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.
Speaker 2 (28:05):
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
(28:26):
don't need to be there.
Speaker 1 (28:26):
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.
Speaker 2 (28:42):
That started docking undocking MDI thing in front really from
Windows three for crying out loud, but it's never gone away.
Speaker 1 (28:49):
Yeah.
Speaker 3 (28:49):
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.
Speaker 2 (29:06):
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.
Speaker 3 (29:17):
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.
Speaker 2 (29:30):
I like that.
Speaker 3 (29:30):
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.
Speaker 1 (29:39):
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
(30:02):
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
(30:22):
as our Dallas Hey, and we're just keeping out over
tooling Visual studio architecture. You know, whatever Steve wants to
talk about.
Speaker 2 (30:31):
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
(30:54):
with what my how my developers have workflows work. They
can give them more freedom knowing the consequences of a
refactor or just smaller.
Speaker 3 (31:02):
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.
Speaker 1 (31:11):
It's going to need it. It's going to mean another
thing in about forty years, you know that, right?
Speaker 2 (31:16):
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.
Speaker 3 (31:30):
Okay, I think I know where you're going, But yeah,
I'm a young one.
Speaker 1 (31:33):
Yeah, okay, adult diapers.
Speaker 2 (31:36):
Okay, adult diapers.
Speaker 1 (31:38):
Explain my chad.
Speaker 3 (31:40):
Explain it to me at least, but your audience appreciates it.
There you go.
Speaker 1 (31:43):
If you've got to explain it, it's not funny.
Speaker 3 (31:47):
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,
(32:09):
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,
(32:31):
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
(32:53):
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.
Speaker 2 (33:14):
Yeah, yeah, and absolutely the biggest thing is you're going
to miss one. You're going to fix four of them.
Speaker 3 (33:19):
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.
Speaker 1 (33:32):
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,
(33:54):
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,
(34:15):
and I say, okay, yeah.
Speaker 2 (34:17):
Get rid of it.
Speaker 3 (34:18):
Yeah, just lean in the compiler.
Speaker 1 (34:20):
Lean on the compiler.
Speaker 2 (34:22):
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
(34:42):
the arbiter. Nope, I can't compile this, so thanks for playing.
Speaker 1 (34:48):
What I don't want is copilot telling me that I
that I'm stupid and I shouldn't do what I just did.
Speaker 3 (34:54):
Right.
Speaker 1 (34:55):
I like that co pilot offers positive suggestions, like something
that works.
Speaker 2 (35:00):
It is a very positive tool. You know, if you
work on the prompts, you can make it to sarcastic
and nasty.
Speaker 1 (35:05):
Yeah you probably can.
Speaker 3 (35:06):
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.
Speaker 1 (35:17):
That's interesting.
Speaker 3 (35:19):
Wow.
Speaker 2 (35:20):
Is that an emotional thing there, Steve? Is that where
you are?
Speaker 3 (35:24):
I was just seeing how it could do as a
substitute for stack overflow with the full experience.
Speaker 1 (35:30):
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,
(35:56):
lambasting them for being stupid, and just see when.
Speaker 2 (35:59):
It comes up. Then we have enough in the other
world already.
Speaker 1 (36:03):
Yeah, that'd be I think it would be hilarious.
Speaker 2 (36:06):
I gotta say, I.
Speaker 3 (36:07):
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.
Speaker 2 (36:15):
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.
Speaker 3 (36:34):
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.
Speaker 2 (36:54):
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,
(37:17):
like somewhere in there is a balancing act to reel
it in for sure.
Speaker 3 (37:22):
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
(37:44):
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
(38:08):
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
(38:31):
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.
Speaker 2 (38:43):
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.
Speaker 3 (39:00):
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,
(39:23):
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
(39:45):
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.
Speaker 2 (40:05):
Yep, I'm by it.
Speaker 1 (40:06):
Yeah, I'll take that.
Speaker 3 (40:07):
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
(40:30):
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.
(40:52):
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
(41:12):
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
(41:34):
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
(41:58):
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.
Speaker 2 (42:19):
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.
Speaker 3 (42:29):
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.
Speaker 2 (42:41):
I mean I'm always chilled by the one right way here,
Steve right, Oh, sure it's at.
Speaker 3 (42:46):
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,
(43:06):
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
(43:28):
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.
Speaker 2 (43:41):
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.
Speaker 3 (44:00):
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
(44:22):
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
(44:42):
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.
Speaker 2 (44:51):
No, I appreciate that. It's it's compelling, it sounds wonderful.
Speaker 1 (44:55):
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.
Speaker 2 (45:01):
But I mean the big thing here is you tend
to walk on your own too, Carl. Where this approach
is very team friendly.
Speaker 3 (45:09):
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
(45:30):
separate pieces of the code based so your likelihood of
merge conflicts goes way down.
Speaker 2 (45:34):
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.
Speaker 3 (45:50):
That's right.
Speaker 2 (45:51):
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.
Speaker 3 (46:06):
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
(46:27):
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.
Speaker 2 (46:32):
Time and abuse you can take before.
Speaker 3 (46:35):
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
(46:57):
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
(47:18):
on GitHub for free.
Speaker 1 (47:18):
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.
Speaker 3 (47:32):
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
(47:52):
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.
Speaker 2 (48:00):
Yeah, but it almost certainly is.
Speaker 3 (48:02):
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.
Speaker 2 (48:24):
Or fork it and take care of it yourself, right, Like,
that's right, This is exactly the argument.
Speaker 3 (48:28):
But I'm with you because because surely that will be
cheaper than that.
Speaker 2 (48:32):
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.
Speaker 3 (48:48):
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
(49:10):
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
(49:33):
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.
Speaker 2 (49:52):
It because the prospect of buying software is so terrifying.
Speaker 3 (49:55):
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
(50:16):
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.
Speaker 2 (50:27):
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
(50:49):
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
(51:11):
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.
Speaker 1 (51:25):
On that happy note, are we ready wrap up? Or
you got something else you want to rant about?
Speaker 2 (51:29):
Steve? Did we miss something here?
Speaker 3 (51:30):
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.
Speaker 2 (51:37):
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.
Speaker 1 (51:49):
Very good, Well, Steve. Thanks, It's always pleasure talking to you,
and I'm sure the next time will be just as pleasurable.
Speaker 3 (51:55):
Thank you, awesome, Always a good time. Thanks guys.
Speaker 2 (51:57):
Number twenty twenty I think you get the subway sandwich.
Speaker 3 (52:04):
You got to punch the card and I get a
free dot net Rocks episode.
Speaker 1 (52:12):
Thanks again, Stave, and we'll talk to you next time
on dot net rocks. Dot net Rocks is brought to
(52:39):
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,
(53:02):
and access to the full archives going back to show
number one, recorded in September two.
Speaker 3 (53:07):
Thousand and two.
Speaker 1 (53:08):
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
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Law & Order: Criminal Justice System - Season 1 & Season 2
Season Two Out Now! Law & Order: Criminal Justice System tells the real stories behind the landmark cases that have shaped how the most dangerous and influential criminals in America are prosecuted. In its second season, the series tackles the threat of terrorism in the United States. From the rise of extremist political groups in the 60s to domestic lone wolves in the modern day, we explore how organizations like the FBI and Joint Terrorism Take Force have evolved to fight back against a multitude of terrorist threats.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com