Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month,
Speaker 1: we'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey guess what, it's dot net rocks. I'm
Speaker 1: Carl Franklin, an amateur camp and we haven't it's been
Speaker 1: a while since we just recorded one. Last week's show
Speaker 1: we recorded about an hour ago. But before that, it's
Speaker 1: been been a month because I went on the road
Speaker 1: for a month, all right. I did a couple of
Speaker 1: weeks in Mexico just to get out of the gray
Speaker 1: because it's the challenge of looking up up here.
Speaker 2: And then NBC London.
Speaker 1: I saw the posts you did from Mexico with our
Speaker 1: friends Paul and Stephanie.
Speaker 2: Yep, they came. They came down for a week with us,
Speaker 2: and then I was at NBC London and then Sweet
Speaker 2: Dug in Stockholm.
Speaker 1: Very cool.
Speaker 2: So you saw Fritz there, I believe I did. The
Speaker 2: Fritzy was there, The Hunter was there, the Handsoman.
Speaker 1: Wow, that's cool.
Speaker 2: Yeah, I know the excess of Scots. To be honest,
Speaker 2: I will be at the other Stockholm conference dev some Yeah,
Speaker 2: I'm looking at being there as well, so maybe we
Speaker 2: can record some stuff.
Speaker 1: Yeah maybe I think the weather be a little nicer
Speaker 1: when I'm there. Yeah, it'll be probably, I think just timing. Okay,
Speaker 1: let's get into better now a framework. All right, man,
Speaker 1: what do you got long last? Yeah, Music to Code
Speaker 1: Buy track twenty two is available.
Speaker 2: Oh my goodness, it has been a while.
Speaker 1: Is available for download and it's been added into the
Speaker 1: Election and the Wave collection and the Flat collection and
Speaker 1: you can go get it at music toocode buy dot net. Awesome,
Speaker 1: but that's not the only thing. Maybe should we play
Speaker 1: just a little bit of it?
Speaker 2: Yeah?
Speaker 1: You should, all right, I should go ahead, So there
Speaker 1: you go. It's just a little bit of it.
Speaker 2: Awesome.
Speaker 1: Yeah. So I do have an announcement around this whole
Speaker 1: music to Code by, music to Flow by whatever thing.
Speaker 1: So music to Code by, you know, it started long
Speaker 1: ago as a project that was on Kickstarter, did an
Speaker 1: album with three tracks and sent out a CD, and
Speaker 1: then I started making more tracks and selling them digitally
Speaker 1: and it all was going pretty well, and it kind
Speaker 1: of slowed down quite a lot, and then every once
Speaker 1: in a while, I'd throw out another track every year,
Speaker 1: every couple of years. And I really wanted to market
Speaker 1: it outside of developers, because the developers are the only
Speaker 1: ones who know what music to code, buy is, and
Speaker 1: anybody else looks at that and says, I don't code,
Speaker 1: what do I need this for? And so I really
Speaker 1: wanted to market it as a you know, a relaxation,
Speaker 1: a focused tool to the broader audience. So I tried
Speaker 1: music to flow by. Well that didn't really work either,
Speaker 1: and so I'm rebranding it yet again, and it's going
Speaker 1: to be called Magic Focus Music. Interesting, Yeah, because I
Speaker 1: think that kind of describes what it is. And I
Speaker 1: don't want to do this as an app. And here's why.
Speaker 1: I'm basically charging for access to this music, right And
Speaker 1: if you do an app, then you have to go
Speaker 1: through the app store in a purchases give thirty percent.
Speaker 1: What a what a racket that is? So I'm building
Speaker 1: a website. It'll be mobile friendly, you'll sign up, you'll
Speaker 1: buy your stuff. It's going to be subscription, it's going
Speaker 1: to be affordable. And because I also figure that people
Speaker 1: are going to mostly use this like in their laptops,
Speaker 1: on their when they're working on their laptops, when they're
Speaker 1: on their desktop. So don't really foresee anybody putting it
Speaker 1: on on their phone while they're using their phone, because
Speaker 1: if he's in their phone, they're not really focusing on anything,
Speaker 1: are they true? Yeah, yeah, so that's the story. Look
Speaker 1: for music tooflow by dot com. I will mention it
Speaker 1: on the show when it is available, but I'm working
Speaker 1: on it right now, and in the meantime, if you
Speaker 1: want to just download the tracks and manage them yourself,
Speaker 1: like most developers like to do, go to music toocoba
Speaker 1: dot net. It's the same stuff, all right, It's exactly
Speaker 1: the same music. So that's it.
Speaker 2: Cool man, That's what I got. Who's talking to us today,
Speaker 2: Richard Grady Calm on Top of Show eighteen sixty one.
Speaker 2: We did it with Jeremy back in August of twenty
Speaker 2: twenty three. You know that I thought talking about minimal architecture. Hey,
Speaker 2: we're going to talk about vertical architecture, but first we
Speaker 2: talked about minimal architecture eighteen months ago. So Damien had
Speaker 2: this great comedy, said a great episode. I always enjoy
Speaker 2: hearing from Jeremy, and it's great to see. Finally a
Speaker 2: tapering off of the micro services hype. I found much
Speaker 2: greater developer efficiency aggressively building natural quote seams that's seams
Speaker 2: seems into projects. Version one or the test edition might
Speaker 2: ship is a single process, but built from multiple projects,
Speaker 2: which can then be easily broken into deployal microservice if
Speaker 2: and when required. Another approach is to have multiple build
Speaker 2: versions of a product. One is a single process and
Speaker 2: others might be split into multiple micro services. And if
Speaker 2: you get your seams right, the amount of additional work
Speaker 2: is trivial. It can be a good exercise which forces
Speaker 2: clean separations as a project grows and allows simple deployments
Speaker 2: and a fast develop when the mega load volumes are required.
Speaker 2: I find it useful to actively try and separate development
Speaker 2: from ultimate deployment. The vast majority of our business code
Speaker 2: can run just as well on a watch as in
Speaker 2: the cloud. Although obstensibly ridiculous, I don't know watch based
Speaker 2: development approaching AI. Yeah, well, of course you'll have.
Speaker 1: To have a cy my coffee cup as AI in it.
Speaker 2: Yes, my fork. Although obstensibly ridiculous, as all AI projects
Speaker 2: are approaching designs with the goal of running it on
Speaker 2: a watch can push towards some good, clean design decisions.
Speaker 2: I think you got a good insight here, Damien, which
Speaker 2: is you're pushing on Conway's law that if we organize
Speaker 2: the project into logical units, those are the those become
Speaker 2: the natural seams. So you start thinking about what are
Speaker 2: the areas of resonance, like what's likely to change, keep
Speaker 2: that separate, and whether you compile it all into one
Speaker 2: big assembly or not doesn't matter. Right, The deployment is
Speaker 2: separate from the construction. So Damian, thank you so much
Speaker 2: for your comment, and a copy of musico By. It's
Speaker 2: on its way to you. And if you'd like a
Speaker 2: copy of musico By, I write a comment on the
Speaker 2: website at dot at Rocks, dot Commra on the Facebook,
Speaker 2: so we publish every show there, and if you comment
Speaker 2: there at everyady on the show, we'll send you a
Speaker 2: copy of music Oe.
Speaker 1: And you can follow us on the other social media's.
Speaker 1: We've been on ex Twitter forever. We're also on mastadon
Speaker 1: and at Blue Sky, which is really coming along, and
Speaker 1: some aberration of at Carl Franklin and at Rich Campbell absolutely. Yeah.
Speaker 1: All right, So before we introduced Jeremy Miller, let's talk
Speaker 1: about nineteen thirty nine. Some significant events included the start
Speaker 1: of World War two.
Speaker 2: Yeah, that's kind of a significant event.
Speaker 1: Yeah. Germany invaded Poland on September first, leading Britain and
Speaker 1: France declare war on Germany. Additionally, this year saw the
Speaker 1: debut of iconic cultural works like The Wizard of Oz
Speaker 1: and the first NCAA basketball tournament. What do you got
Speaker 1: on near lest Richard?
Speaker 2: You know, I've been doing I've been doing the future
Speaker 2: of energy since the Worldwide Energy Geek out what ten
Speaker 2: years ago, and that finally spun into folks asking me
Speaker 2: to do talks just on nuclear power, which and now
Speaker 2: I've done for the past year or so. And interesting, curiously,
Speaker 2: I started doing them before it got really exciting, because
Speaker 2: it really has been around on to nuclear power. But
Speaker 2: one of the cornerstones of that entire story is starts
Speaker 2: in nineteen thirty nine when Autahon and lease Meitner published
Speaker 2: the paper on splitting a uranium atom for the first time. Wow,
Speaker 2: And interestingly, they calculated the yield of the energy of
Speaker 2: splitting that atom from Einstein's nineteen oh five paper equals
Speaker 2: mc squared and he was absolutely completely right, Like the
Speaker 2: numbers worked perfectly. So thirty something years before this guy
Speaker 2: had figured out, well, if you really could convert matter
Speaker 2: into energy, this is how much you'd get. And that
Speaker 2: paper is sorted to the foundational piece like first time
Speaker 2: the intentionally split the ADAM was nineteen thirty nine and
Speaker 2: eighteen forty five they will deploy the first automic bomb.
Speaker 1: I don't know if it was this paper or which
Speaker 1: one that after it was proven, they came to Einstein
Speaker 1: and said, professor, you were right, you were right. Isn't
Speaker 1: that a victory for you. He says, no, it's a
Speaker 1: victory for God.
Speaker 2: Very that's very Einsteinian. Yeah, yeah, but yeah, he's it's
Speaker 2: amazing how quickly all of that happened. Yeah, you know.
Speaker 2: The good news is from that came this paper from
Speaker 2: the English, the mod Report, that said both we can
Speaker 2: use this to make energy and we can use this
Speaker 2: to make weapons, and whereupon they probably did both.
Speaker 1: Yeah.
Speaker 2: Yeah, nineteen thirty nine pivotal year and.
Speaker 1: A pivotal episode of dot net rocks. Because our old
Speaker 1: friend Jeremy Miller is here. And you know, if if
Speaker 1: you're younger than us. You probably you might know who
Speaker 1: he is, but if you've been around for a few
Speaker 1: years like we have, you'll definitely know. So I'm going
Speaker 1: to read your bio anyway. Jeremy Jeremy Miller started his
Speaker 1: career as a real engineer that's in quotes, but wandered
Speaker 1: into software because that looked like more fun. Since then,
Speaker 1: Jeremy has worked in and led software development teams in
Speaker 1: the computer manufacturing industry, finance, insurance, healthcare, and banking industries. Lately,
Speaker 1: Jeremy has been focused on leading software architecture and teams
Speaker 1: and helping mentor other software architects, and by lately I
Speaker 1: mean the last ten years right. Having had roles both
Speaker 1: as an in house software architect and software consultant, Jeremy
Speaker 1: has a great deal of insight into the challenges that
Speaker 1: confront companies developing and maintaining enterprise systems over time. Jeremy
Speaker 1: is well known for his open source software tools, starting
Speaker 1: with structure Map and continuing to Martin and Wolverine and others.
Speaker 1: Jeremy is also a frequent author and technical speaker at
Speaker 1: software conferences and can be found at JEREMYD. Miller dot com.
Speaker 1: Welcome back, sir, thank you very much and very sorry.
Speaker 3: Let me apologize for writing such a ridiculously long I
Speaker 3: hope for you.
Speaker 1: Well, people need to know who you are, and uh, yeah,
Speaker 1: you're the guy. And Hibernate Mafia member is not in there, however, heard.
Speaker 3: Oh if we could just kindly kindly let that one,
Speaker 3: that one go by.
Speaker 2: A long time ago.
Speaker 1: Man, that's right, nobody remembers.
Speaker 3: Yeah, most of your audience, most of your audience is wondering,
Speaker 3: what is it Hybernate.
Speaker 1: That's all right, we don't need to tell him.
Speaker 2: How is the critter stack these days?
Speaker 3: Yeah, so the critive sack. Somebody was making fun of
Speaker 3: that today. Martin and Wolverine moving along very well. So
Speaker 3: at this point, you know, the shameless plug park. At
Speaker 3: this point, I would say Martin is the most widely
Speaker 3: used to ben sourcing tool dotnet. I think it's by
Speaker 3: far and away the most robust. I think we're this.
Speaker 3: We had such a huge year last year in terms
Speaker 3: of future development. I think I'm ready at the point
Speaker 3: to say I think we stand up against any events
Speaker 3: sourcing infrastructure across any ecosystem. Nice good Wolverine completes Wolverine
Speaker 3: and some other littler things complete the the the whole
Speaker 3: critter stack, and that is that's a purposeful theme. Moving
Speaker 3: really fast on that, and like one of the specifics
Speaker 3: we'll talk about is how Wolverine has some special sauce
Speaker 3: for doing vertical slice architecture and almost to take the well,
Speaker 3: eventually you're gonna let you, you're gonna make me, let
Speaker 3: me take a tangent on your comment from Damian earlier.
Speaker 3: It's also developing a lot of special sauce for doing
Speaker 3: modular monoliths, and we might wanna, might want to talk
Speaker 3: about why the modular monolith idea is absolutely not a
Speaker 3: silver bullet and there's a lot more challenges than I
Speaker 3: think people are recognizing right now.
Speaker 2: Yeah, dude, if there was an easy way to do it,
Speaker 2: we'd be doing it. Everything is hard.
Speaker 3: Yeah, it was easy.
Speaker 2: You could buy it at seven to eleven. Everything is
Speaker 2: definitely hard. You know, we've kept circling back on this idea.
Speaker 2: I mean, of course twenty something years have done at Rocks.
Speaker 2: We've gone through it all. Man, Like, remember when SOA
Speaker 2: was a good idea and yeah, then we talked about
Speaker 2: the various globs of goo and now you call them
Speaker 2: monoliths and then you know this modularization or peeling pieces
Speaker 2: off like it's it's a cycle, right, you know, we're
Speaker 2: all trying to build better software.
Speaker 1: SOA was an eye opener for me, not in the
Speaker 1: implementation that was suggested at the time, because I thought
Speaker 1: that was way over architected, but just the idea of
Speaker 1: having islands. I thought that was a good idea, and
Speaker 1: it was one that hadn't occurred to me up to then.
Speaker 3: I think you read it to it more so. I
Speaker 3: was a Dell Computers at the time when when Dell
Speaker 3: still manufactured their own stuff. So I'm trying to apply
Speaker 3: that to at the time manufacturing it when you have
Speaker 3: shipping systems and inventory systems and a million and one
Speaker 3: little one off things where they may need to want
Speaker 3: to talk to each other, where you don't want to
Speaker 3: duplicate as much data, you know, SOA was it was
Speaker 3: attractive at least in theory, right I don't I don't
Speaker 3: think anybody wants to reuse any of the mechanisms we
Speaker 3: use back then though.
Speaker 1: Now, yeah, that's exactly what I'm saying.
Speaker 2: Tooling is always a problem with this idea that SO
Speaker 2: was catching. It was basically at the forefront of the
Speaker 2: fact that we were about to blow the client up, right,
Speaker 2: that that you were going to have phones, were going
Speaker 2: to be real clients. There was going to be multiple
Speaker 2: devices and multiple platforms, you know, coming out of the
Speaker 2: wind Tell hegemony where you were building on the same
Speaker 2: machine that everybody was working from. Or we didn't ever
Speaker 2: think about it all that, which was a weird time.
Speaker 2: It is always said, hey, this back end code you'll
Speaker 2: work for everything. You'll only have to write that once
Speaker 2: and now you'll be You just got to set a
Speaker 2: services that you can decide what client you want to use.
Speaker 3: Yes, that also went also went a lot easier when
Speaker 3: we gave up on the full XML soap.
Speaker 2: Thing and oh lord save from eximum.
Speaker 3: Yeah, we're old enough. We lived through.
Speaker 2: The wisdole, the wisdole nightmare.
Speaker 1: Yeah.
Speaker 3: Hell uh are systems that did three or four levels
Speaker 3: of XML transformation to the point where you had no
Speaker 3: traceability between up to downstream.
Speaker 1: Right, we should never have needed biz talk.
Speaker 2: Yeah, I mean the origins of bis talk before the
Speaker 2: soap layer were you know, pre Internet intercommunications, Like they
Speaker 2: were doing serious transformation of data for connecting between companies. Right,
Speaker 2: the fact that we standardize the network and then it
Speaker 2: starts standardizing protocols. You're right, we should have been able
Speaker 2: to move away from it biz talk. I think just
Speaker 2: tried to stay relevant. Yeah, Plus we kept screwing up.
Speaker 2: These interplay protocols were bad, right, and they were always
Speaker 2: bad like CORBA was bad.
Speaker 3: Is the last we will go down this rabbit hole.
Speaker 3: The last video I recorded, we talked about DCOM, a
Speaker 3: DCOM war story.
Speaker 2: So oh boy, and you know the D stands for dumb.
Speaker 1: Welcome to three old guys talking about technology that doesn't
Speaker 1: exist anymore.
Speaker 2: But to the to your point, it's better now, right,
Speaker 2: Like we have learned, we have better platforms, we have
Speaker 2: more standardization. We we understand what a cloud proxy is
Speaker 2: for and why it makes our lives so much better.
Speaker 2: Like things are better.
Speaker 3: I'll go farther the done it, I mean, we're all
Speaker 3: done at guys. Here the donet ecosystem, I think it's
Speaker 3: just generation vastly better after the dynat core wave of things.
Speaker 3: Some of the low level abstractions that they put in
Speaker 3: place I host, the I configuration, eyewagger, those standard interfaces,
Speaker 3: the I host builder, so much of that has.
Speaker 2: I'm coupling it from Windows entirely. That process, that rething
Speaker 2: just made it a better profit platform.
Speaker 3: Yes, I'm I'm doing this on a Mac. I haven't
Speaker 3: coded on Windows in years except for Pararelel. Yeah. Love
Speaker 3: the new World Order.
Speaker 1: Now with dot net nine.
Speaker 2: Yeah, well, and in the cloud, you're crazy not to
Speaker 2: run it on Linux. Run dot nen olynux. It's a
Speaker 2: twenty five percent discount if you do.
Speaker 1: It and add dot Net nine into the mix and
Speaker 1: using what eighty percent less memory or something crazy like that.
Speaker 1: Dot Net nine uses so much less memory.
Speaker 3: So I'm not I'm not really running apps in production
Speaker 3: to know that, but I can say every time we
Speaker 3: get a new dot net version, my build times go down. Yeah, yeah,
Speaker 3: cannot complain.
Speaker 2: And you and run times are faster like they really,
Speaker 2: I don't know how they can keep this up. Is
Speaker 2: there a law? Is there a law of this? At
Speaker 2: some point it's only one bit being flipped, and that's
Speaker 2: just not enough.
Speaker 1: There it is Campbell's law right there. Yeah, you heard
Speaker 1: it here. First, we will continue optimizing until there's only
Speaker 1: one bit.
Speaker 2: Yeah, down to a bit. Wait, we were going to
Speaker 2: talk about something today, I'm sure what we were.
Speaker 1: We were vertical architecture with some thing you expressed an
Speaker 1: interest in.
Speaker 3: Well, it's taking out the vertical slice architecture. But so
Speaker 3: this might be a sequel to a sequel or continuation
Speaker 3: in the last time time I got together with you
Speaker 3: got it? M h. So the phrase vertical slice architecture,
Speaker 3: it's popularized by by Jimmy Boguard in the dot net space.
Speaker 3: It's you know, it's very very tightly associated with mediator.
Speaker 3: Of course, Wolverine supports it, supports it quite differently potentially,
Speaker 3: but I guess maybe stop and you know, to explain
Speaker 3: what it is. I always got to stop and contrast
Speaker 3: it to what's coming before or what's really the state
Speaker 3: of the art, at least a few years ago. I'm
Speaker 3: sure you guys have plenty of shows with folks coming
Speaker 3: on to talk about clean architecture, onion architecture, extagonal ports
Speaker 3: and adapters, done it right. I've been there, done now.
Speaker 3: So they're very well meaning attempts to try to, you know,
Speaker 3: establish a kind of a standard for a team get
Speaker 3: better results of we want to disentangle business logic from infrastructure.
Speaker 3: We'd like to make things testable. And then folks started
Speaker 3: to throughout all of these enterprise architecture templates, these prescriptive
Speaker 3: you know, look at my repository and I'll tell you
Speaker 3: the emptying projects. You have to divide things into the
Speaker 3: rules of what things are called, how they're divided. You
Speaker 3: know where this goes. So I think we took a
Speaker 3: couple of wrong terms. We you know, first thing we
Speaker 3: did is these these temples tend to focus too much on,
Speaker 3: you know, the nouns of the system. I have an
Speaker 3: invoice controller that talks to an invoice service that must
Speaker 3: talk to an invoice repository, and they've all got to
Speaker 3: be an emptying different.
Speaker 1: Projects, right, an email sender.
Speaker 3: Yeah, and you know every system, every enterprise system, grows
Speaker 3: until there's messaging service right right. Yeah, I've done lots
Speaker 3: of those. But you know, it's made us kind of overemphasized,
Speaker 3: maybe throwing in a lot of abstractions. You know, we
Speaker 3: we maybe took a little too seriously the idea that
Speaker 3: it has to be possible to swap out your infrastructure
Speaker 3: at a moment's notice, which you know nobody really does
Speaker 3: are very rarely right. So what happens in bigger enterprise
Speaker 3: systems is you get these huge horizontal layers where every
Speaker 3: use case has to bounce through all of these separate layers,
Speaker 3: and it becomes very difficult to reason about a single
Speaker 3: use case. It's all scattered around, right. You can't really
Speaker 3: update anything anyway, even though you have these abstractions, because
Speaker 3: it's a full project to replace the database or upgrade
Speaker 3: a technology. It's just too bit So. The kind of
Speaker 3: Reacto logical reaction to that is the idea of a
Speaker 3: vertical slice architecture we are going to take. We're going
Speaker 3: to primarily organize code, and here I'm just talking about
Speaker 3: how we situate code. I'm not even really talking about
Speaker 3: changing the basic constructions or anything like that, but we're
Speaker 3: going to try to lean towards organizing code around use
Speaker 3: cases or especially works well with cqurs. I'm going to
Speaker 3: organize code around the command and everything it takes to
Speaker 3: handle that command or ACQUERI and everything that they square it.
Speaker 3: The general idea is I'm going to take things that
Speaker 3: are closely related and I'm going to put them together,
Speaker 3: and things that are not related, I'm going to spread
Speaker 3: them out.
Speaker 1: Right, So the vertical slice is starts when somebody clicks
Speaker 1: a button, let's say on the website and ends when
Speaker 1: there's a result, an end result, whether that goes through
Speaker 1: a queue or through databases and all these other services,
Speaker 1: all those things happen in one place that isn't shared
Speaker 1: with the other slices.
Speaker 3: So I won't go so I will go all the
Speaker 3: way to that extreme. I mean, I would say it's
Speaker 3: perfectly valid to share some helper code. But yeah, so
Speaker 3: I really think of it as like a single web request.
Speaker 3: You're issuing a create invoice or approve invoice command to
Speaker 3: an HP endpoint. So everything that it takes to fully
Speaker 3: apply that, you know, whatever data you need to fetch,
Speaker 3: reading the HP validation business rules, it might have to
Speaker 3: happen in finally, persistence, if you were using you know,
Speaker 3: Woolring for example. Our idiom is to try to push
Speaker 3: you to really do that in one code file.
Speaker 2: So, I mean, are you talking about everything through all
Speaker 2: of those layers just being a single apply.
Speaker 1: Well, you're you're separating the UI though, right.
Speaker 3: Yeah, yeah, if it's small enough.
Speaker 1: Yeah.
Speaker 3: Yeah. I'm a I'm a back end guy. Oka, yeah, Okay,
Speaker 3: nobody would let me do front end work unless you
Speaker 3: you're desperate.
Speaker 1: Yeah, I don't think you'd want to put that in
Speaker 1: your UI. Yeah.
Speaker 3: No, no, no, no no, I mean that there's a
Speaker 3: there's a fallow up conversation. Get somebody on to talk
Speaker 3: about composite UI someday. But that's okay. So if it's
Speaker 3: if the use case is small enough, I mean, if
Speaker 3: it gets big, and you know it's probably with all
Speaker 3: those prescriptive templates, they blow up. Is sometimes a particular
Speaker 3: use case may be too big, and then you start
Speaker 3: splitting things up helpers, maybe you draw out split off
Speaker 3: message handlers. But what we're doing with vertical slice is
Speaker 3: we're saying, you know, we're not so worried about necessarily
Speaker 3: swapping out infrastructure. But I'll come back to that. What
Speaker 3: you want, though, is you want to make it as
Speaker 3: easy as possible to reason about what is happening in
Speaker 3: my system from this input to the outputs it makes
Speaker 3: because the business logic changes all the time. Yeah, and
Speaker 3: that's where your bug fixes are going to go.
Speaker 1: So you're saying, if you have everything in one file,
Speaker 1: you don't have to step through the debugger and find
Speaker 1: out which modules are being touched in which where they're coming.
Speaker 1: And then now you've got this mental list of all
Speaker 1: these places where you have to make changes. It's all
Speaker 1: in one file.
Speaker 3: In the ideal and the ideal you know some things
Speaker 3: are going to be too big for that yet out.
Speaker 3: But yeah, now to your point, I mean to go
Speaker 3: into apostasy here. You know, if you're doing it to
Speaker 3: Wolverine style, we're going to push you to ditch repository layers. Well,
Speaker 3: at least as a go to default move. There's always
Speaker 3: exceptions to directly utilize. If you're using a core use
Speaker 3: the dB context. If you're using Martin Martin, you're going
Speaker 3: to use I Document Store, Die document session directly with
Speaker 3: a huge caveat here. You know, in our case, we
Speaker 3: want it still to be in one file, but we'll
Speaker 3: take other steps to isolate the business logic code away
Speaker 3: from infrastructure so you can and kind of I'll come
Speaker 3: back to that, but to be able to go right
Speaker 3: down to the metal so you can use every last
Speaker 3: bit of power in your data persistence tooling. You know
Speaker 3: you need to fiddle with lazy versus eager fetching to
Speaker 3: be faster. You need to batch up quaring to be faster.
Speaker 1: Would you still want to use a CRUD interface. I mean,
Speaker 1: that's the essence of what a repository is. Isn't it
Speaker 1: so that you could swap out whatever you know, database
Speaker 1: back end for testing memory repository for example.
Speaker 3: Okay, so this is the part where people are going
Speaker 3: to give you angry comments later, right, No, please bring
Speaker 3: it on a little bit controversy. So we've got two
Speaker 3: issues here. You know, on one hand, what are we going
Speaker 3: to do to be able to swap out infrastructure? Right?
Speaker 1: Mm hmm.
Speaker 3: We're going to put a pin in that and come
Speaker 3: back to it.
Speaker 1: Okay.
Speaker 3: Second point is how do I make code testable? Yeah, so,
Speaker 3: especially with the wolverine style, we're leaning really heavily into
Speaker 3: an idea from Jim Shore called the A frame architecture.
Speaker 3: So in the show notes all I'll sen Joe Link
Speaker 3: there's a paper called Testability without Mocks. I recommend to
Speaker 3: everybody who works with me sooner or later the A
Speaker 3: frame idea like that. Now, if you're talking about, say
Speaker 3: we're building a wolf wearine handler, either an h should
Speaker 3: be handler or a message handler. That is mean. Let's
Speaker 3: say it's a proven invoice, right, so you probably need
Speaker 3: to go get the current state of the invoice because
Speaker 3: you may need to look at it. Is it already approved,
Speaker 3: is everything done? Has you know everybody signed off? Whatever
Speaker 3: it takes, and then decide, decide your business logic, decide
Speaker 3: what do I knew? Next do I decide to approve
Speaker 3: it and go on and maybe send out other fall
Speaker 3: up messages or not, and then finally persist it. So
Speaker 3: coming to this idea of an A frame, I'm not
Speaker 3: gonna worry about interfaces and mock objects or stubs or
Speaker 3: fakes or anything like that. We're going to divide things
Speaker 3: up into like kind of a controller on top, the
Speaker 3: a guy at top. He is going to reach into
Speaker 3: data persistence. He's going to grab the invoice data for you,
Speaker 3: push it into the business logic. Business logic. In the
Speaker 3: case of Wolverine, we're pushing really hard. We want it
Speaker 3: to be a pure function.
Speaker 1: Now you keep mentioning Wolverine, but what if people don't
Speaker 1: use Wolverine and aren't really familiar with it. How can
Speaker 1: you give us an example that doesn't use Wolverine.
Speaker 3: Actually, it's just extracting methods. So whether this was mediator
Speaker 3: or whatever, it's going to be, just say say you
Speaker 3: have a mediator handler and in service bus handler, mass
Speaker 3: transit handler, or just just an MVC controller endpoint. What
Speaker 3: you're really going to do is just build off some
Speaker 3: some helper methods and that's it. So one method is
Speaker 3: the controller, NVC controller is going to talk to E
Speaker 3: of Core maybe and pull out the invoice information for you, ok. Right,
Speaker 3: and then it's going to call into a method that
Speaker 3: is your actual business logic. Who say, here's the command
Speaker 3: somebody wants to prove this invoice, and here is the
Speaker 3: current state of the invoice. And out of that pure function,
Speaker 3: you tell me what to do next. You're going to
Speaker 3: return some kind of result that is, here's an event
Speaker 3: sourcing It could be here's an event I want you
Speaker 3: to append invoice approved or approval rejected, whatever it's going
Speaker 3: to be, or maybe something that reflects what to do next.
Speaker 3: Now our business business function here I keep saying pure function.
Speaker 3: You know we're gonna we're gonna dive into functional programming
Speaker 3: world a little bit. People are gonna make fun of
Speaker 3: me for this.
Speaker 1: Now, nobody's making fun of you, dude, nobody.
Speaker 3: No, people will on Blue Sky later.
Speaker 1: So nobody.
Speaker 3: We want to isolate that business logic or it's not
Speaker 3: depending on services, there's no interfaces to mock it's just
Speaker 3: if you have this state in this command, what do
Speaker 3: you do next? You get you get business logic in
Speaker 3: place where it's really easy to unit test, no mock
Speaker 3: set up, no crazy stuff, no in memory database, I
Speaker 3: don't care. And in the last step, you know, the
Speaker 3: A frame the controller is like I'm getting stuff for you.
Speaker 3: I'm pushing into business logic and I'm taking what you
Speaker 3: decide to do next, and then I'm persisting it back
Speaker 3: to ef core maybe or Martin or whatever it is,
Speaker 3: and I'm sending out extra messages. So the A frame architecture,
Speaker 3: it is really a coding approach, but it's a way
Speaker 3: to isolate your business logic without having to throw in
Speaker 3: a lot of abstractions, a lot of indirections and throwing out,
Speaker 3: you know, five different projects like you would in onion architecture.
Speaker 1: Right, it simplifies because that that is the fundamental problem
Speaker 1: of all these architectures is that they complicate things and
Speaker 1: they add all these layers of abstraction for the purpose
Speaker 1: of what for you know, for for making it flexible.
Speaker 1: But then something is ultimately flexible, it's ultimately difficult to.
Speaker 3: Use it is now back to rewind to the point
Speaker 3: and you're you. I think you were correctly challenged. Well,
Speaker 3: what if I want to swap out my database? Yeah, yeah,
Speaker 3: which you're unlikely to do, but you could, so.
Speaker 2: I always finally, swap out the database defense a weak defense.
Speaker 2: It's like, you're probably not going to do that.
Speaker 3: You can't. You can't because if you have a big
Speaker 3: enough project and it's a flat layer, you can't because
Speaker 3: that's going to be an entire project to do a
Speaker 3: full regression testing cycle, and most people can't do it.
Speaker 3: Your business partners will never let you do.
Speaker 1: That, all right, But here's a I can give you
Speaker 1: an example where you would use a repository pattern basically
Speaker 1: a cred interface, right is use you could use the
Speaker 1: same interface on a client to create a repository that
Speaker 1: calls makes all your API calls, and you could use
Speaker 1: the same interface on that same client to do something
Speaker 1: against the client side database that I can't even remember
Speaker 1: the name of it now because I'm stupid, But I
Speaker 1: dB something dB all right.
Speaker 3: Well just local storage?
Speaker 1: Sure, yeah, look not local storage, but there's another there's
Speaker 1: another database that's built in a new browser. You can
Speaker 1: do that, right and on the back end, if you
Speaker 1: wanted to run things against repository that just uses memory
Speaker 1: collections to test all your stuff. But I think that
Speaker 1: is where you brought up another another thing that you
Speaker 1: can test without mocking and test without memory databases and things.
Speaker 3: Yes, so I want to test, be able to test.
Speaker 3: I would really want to be able to test the
Speaker 3: business logic without without having to do a bunch of
Speaker 3: mock setups. You know, if you are as old as us,
Speaker 3: and I don't think you have to be anywhere near
Speaker 3: as old as US, You've dealt with code bases where
Speaker 3: the unit tests were unusually hard to work with because
Speaker 3: there was too much reliance on mocking libraries or fakes,
Speaker 3: and those tests become very hard to reason about. They
Speaker 3: become very brittle because you'reation is too tightly coupled to
Speaker 3: the luck the system so indexed dB.
Speaker 1: That's what I was trying to remember.
Speaker 3: Sorry, gotcha, gotcha. I've read about it, never used it.
Speaker 3: So a couple of things. The I think your example
Speaker 3: of using a repository, I think that's perfectly valid as
Speaker 3: far as swapping out the technology. So the single I
Speaker 3: think the single best thing you can do to make
Speaker 3: your technology swappable is to invest very heavily in having
Speaker 3: a very effective test automation infrastructure. That's the one thing
Speaker 3: that's going to give you enough feedback to do this,
Speaker 3: because you can't just swap out interfaces if you can't
Speaker 3: test your app very fast. Right, that's one thing we
Speaker 3: keep touching on modular monolith a little bit. And I
Speaker 3: think all this is related. I don't think if you
Speaker 3: have a big system, it's impossible. It's effectively impossible to
Speaker 3: swap out infrastructure in most project planning. But if you
Speaker 3: have a way where you could do it bit by
Speaker 3: module by module, maybe you could pull that off. Or
Speaker 3: if you keep upgrade from whatever SQL server to sql
Speaker 3: server to postgraphs for the cheap or hosting, or move
Speaker 3: to a different no SQL database or get off Mango
Speaker 3: dB or whatever it is, maybe you can do it
Speaker 3: one module at a time. Right, a couple other things,
Speaker 3: you know, diving into things like performance and whatnot. These
Speaker 3: database engines, they do not work the same way at all.
Speaker 3: Ef core might be a perfectly good abstraction over relational databases,
Speaker 3: which are much more similar than not. I mean, maybe
Speaker 3: you can go from SQL server to postcraph, but going
Speaker 3: from a relational database to a no SQL database. That's
Speaker 3: a very different ballgame. The same abstractions are not going
Speaker 3: to work, even the link the link providers, there are
Speaker 3: a lot of extensions. You know, people use these repository
Speaker 3: abstractions where they let iqueriable link leak out that that's
Speaker 3: probably a terrible idea.
Speaker 1: Yeah, they no good, that's a terrible idea. And and
Speaker 1: by the way, it doesn't work.
Speaker 3: It doesn't work.
Speaker 1: Inquible requires code, doesn't it. So it does, but it's
Speaker 1: not data.
Speaker 3: To make it fast, your equeriable is going to need
Speaker 3: a lot of tool specific usage in a lot of cases.
Speaker 1: Yeah, you can't just pass that from a to a
Speaker 1: client from an API controller. Yeah, so ask me how
Speaker 1: I know.
Speaker 3: Everybody's done that. One I try to the testability point
Speaker 3: you brought up. He's like, of course people get excited
Speaker 3: about the in memory provider. It's going to behave very
Speaker 3: differently than your real database. It will give you false positive.
Speaker 3: So another thing I'm going to say is when you're
Speaker 3: picking technologies, you very purposely try to pick technologies that
Speaker 3: have a very good testability story, right, that play very
Speaker 3: nicely inside of automated testing, which is to put my
Speaker 3: money where my mouth is on that one, taking Martin
Speaker 3: as either document store or it store. Martin has built
Speaker 3: in functionality to set up databases on the fly if
Speaker 3: you're in development or testing time, and it has the
Speaker 3: ability to wipe your database out in one command line.
Speaker 3: The point being here is it's just it's actually much
Speaker 3: friendlier inside of an integrated test harness then we would
Speaker 3: have been used to twenty years ago, where that was
Speaker 3: almost impossible.
Speaker 1: Yeah. Hey, getting back to my love for repositories. One
Speaker 1: of the things that I do is I have a
Speaker 1: an EF repository that's generic, and then I have a
Speaker 1: generic Dapper repository. I have a GENERICADO dot net by
Speaker 1: itself repository. And that's good because you know, if you
Speaker 1: start out with a customer and they like EF and
Speaker 1: then there's something, something happens, something whatever, and they're like, no,
Speaker 1: we don't like this anymore, we want to move to
Speaker 1: ado dot net. Well, then I'll try Dapper. Right. So
Speaker 1: I'm not really changing the database per se, I'm changing
Speaker 1: the code that accesses the database, and so that's one
Speaker 1: of the reasons why. But I want to get your
Speaker 1: reaction to this after the break, which we're doing right now.
Speaker 1: We'll be right back dot net rocks. Hold on, We'll
Speaker 1: be right back. Did you know there's a dot net
Speaker 1: on aws community. Follow the social media blogs, YouTube influencers
Speaker 1: and open source projects and add your own voice. Get
Speaker 1: plugged into the dot net on aws community at aws
Speaker 1: dot Amazon dot com, slash dot net. It's dot net rocks.
Speaker 1: I'm Carl Franklin. That's my friend Richard Campbell hey, and
Speaker 1: our friend Jeremy Miller. And want your reaction to uh
Speaker 1: to my love of repositories again and then we'll get
Speaker 1: off this. I swear to God.
Speaker 3: No to today's point, what if you want to switch
Speaker 3: quickly between dapper rideo, dot net or Core, or you
Speaker 3: would to go to old school and bring in hibernade
Speaker 3: back because that does still work.
Speaker 1: I have no idea what you're talking about.
Speaker 3: So if you're doing that, I think you're in a
Speaker 3: world of I think that might apply well to more
Speaker 3: of a creud centric world where I'm editing in order
Speaker 3: at a time I'm adding a you know, an invoice
Speaker 3: at the time. You know, I hate the phrase pick
Speaker 3: the right tool for the job, but pick the right
Speaker 3: tool for the job. Most of what I'm talking about
Speaker 3: I do deal with larger systems with a lot more workflow,
Speaker 3: a lot more complexity than a CREUD system. So what
Speaker 3: you're talking about, I think that's fine for something that's
Speaker 3: mostly about editing data. But right off the bat, so
Speaker 3: you know Richard's an old database guy.
Speaker 1: You mean old.
Speaker 3: Is not.
Speaker 2: So no older than you?
Speaker 3: There are these by two weeks you can write really
Speaker 3: bad database you know, database sequel queries. My experience can't
Speaker 3: speak for everybody else. My experience, by far away, the
Speaker 3: worst cause of very poor performance with the database is
Speaker 3: being chatty, making way too many calls back and forth
Speaker 3: to the database, even to the point where you know,
Speaker 3: in these layering things where you might be calling for
Speaker 3: the same data over and over and over again and
Speaker 3: you don't even know it because you can't see it. So,
Speaker 3: taking that as an example, say you have this is
Speaker 3: pretty common. You have a web request and then the
Speaker 3: course of handling it, you need to look up three
Speaker 3: or four different entities at a time. Sure, right, and
Speaker 3: if you take some kind of repository abstraction approach, you're
Speaker 3: you don't have to do this, but you probably fall
Speaker 3: down that path of having a totally separate repository for
Speaker 3: each and right common. That's almost forcing you to do
Speaker 3: a very naive, least common common denominator approach of I'm
Speaker 3: going to go roll a one and load the second
Speaker 3: and load the third. You may be doing it in
Speaker 3: plus one.
Speaker 1: Yeah, absolutely, Yeah, there's there's a lot of there's a
Speaker 1: lot of queries that just don't that doesn't fit. Yeah.
Speaker 1: I mean that that's why we have STAR procedures, isn't it.
Speaker 1: You know, we have a procedure that gets Okay, he's
Speaker 1: just wincing. Now, he's wincing. He's he's got his fingers
Speaker 1: over his eyes.
Speaker 2: It's a polighter way to say that, which is there
Speaker 2: is an opportunity for DBAs to provide optimizations to you.
Speaker 1: Yes, yes, yes, of course, I mean that this is
Speaker 1: one of the reasons why STAR procedures exist, right besides
Speaker 1: the exist you know, came into being, shall I say,
Speaker 1: because of the abstraction one, but also because we could
Speaker 1: do complex queries in return complex result sets.
Speaker 3: So technically yes, but to our point about trying to
Speaker 3: prefer tools that give you easier and easier time in
Speaker 3: integration testing. Sure, if you're depending on stored procedures and
Speaker 3: for procedures with logic, you have made your code as
Speaker 3: hard to test as I possibly can.
Speaker 1: I totally agree, and I have since sworn them off. Jeremy,
Speaker 1: I have I swear to God.
Speaker 2: Now and start procedure should be the exception, like, we
Speaker 2: can't seem to make this go any faster. What do
Speaker 2: we got to do? And the DBA can help.
Speaker 3: Yes, But the point, the point I was getting at
Speaker 3: is but I also say, you're using a no SQL
Speaker 3: database yep. Or you know, for me, Mark, most of
Speaker 3: my clients are using events store. One where using an
Speaker 3: event store tool, so you're dealing with projections and all
Speaker 3: kinds of things.
Speaker 1: Yeah.
Speaker 3: The point is your underlying tool has probably has some
Speaker 3: kind of special sauce power to do batch Quarry Martin,
Speaker 3: for example, will let you line up I want to
Speaker 3: run this link, quarry this link, query, load this entity,
Speaker 3: load that entity, or and go do it in one batch.
Speaker 3: But I'll also say I want to load this entity,
Speaker 3: but I want you to find its related thing here
Speaker 3: and it's third related thing and do it in one
Speaker 3: network round trip. That is a massive cost savings in
Speaker 3: terms of performance. Sure, so being able to go right
Speaker 3: to the metal, you're not really going that close but
Speaker 3: using all the power that you're underlying infrastructure has and
Speaker 3: then putting it in one vertical slice where you can
Speaker 3: actually reason about what are the database queries I'm actually
Speaker 3: making from this system input to get my data out.
Speaker 3: That's going to be the best possible chance of getting
Speaker 3: something that's very performant.
Speaker 2: Can we talk about the second vertical slice you're going
Speaker 2: to take like you talk about the vertical slice approach
Speaker 2: to get started. Essentially, let's get something running a particular
Speaker 2: feature set and and you know, one time, even an
Speaker 2: agile we want to call that a spike, like we're
Speaker 2: gonna test this thing. My concern with this approach is
Speaker 2: always then more teams start working on their slices and
Speaker 2: we're duplicating work, or we're coming with different styles, or
Speaker 2: you know, they don't ever play with each other very well.
Speaker 3: So a lot that's going to boil down to communication.
Speaker 3: But that also gets into a conversation I did want
Speaker 3: to I did want to have with you guys. You know,
Speaker 3: the folks that really like to have those prescriptive architectures.
Speaker 3: Some of it is about standardization and take away. People
Speaker 3: need to be creative or think kind of kind of
Speaker 3: straight jacket in into doing a one one wayfect.
Speaker 2: Right that there is one right way for this app.
Speaker 3: Yeah, so I'm gonna give you a sports fan, right,
Speaker 3: and if you follow your team long enough, you're gonna
Speaker 3: hear the phrase a lot of this player is a
Speaker 3: high I four player or this other player could raise
Speaker 3: the ceiling of the team. And all is when we
Speaker 3: talk about a player's floor ceiling, you kind of say
Speaker 3: we expect to be at least this good. That's the floor.
Speaker 3: When you say raising the ceiling, we could potentially be
Speaker 3: even this much better. Folks that really care about standardization
Speaker 3: across teams, they're trying to raise the floor. They're trying
Speaker 3: to say I want a minimum quality by saying everybody
Speaker 3: just do it the exact same way. Theoretically you can
Speaker 3: move around. People don't have to think so much. They
Speaker 3: can just go. There's obvious value, there's obvious attraction. The
Speaker 3: only problem is that it doesn't work very well. Righthew,
Speaker 3: you get these these one size fits all templates, what
Speaker 3: happens is you get use cases that are vastly more
Speaker 3: complicated than your clean architecture approach. Shows if you make
Speaker 3: people stop thinking like I'm straight jacket into this approach,
Speaker 3: they stop thinking and they start writing just those massive,
Speaker 3: bloated NBC controllers which to mediator pulling it out, and
Speaker 3: now you have bloaded mediator handlers. People forget to do
Speaker 3: things like I'm just going to extract a helper method
Speaker 3: out and compose my method. Or you on the other
Speaker 3: side of things, your prescriptive template may be more complicated
Speaker 3: than it should be, and you get a lot of
Speaker 3: straight pastors. I've seen that as well.
Speaker 2: So now this is always a challenge. If it's simple
Speaker 2: enough to use, it's not sophisticated enough to do what
Speaker 2: you need to do. And if it's sophisticated enough to use,
Speaker 2: it's too complicated to understand.
Speaker 3: So you know, the duplication, I mean, that's a real problem.
Speaker 3: That's absolutely a legitimate, legimate concern. What I would say
Speaker 3: is communication between teams. Hopefully your team is still working
Speaker 3: in a you know, it's kind of a DIT style
Speaker 3: bounded context where they have an isolated PURBUW to some degree,
Speaker 3: and then there's not much natural duplication except in infrastructure,
Speaker 3: you know, being able to rotate around teams. You know,
Speaker 3: this is this is orthogonal to architectural style in places
Speaker 3: where you do see duplication in code, you start to
Speaker 3: do some refactorings to gather up the duplication, just like
Speaker 3: we've always done.
Speaker 2: In some ways, I can almost see you describing this
Speaker 2: as a good problem. You've gotten to a place where
Speaker 2: you've built enough that they can see the duplication, and
Speaker 2: now you can put an initiative to try and consolidate
Speaker 2: that and make things a bit more Yes, I would
Speaker 2: also think the first slice you pick in a green
Speaker 2: field app is going to set the tone, so pick carefully.
Speaker 3: Maybe maybe yeah, But taking this, you know, down the
Speaker 3: people side of things, you know, rather than saying, here's
Speaker 3: this very limited straight jacket rule of you know, we
Speaker 3: downloaded somebody's GitHub repository that lays out a clean architecture
Speaker 3: or something or other. Right, having a constant learning environment
Speaker 3: where your people are empowered to learn an experiment a
Speaker 3: little bit, as long as you can trust that they'll
Speaker 3: communicate with each other, so that that's what I would
Speaker 3: describe as raising the ceiling of your your shop. You know,
Speaker 3: you have a chance to do things much better.
Speaker 2: I mean, I think it's reasonable set minimums, but don't
Speaker 2: don't require where people stay at the minimums like I
Speaker 2: think I have to enough smart enough to go when
Speaker 2: to know when they're going below it, but not be
Speaker 2: concerned when they go above it, because that's ultimately a.
Speaker 3: Good thing, definitely that. And then all of us learn.
Speaker 3: If you're ever a technical lead, so here later you're
Speaker 3: going to learn a hard rough lesson that. The more
Speaker 3: specific direction you give to somebody working with you, the
Speaker 3: worse the results are coming back. Sure, because if you
Speaker 3: turn off the brain, you make them just.
Speaker 2: You know, I've seen Carl do this with music, where
Speaker 2: he pointed the bass player and said, just be awesome.
Speaker 1: Just be awesome. That's a true story, the true story.
Speaker 1: He says, what do you want me to play here?
Speaker 2: He was awesome?
Speaker 1: Said I said, just be awesome, and he.
Speaker 3: Was, yeah, that's awesome.
Speaker 2: But you know, I can think of some devs where
Speaker 2: he's that's all you need to tell him is, hey,
Speaker 2: just be awesome.
Speaker 1: Just be awesome. Don't write bugs.
Speaker 3: Well, yeah, and then then let me let me rain
Speaker 3: some of that in of you know. Also, folks, don't
Speaker 3: don't get too creative, don't get too crazy. No matter
Speaker 3: what tool you use, use it in the idiomatic way.
Speaker 3: Don't write your own special frameworks, that kind of thing.
Speaker 1: I remember the Onion article Apple employee fired for thinking
Speaker 1: too different.
Speaker 2: The way I always pitched it to my devs was,
Speaker 2: I want you to be able to take a vacation,
Speaker 2: so somebody else needs to be able to read this code. Yeah,
Speaker 2: that's right. Motivation just you know, give yourself, be able
Speaker 2: to give yourself a break.
Speaker 3: So running right back to our vertical slice architecture idea,
Speaker 3: we are trying very hard, you know, and again I'm
Speaker 3: so plugging it. The approach we're taking with Wolverine, especially,
Speaker 3: shrink your code down, take out so much code ceremony
Speaker 3: that you can hopefully very easily reason about your system
Speaker 3: follow one place. There's less code period, there's less hoops
Speaker 3: to jump through, and even a strange person could come
Speaker 3: in as as they are a developer, they can see, yeah, right,
Speaker 3: understand how it's working top to bottom.
Speaker 2: I get this. Yeah, and so maybe you can actually
Speaker 2: take two weeks off and the world doesn't hold still
Speaker 2: or burn to the ground.
Speaker 3: I'll let you know if I ever do.
Speaker 2: I always thought it was a good milestone, right, was like,
Speaker 2: are we functioning enough of the team that somebody can
Speaker 2: go away for a while, and not that we don't
Speaker 2: burn to the ground, or even that we can hold
Speaker 2: everything still, but that we still made progress without them. Yeah,
Speaker 2: they came back to not an inbox that killed them,
Speaker 2: that punished them for taking their time off.
Speaker 3: I I think I've told this story before. The first
Speaker 3: project where I was a technical lead on a project
Speaker 3: that was actually important, all of my managers, two or
Speaker 3: three times a day would ask me, well, what are
Speaker 3: we going to do if you get hit by a bus?
Speaker 2: Right?
Speaker 1: That's the very real thing.
Speaker 3: And I heard that so often that I started seriously
Speaker 3: pondering my own mortality.
Speaker 2: Yeah, and it got it. You want to hit the
Speaker 2: bus so bad?
Speaker 1: Isn't that one of Steve Smith's anti padd or whenever?
Speaker 2: The bus being hit by bus is definitely an anti pattern.
Speaker 3: No, no, no, but you know the one bus, the
Speaker 3: one bus, low bus factor.
Speaker 2: Yeah, that's it, Yeah, low bus factor. But that's why
Speaker 2: I went with the vacation scenario, because it seems less
Speaker 2: you know, mortally threatened.
Speaker 1: It's less morbid. It's a very Canadian approach to that metaphor.
Speaker 3: I was just gonna say, I'm an American. I don't
Speaker 3: know what a two week vacation would be. Yeah, I
Speaker 3: mean I've had one once.
Speaker 1: Maybe right, better software through politeness, just.
Speaker 2: Trying to keep people healthy and happy. You know, the
Speaker 2: death We took over a team that had been death
Speaker 2: marching for like six months and they and the boss
Speaker 2: is like, what do you suggest this is? I'm thinking
Speaker 2: a three week I think a three day weekend first, like,
Speaker 2: just send everybody home for three days, take a breath,
Speaker 2: will We'll reorganize next week. Absolutely, you know, you can't
Speaker 2: just keep beating people. We're not making progress anymore and
Speaker 2: everyone's miserable. Got to get up and take a walk
Speaker 2: once in a while.
Speaker 3: I really say, I haven't been on a death march
Speaker 3: in a few years, but I certainly did my share
Speaker 3: of them back in the Waterfall doos.
Speaker 2: Yeah. Well, and it's one of those things where everybody's
Speaker 2: built their parts and you've tested in various bits and
Speaker 2: now you're trying to really get to a deployment and
Speaker 2: does it actually scale away it's supposed to behave and
Speaker 2: are the people happy with it? And then it's patch
Speaker 2: patge patch, like what are we missing trying to get
Speaker 2: to that magic V one that somebody promised on an
Speaker 2: arbitrary date. They didn't understand.
Speaker 3: Yeah, yeah, or the day as a tech lead, the
Speaker 3: tester asked me, what about the reports from the requirements?
Speaker 3: And I don't know what you're talking about. And there
Speaker 3: was a second requirements document I had never been shown
Speaker 3: until then. Yeah, and we were already in the official
Speaker 3: testing phase.
Speaker 2: Yeah, surprise. Yeah, I should have known about this a
Speaker 2: year ago.
Speaker 3: Waterfall for the win.
Speaker 1: Abbreviated WTF waterfall? What's in your inbox? Jeremy, what are
Speaker 1: you going to do next?
Speaker 3: So probably won't show up in a conference until till
Speaker 3: later next year. I did so many late last year
Speaker 3: that I'm didn't get get submissions off. But the big
Speaker 3: thing I'm working on right now in my company, jazzper
Speaker 3: Effects Software, working on a tool called critter Watch that
Speaker 3: is a commercial management console monitoring tools specifically for the
Speaker 3: entire Critter stack, So everything you would need to not
Speaker 3: just watch what's going on your system, but also be
Speaker 3: able to help heal the system, deal with did letter
Speaker 3: Q messages. Eventsourcing creates all kinds of extra stuff, problems
Speaker 3: of being able to kick off projection, rebuilds, rewind subscriptions,
Speaker 3: turn things on, change how change what servers things are
Speaker 3: running on? Maybe to deal with privacy concerns, be able
Speaker 3: to retroactively say we're going to do something called crypto shredding.
Speaker 3: We're just going to throw away the key so we
Speaker 3: can't read this client data anyway. You know, all kinds
Speaker 3: of good stuff like that. So trying to make the
Speaker 3: jump from you know, we're a services company around open
Speaker 3: source tooling right now, but we want to make the
Speaker 3: jump to also having that paid commercial add on that.
Speaker 1: That's very cool, cool. Well, hope you come back and
Speaker 1: talk to us when that's in play, you know, or
Speaker 1: if you have any other things that are new, just
Speaker 1: feel free to reach out and come back on the show.
Speaker 3: All right, we'll certainly do that, guys.
Speaker 1: It's always a pleasure.
Speaker 3: Thanks thanks for having me.
Speaker 1: That's been a pleasure for us too, And we'll talk
Speaker 1: to you next time on dot net rocks. Dot net
Speaker 1: Rocks is brought to you by Franklin's Net and produced
Speaker 1: by Pop Studios, a full service audio, video and post
Speaker 1: production facility located physically in New London, Connecticut, and of
Speaker 1: course in the cloud online at pwop dot com. Visit
Speaker 1: our website at d O T N E t R
Speaker 1: O c K S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code.
Speaker 1: See you next time.
Speaker 3: You got javans
Speaker 2: And no