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, welcome back to dot net rocks. I'm
Speaker 1: Carl Franklin and I'm Richard Campbell, and we're here for
Speaker 1: your geek out pleasure. Not yet, no official geekout, but
Speaker 1: you know we're gonna there coming. We're gonna geek out
Speaker 1: with our guests.
Speaker 2: Now. There's so much to talk about. I can't even
Speaker 2: tell you. I've been writing and writing and writing and writing.
Speaker 2: They're gonna be long. Sorry, they're gonna be long.
Speaker 1: Yeah, I think everybody looks forward to that at the
Speaker 1: end of the year. Richard, I certainly do.
Speaker 2: I appreciate that. I told you I've I've made a
Speaker 2: new talk just on nuclear power.
Speaker 1: Yeah, there's a lot of new stuff.
Speaker 2: And then suddenly all attack giants are talking about nuclear power.
Speaker 2: So everybody wants that talk. And it's a physics talk
Speaker 2: like I start with I pull up a periodic table
Speaker 2: and talk about the actinides and go through a decay
Speaker 2: pattern of you two thirty eight like it's.
Speaker 1: Okay, I'm going to have another sandwich.
Speaker 2: And but you know, it all pulls the story together
Speaker 2: and some interesting things happening in the space. But we'll
Speaker 2: talk about that on the Energy Geek go yeap.
Speaker 1: And first before we bring on Adam, let's do a
Speaker 1: little thing called better no framework awesome?
Speaker 2: All right man? What we got?
Speaker 1: Well, I want you guys to go to Boston dot
Speaker 1: Chef's makingwaves dot com.
Speaker 2: Nice. What is this?
Speaker 1: So this is a cruise and it's the same cruise
Speaker 1: company that does the rock Boat. I don't know if
Speaker 1: you've heard that no, but it's like you know, one
Speaker 1: hundred bands, oh all on a cruise and you see
Speaker 1: a different one like every different venues and stuff. But anyway,
Speaker 1: so this is a cruise from all up in New
Speaker 1: England Boston to Portland, Maine and Saint John, New Brunswick.
Speaker 1: It's in October October twenty fourth through twenty eight in
Speaker 1: twenty twenty five. And if you're a fan of you know,
Speaker 1: Food Network and Celebrity chefs like I Am.
Speaker 2: Back when Food Network actually talked about food.
Speaker 1: Alton Brown is going to be on this cruise.
Speaker 2: There you go, that's your ringer right there, right, Yep.
Speaker 2: We love Alton Brown. He's our kind of geek.
Speaker 1: And then as the Choi, Anne Burrell, Eric Adjepong, Roco
Speaker 1: de Spirito, Alex Gerna Shelley, Mark Murphy, Jeff Morrow, and Andrew Zimmern,
Speaker 1: Josh Capon, a couple other people that you may have
Speaker 1: or may not have heard of. Gabe Bertaccini, who does
Speaker 1: a show called chow House with Alex Cornishelly, it's just
Speaker 1: going to be great. And so you know, it's a
Speaker 1: cruise you have cooking demonstrations and dinners and food cooked
Speaker 1: in person by these people and reading the comments from
Speaker 1: last year. Some of them like to be a little
Speaker 1: more private than others and they don't really come out
Speaker 1: and greet and talk, but others will hang out with
Speaker 1: you like the whole time. Wow. So I'm just really
Speaker 1: really excited to go on this. I've actually bought a ticket,
Speaker 1: so oh you're going, I'm going. So if you want
Speaker 1: to go on this cruise with me, just get a ticket.
Speaker 2: Let me know that's really fun.
Speaker 1: So that's what I got. Who's talking to us today, Richard?
Speaker 2: I grabbed a comment Taver Show nineteen twelve, which is
Speaker 2: just back in August when we talked to Anita Vam
Speaker 2: about demain driven design and events sourcing, which I think
Speaker 2: will be somewhat orthogonal to the things you were talking about.
Speaker 2: Jaye Debauer had this comedy. He says, I've listened to
Speaker 2: every episode since sometime in twenty ten. Wow, so that
Speaker 2: would be you know, Got the Morning a thousand episodes easy,
Speaker 2: And you guys have had a huge impact on my career.
Speaker 2: So thanks. I have a reputation for coming into work
Speaker 2: and saying I was listening to dot at rocks And anyway,
Speaker 2: onto the real meat. We've been using aka dot net
Speaker 2: and event sourcing ideas that I need to talk about
Speaker 2: and it's a match made in heaven. All the positive
Speaker 2: things that I need to had to say, but wanted
Speaker 2: to point out one other benefit that's been very interesting.
Speaker 2: When you have an event store and an unexpected question arises,
Speaker 2: you can always write a bit of code to reprocess
Speaker 2: that event streamer streams to calculate the answer to a
Speaker 2: new question. I believe Anita mentioned the time travel or
Speaker 2: something like that, the events can always be replayed up
Speaker 2: to a desired time and allowing you to view the
Speaker 2: state as it was at the time. In my experience,
Speaker 2: the business is delighted when you can perform magic tricks
Speaker 2: like this. Thanks so much for the great show.
Speaker 1: Fantastic.
Speaker 2: Yeah, no, it's great. It is a great point about
Speaker 2: this different way of thinking about software that having event
Speaker 2: streams that you can store and replay just gives you
Speaker 2: all kinds of possibilities for tackling problems. It's certainly been
Speaker 2: something I've used when doing profiling for performance problems, where
Speaker 2: the fact that we could replay the workload and make
Speaker 2: some alterations replay the workload a n it taught us
Speaker 2: a lot. So Jay, thank you so much for your
Speaker 2: comment and a copy of music Cobi. It's on its
Speaker 2: way to you. And if you'd like a copy of
Speaker 2: music code by, I write a comment on the website
Speaker 2: at dot at Rocks dot com or on the Facebook
Speaker 2: to publish every show there. And if you comment there
Speaker 2: and I reading on the show, we'll send you copy
Speaker 2: of music Coba.
Speaker 1: Music to Koba of course still cranking and people love it.
Speaker 1: And yes, I do plan on coming out with another
Speaker 1: track taking next year. Yeah, I'm still tankling.
Speaker 2: That's all of that.
Speaker 1: But as for social media, Richard and I have been
Speaker 1: on ex Twitter for a long time. Maybe not for long,
Speaker 1: I'm not sure. But you can also Rea Stress on
Speaker 1: blue Sky, I'm Carl Franklin dot bsky dot social.
Speaker 2: And I'm rich Campbell dot bsky dot social.
Speaker 1: And also on Masterson I'm at Carl Franklin tech hub
Speaker 1: dot social.
Speaker 2: And I'm Rich Campbell at Masterdon dot social.
Speaker 1: Yeah. All right, well send us a toot a teat
Speaker 1: a suite or whatever the heck you call it. And
Speaker 1: that's another way that you could win some music to
Speaker 1: code by Skeat, I think is what they call.
Speaker 2: It's a skeet yep, it's I don't know if that's
Speaker 2: a great name, but it is what it is.
Speaker 1: John Skeet can't really take credit for that. That's like
Speaker 1: one thing that he can't take credit for. He's done
Speaker 1: everything else exactly. Okay, let's bring on Adam. Adam Dimitrik
Speaker 1: is the CEO of Adaptec Group and the creator of
Speaker 1: event Modeling, with over three decades experience in software development
Speaker 1: and architecture. Adam is an expert in event driven systems
Speaker 1: and event sourcing. He has been instrumental in advancing these methodologies,
Speaker 1: particularly through his work on event modeling, which we'll talk
Speaker 1: about today, and that provides a transparent, inclusive and collaborative
Speaker 1: approach to system design. Adam is a frequent speaker at
Speaker 1: international conferences and has contributed significantly to the responsible, efficient
Speaker 1: system design and implementation in software industry. Welcome Adam, and
Speaker 1: apologies that you haven't been on this show before.
Speaker 3: No worries, I've been busy, so you know, finally our
Speaker 3: paths cross and thank you for having me. What a
Speaker 3: wonderful intro to the topic as well.
Speaker 2: We've always been in an adjacent thread to each other,
Speaker 2: right often at the same shows. I think we've done
Speaker 2: a little drinking together now and again. But yeah, long overdue, Adam.
Speaker 2: I apologize. You shouldn't it taken it?
Speaker 3: Yeah, twelve years ago is now? And then yeah, yeah now,
Speaker 3: and then yeah as you do.
Speaker 1: Sure.
Speaker 2: Yeah.
Speaker 3: We met. Last time I think was NBC OSLO in
Speaker 3: Norway twenty twelve, so I was still giving talks back
Speaker 3: then on GET which was kind of fairly new and
Speaker 3: in a lot of circles and I think patterns Microsoft
Speaker 3: Patterns and Practices, the Seacaarras Journey Book. I was involved
Speaker 3: in that project.
Speaker 2: Ye yeah, right.
Speaker 3: Exactly that time, and that was I was really doing
Speaker 3: a lot of that good stuff getting that going for
Speaker 3: that team, which was really fun and engaging way to
Speaker 3: help out with.
Speaker 1: Was before I started looking like heat miser. So that's how.
Speaker 2: Wow, look at the Exploring c QRS and Events Sourcing
Speaker 2: book is still on the Microsoft side, included the show notes.
Speaker 2: Everyone wants to look at it. It's two years old.
Speaker 2: But it's not wrong.
Speaker 3: No, no, it's actually it's one of the first fouries
Speaker 3: I think into using Azure. So we have a lot
Speaker 3: of clients that use Azure for you know, the different
Speaker 3: technologies they are cosmos, et cetera, for storing the event streams,
Speaker 3: et cetera. So if you're on a very dot net
Speaker 3: focused textac you know, this is what I'm going to
Speaker 3: be talking about is highly technology agnostic. It's talking about
Speaker 3: being responsible with your information system. So sure, really the
Speaker 3: whole kind of background of how our parallel lives kind
Speaker 3: of weave in and out.
Speaker 1: Yeah, yeah, So the the comment Richard read was a
Speaker 1: pretty good introduction to events sourcing if you don't know
Speaker 1: what that is. And the whole idea is that instead
Speaker 1: of mutating a field and a table, you add a
Speaker 1: new record and whatever changed and who changed it, so
Speaker 1: that it does become sort of like a time machine
Speaker 1: that you can step back and every record is a state. Essentially.
Speaker 3: Yeah, it's like it's like accounting, but for information. That's
Speaker 3: how I like to think of it, because accountants don't
Speaker 3: have erasers, as the stereotypical thing goes.
Speaker 1: And so interesting you said accountants, because that was the
Speaker 1: first introduction to that that I had back in the nineties.
Speaker 1: We were building an accounting module for some software I
Speaker 1: was building or helping to build, and that was a requirement,
Speaker 1: like you could not modify field, you had to write
Speaker 1: a diff Essentially.
Speaker 3: What's interesting about the history of this whole idea of
Speaker 3: event sourcing is that many kind of credit event sourcing
Speaker 3: to Martin Fowlers areticle in December two thousand and five. However,
Speaker 3: if you kind of look at information systems in general,
Speaker 3: the approach has really been the way you create information
Speaker 3: systems throughout thousands of years. Most of the organizations and
Speaker 3: systems that happened before computing were literally record keeping and
Speaker 3: you needed those carbon copies to know where the heck
Speaker 3: things are people filing cabinets by their desks to you know,
Speaker 3: to have the old copies there. So events sourcing is
Speaker 3: actually quite natural for human beings.
Speaker 1: And I think I always know, if you think about it,
Speaker 1: are you taking the eraser away? You know?
Speaker 2: Yeah, for a good reason, guys, get serious talking. You
Speaker 2: go all the way back to writing with quills on clay,
Speaker 2: right and Kadian, where you can't erase anything, You've got
Speaker 2: to throw it out.
Speaker 1: Yeah.
Speaker 2: And that whole markup system was designed for counting an inventory.
Speaker 2: It was an entry only system exactly.
Speaker 1: Wow, Richard, that's awesome. What a way to tie this
Speaker 1: back to history. Great, it's so cool.
Speaker 3: I think another problem that people have it's a little
Speaker 3: bit different than what they're used to. So I have
Speaker 3: to say there's a bit of a baby duck syndrome
Speaker 3: at play when people are looking at this way of
Speaker 3: working a lot of times. But once you're familiar with
Speaker 3: both ways of working, either the mutable state way that
Speaker 3: we kind of have forms over data a lot of times,
Speaker 3: crowd systems or whatever, and these behavior based ledger based approaches.
Speaker 3: One of the simplest things about it is that you
Speaker 3: really don't have to think about you know, am I
Speaker 3: going to have to follow a whole bunch of relationships
Speaker 3: between tables right away? When I have a form and
Speaker 3: I press submit, it's like, the only thing I need
Speaker 3: to do is just store that that was submitted. It's
Speaker 3: almost like the systems thinking boundary and capturing things at
Speaker 3: the ingress and the outgress, like and that is your
Speaker 3: source of truth. So there's very little subjectivity about it.
Speaker 3: When you know that your business requires this information that
Speaker 3: user is going to be adding something, it really takes
Speaker 3: away that subjective kind of discussion of like how am
Speaker 3: I going to design this? And oftentimes in this event way,
Speaker 3: the event modeling is not really modeling the events themselves.
Speaker 3: It's modeling using the building blocks that the events provide
Speaker 3: because they're kind of dictated to you, like the business
Speaker 3: says this has to happen at this time, so you
Speaker 3: have no choice but to capture that information. The subjective
Speaker 3: stuff is left how you interpret it later. But the
Speaker 3: other good thing about that is is that you are
Speaker 3: not really restricted to one way to abstract that projection.
Speaker 3: You're free to really do a lot of different projections
Speaker 3: for different purposes, so that same information can be used
Speaker 3: in an entirely different way further along in the workflow.
Speaker 3: And so there's this natural sort of fanning out into
Speaker 3: purpose built abstractions, which really gives a lot of awesome
Speaker 3: capabilities for people working on the projects. That's also have
Speaker 3: a list of one hundred benefits of this approach, and
Speaker 3: one of them is this really good autonomy so that
Speaker 3: people don't step on each other's toes and so that
Speaker 3: you're free to build the abstraction that fits that particular
Speaker 3: step in a workflow one percent. Right, You're not make
Speaker 3: one abstraction that tries to make all the different pieces happy,
Speaker 3: because you're never going to make everyone happy all the time.
Speaker 3: So that's kind of one of the really benefits of that.
Speaker 1: Can we just jump back a little bit and yeah,
Speaker 1: I mean you kind of jumped into the benefits of
Speaker 1: event modeling without really talking about the fundamentals of what
Speaker 1: it is. Oh yeah, sure, so elevator pitch.
Speaker 3: Yeah, event modeling is kind of a I mean, you
Speaker 3: guys kind of gave a short kind of intro winter this,
Speaker 3: but it's really about having a clear and understandable documentation
Speaker 3: of what the system is doing, and it really is
Speaker 3: a storyboard for for your system, much like you would
Speaker 3: have a storyboard for a movie where you have the
Speaker 3: scenes at the top row of what's happening visually, but
Speaker 3: at the bottom you have notes about you have notes
Speaker 3: about the plots to make sure that the movie still
Speaker 3: makes sense. So you need to have both, or you
Speaker 3: end up with water World. You know, if it looks
Speaker 3: really good, you don't want you don't want a water World.
Speaker 3: So that's and vice versa, right, I mean you can
Speaker 3: have the really you know, a really good story and
Speaker 3: you hear about this an excellent book with a horrible
Speaker 3: movie adaptation, right, so you don't want the opposite either,
Speaker 3: or something is a visual to just you don't.
Speaker 1: Want to be drinking your own urine.
Speaker 3: Yes, yeah, so it's it's kind of it's it's really
Speaker 3: about I would have I would like an event modeling
Speaker 3: to like, let's say, Richard, you have a you have
Speaker 3: a system, and I don't know how it works, and
Speaker 3: you could hand me a pile of specifications and documentation
Speaker 3: and hope that I'm bored enough over the weekend to
Speaker 3: go through it all, or we could sit down side
Speaker 3: by side and you can say, hey, Adam, let me
Speaker 3: walk you through some examples of how I use this system. Right,
Speaker 3: I go, okay, so what do you do now after
Speaker 3: you log in? Okay, you press this Okay, I understand.
Speaker 3: You set it up, and now I can put things
Speaker 3: in the cart and my customers can pay for things.
Speaker 2: Et cetera.
Speaker 3: It's like, very cool, Richard, thank you. I totally understand
Speaker 3: how the system works. It wasn't that way more effective
Speaker 3: than a bunch of papers sitting at my desk waiting
Speaker 3: to be read.
Speaker 1: Right, So essentially taking from the user story down into
Speaker 1: the system, what gets written, what doesn't get written about? Yeah?
Speaker 3: Yeah, so it's sort of like the closest thing I
Speaker 3: would say that. It's like is sequence diagrams from UML,
Speaker 3: except we take the middle pieces out and we really
Speaker 3: talk about state the kind of the object on the
Speaker 3: very far right in the sequence diagram and the user
Speaker 3: interaction on the very far left, and this is kind
Speaker 3: of the right size block for units of work. Those
Speaker 3: state transitions we don't want to talk about get into
Speaker 3: the weeds of like is this class a good abstraction
Speaker 3: or not? That's highly subjective and also silos a lot
Speaker 3: of the conversations into just the dev circles, so it
Speaker 3: doesn't really have a good collaborative platform for talking with
Speaker 3: your business users. Now State. I sometimes explain this as
Speaker 3: like this, you know the pyramid you have in an
Speaker 3: organization where we have your you know, boss, CEO, whatever,
Speaker 3: they have a vision statement. That vision statement gets broken
Speaker 3: down into a set of goals or whatever, and then
Speaker 3: it gets keeps getting broken down into requirements, into actual
Speaker 3: you know, implementation and tests. So it really fans out.
Speaker 3: But there's that really good common area in the middle
Speaker 3: of that triangle called understanding state. And as I go
Speaker 3: through this, you know, storyboard of what what people see,
Speaker 3: what gets stored in the system as the time moves on.
Speaker 3: By example, you know, no branching, nothing like that, just
Speaker 3: like no no flow charts. Is not a flow chart.
Speaker 3: You really understand, you know what happens, and people can
Speaker 3: work together using this. It's kind of like a blueprint.
Speaker 3: If you go to a construction site, there's a big
Speaker 3: blueprint on a big table. The carpenters and the and
Speaker 3: the and the plumbers can can look at it. And
Speaker 3: so the key there is that the carpenter knows exactly
Speaker 3: where to cut the holes in the walls so that
Speaker 3: the plumber can put the pipes through where they need
Speaker 3: to go.
Speaker 2: Right.
Speaker 3: So there's that. I guess what we've kind of been
Speaker 3: trying to do in this after industry ever since agile
Speaker 3: is to do the small design up front, which was
Speaker 3: kind of always the premise we'll get rid of big
Speaker 3: design upfront because we don't want to We don't want
Speaker 3: to be, you know, being kind of armchair architects for
Speaker 3: a whole year planning these great goals and you know,
Speaker 3: things that will never see the light of day because
Speaker 3: we've never actually practiced them. So this, you know, this
Speaker 3: event modeling can actually be done as little as an afternoon,
Speaker 3: and it can also be done and often is done
Speaker 3: as a way to maintain the system because you upgrade
Speaker 3: your schematic of what's happening. So you know, if I
Speaker 3: come back to a system four years later and we
Speaker 3: do this often you kind of roll out the schematic
Speaker 3: and say, hey, someone needs a feature and it requires
Speaker 3: you know, this extra workflow to be at it, so
Speaker 3: we'll make space on it. Plunk in what needs to
Speaker 3: be done, do what's called information completeness check, which is
Speaker 3: a real fancy way of saying, do I have a
Speaker 3: source for that piece of information somewhere? And if the
Speaker 3: arrow's doing add up, we know we're missing something and
Speaker 3: so we're going to have to you know, this is
Speaker 3: where we really understand the coupling in a system. We
Speaker 3: start to actually see where you know, that field value
Speaker 3: must come from. Okay, we probably need to add date
Speaker 3: of birth on the registration page because we're obviously using
Speaker 3: date of birth and the thing that we just imagined
Speaker 3: we want to have in the next release. So that's
Speaker 3: kind of how it works. I also think of old
Speaker 3: history of when you had a vacuum tube television and
Speaker 3: you opened up the back panel, you'd have the entire
Speaker 3: schematic with the where each wire goes to which vacuum tube,
Speaker 3: so that if something went wrong with your TV, you know,
Speaker 3: it's not today's throwaway society where you go back to
Speaker 3: Costco and return it. You actually, you know, had a
Speaker 3: TV repairman and go and you know find that too.
Speaker 3: And you know, I think someone mentioned that there's at
Speaker 3: stores there used to be vacuum tube testers. We'd plug
Speaker 3: in your vacuum tube and click and then see which
Speaker 3: ones work or whatever. So we kind of want to
Speaker 3: have that responsible way of maintaining our software systems. And
Speaker 3: so an event model is a is a really human
Speaker 3: friendly diagram of what the system's doing. And I also
Speaker 3: call it inform architecture, which is really the backbone of
Speaker 3: all architecture because no matter what cool stuff we're doing
Speaker 3: in tech, it all serves the purpose of getting information
Speaker 3: to people, right. And the reason that the screens and
Speaker 3: the UX is in event modeling is because all systems
Speaker 3: we build are for humans, and so we need that
Speaker 3: human face to it. And so where previous attempts to
Speaker 3: do even like business specific things like BPMN, oftentimes this
Speaker 3: is more of an extra feature or a benefit that
Speaker 3: you can or can't use, event modeling says, no, you've
Speaker 3: got to have these things in here because humans are
Speaker 3: using it. So I really want to know if my
Speaker 3: process is at fifty percent, you know, with these steps,
Speaker 3: if I navigate to this web page, what would I
Speaker 3: see right? And on those relevant things, we kind of
Speaker 3: do that, and so an event model is organized as well,
Speaker 3: so you have your subsystems and swim lanes below, and
Speaker 3: you also have the different users that are interacting with
Speaker 3: the system at the top in their own swim lanes.
Speaker 3: And the middle part is really like the watermark of
Speaker 3: like the input and output, Like where does the information
Speaker 3: come in? And then how is it project it out
Speaker 3: to a particular screen, And you can connect all those
Speaker 3: things together and it's a real fun, fast way to
Speaker 3: get going, but also a really responsible way of maintaining
Speaker 3: really crazy large systems. So we had these event models
Speaker 3: that you know, span giant projects worth millions of dollars,
Speaker 3: and so it ends up scaling from you know, startup
Speaker 3: to giant enterprise. And it's kind of like skills like
Speaker 3: this I kind of see as carpentry, right, Like if
Speaker 3: you know the shape of wood, you can build a
Speaker 3: really good chair, you can build a really good house. Right.
Speaker 3: How does a good carpenter work at all these levels, Well,
Speaker 3: they really understand the nature of what they're working with, right,
Speaker 3: And so understanding information is kind of like the backbone
Speaker 3: of being able to you know, build small systems or
Speaker 3: build large systems.
Speaker 2: Right.
Speaker 3: You kind of a good system will have this no
Speaker 3: artificial ceilings of how far they can go. So yeah,
Speaker 3: that's kind of I get too excited talking about event model.
Speaker 3: I can talk about it all day. So I hope
Speaker 3: that was a succinct enough explanation kind of what's on
Speaker 3: top of my mind after you guys introduced it.
Speaker 2: Does a tooling matter much here? Like it sounds like
Speaker 2: a way of thinking about data, But I think about
Speaker 2: the comment and using aka dot net for example, it's like,
Speaker 2: is that help you lead to go the right way?
Speaker 3: It could, and it certainly was very important in earlier days.
Speaker 3: I think now with the focus on how important information is,
Speaker 3: especially with AI and all that, you really want the
Speaker 3: maximum amount of things, So why not capture all of this?
Speaker 3: And we're kind of blending to topics you're event sourcing
Speaker 3: and event modeling because event modeling works for traditional systems.
Speaker 3: We've had lots of people that love the notation and say,
Speaker 3: you know, our company is just not ready for event sourcing.
Speaker 3: We don't have the ability to shift the culture to
Speaker 3: do it that way, but they still use event modeling
Speaker 3: for that. So your question, Richard, is about kind of
Speaker 3: two areas. So yeah, underlying technology, there's tooling there to
Speaker 3: support event sourcing if you want, but you can use
Speaker 3: it with traditional stuff, right, doesn't make it any harder.
Speaker 3: But there's also the what do you use especially around COVID.
Speaker 3: A lot of this stuff used to be done in
Speaker 3: person before COVID, on whiteboards where you would use sticky
Speaker 3: notes to kind of elaborate what's our workflow, you know,
Speaker 3: what are we going to be capturing. Let's put up
Speaker 3: some you know, mockups that we drew with with felt
Speaker 3: markers on white pages and just put them across and
Speaker 3: kind of say, yeah, that looks like a really cool system.
Speaker 3: I can see this working, and I can.
Speaker 2: Yeah, And the tech is secondary the point there, right,
Speaker 2: the system stands alone.
Speaker 3: Yeah, exactly, So that the cool thing about that is that, yeah,
Speaker 3: it's an back of the napkin sticky note process that
Speaker 3: kind of conveys the same information. But obviously since COVID
Speaker 3: everything's gone online. Nothing beats in person kind of interaction,
Speaker 3: especially when you're collaborating. But a lot of things were
Speaker 3: brought online. So there's the advent of well real time
Speaker 3: board changed to MIRO, and then of course Microsoft has
Speaker 3: its own whiteboarding technologies and teams, and many others are
Speaker 3: out there. There's open source ones like Diagrams, dot net
Speaker 3: and on and on, Lucid, chart Excala draw. All of
Speaker 3: those work as long as we can draw a rectangle
Speaker 3: and connect them with arrows. You pretty much got all
Speaker 3: you need for event modeling and you can get started
Speaker 3: right away. And so the other thing that makes this
Speaker 3: tech agnostic on the front end of actually designing it
Speaker 3: is that it's really synonymous to what a lot of
Speaker 3: people are happy with already. Most systems that you have
Speaker 3: that people want to design, people are quite familiar with
Speaker 3: mockups and they want, you know, mockups of the screens
Speaker 3: that a user will see in generally, so a lot
Speaker 3: of places already have kind of the basics in their
Speaker 3: muscle memory to go through this kind of process. So
Speaker 3: that's why it's getting quite a lot of traction.
Speaker 2: Yeah, it feels like you're just putting language around stuff
Speaker 2: we were doing instinctually.
Speaker 3: Yeah, but there's some important caveats because a lot of times,
Speaker 3: you know, one of our clients was plenty of Fish
Speaker 3: and you know, to send a message from one user
Speaker 3: to another. And for those that don't know, plenty of
Speaker 3: Fish is a free dating site, so there's a lot
Speaker 3: of like a free profile, so you could be talking
Speaker 3: to a random stranger, could be someone that's not necessarily
Speaker 3: been vetted as much as with another platform. So you know,
Speaker 3: if you were to do a wireframe mockup of sending
Speaker 3: a message from one user to another on a wireframe,
Speaker 3: that would look like, oh, that's just two steps. There's
Speaker 3: a send message and that oh this person's receiving it,
Speaker 3: great specs, right, But like in the middle is about
Speaker 3: twelve steps of we got to spam check, we got
Speaker 3: to translate it, and you know, replace dollar signs for
Speaker 3: essays and all sorts of tricks that people play to
Speaker 3: do that. So you know, when we actually did this
Speaker 3: with them, event modeling elaborates this to make this complexity
Speaker 3: drawn out horizontally to actually see the size. So where
Speaker 3: this makes an impact is in your agile estimation, so
Speaker 3: or you have extra L T shirt sizes or whatever.
Speaker 3: We kind of don't want to be subjective saying like, hey, Adam,
Speaker 3: how hard do you think this is?
Speaker 2: Oh?
Speaker 3: I think that's an extra large or a medium T
Speaker 3: shirt size? Highly subjective, right, Like does Adam really have
Speaker 3: the good experience to answer this?
Speaker 2: You know, maybe this.
Speaker 3: Other person will give me a large or a small
Speaker 3: depending on their experience. So we kind of want to
Speaker 3: remove the subjectivity and rather than saying, you know, how
Speaker 3: long is it going to take to send this to
Speaker 3: get the work done to send this message to this
Speaker 3: other person on this platform. I need to then see
Speaker 3: and illustrate to the business in a human friendly way
Speaker 3: that this is going to take twelve steps along the
Speaker 3: way to transform the information and filter the information along
Speaker 3: the way, and we can label those things such as
Speaker 3: bad word filter and spam filter and you know alternate
Speaker 3: character Unicode filter where people are trying to well, you know,
Speaker 3: the old hack with a semicolon being replaced with the
Speaker 3: Unicode version from I forget what it is. I think
Speaker 3: it's an an Indian language of some sort, but it
Speaker 3: looks like a semi colon, but your thing doesn't compile
Speaker 3: because it's not actually a semi place.
Speaker 2: Some Unicode character tas like, why is that failing?
Speaker 3: I've watched three Days of Sleep and.
Speaker 1: We just did a Blazer puzzle on that where an
Speaker 1: E looked like an E but it wasn't an E
Speaker 1: and it was a cyrillic yeah something. Yeah, yeah, it's
Speaker 1: not an E and everything compiled because we were instantiating
Speaker 1: a new class name in the class name that we
Speaker 1: were instantiating had that crazy E in it, and it
Speaker 1: didn't work.
Speaker 3: Yeah, yeah, yeah, so anyway, I mean, this kind of
Speaker 3: stuff was really pertinent to these guys and if they
Speaker 3: didn't get you know, I think it's a lot better.
Speaker 3: First of all, I think it kind of removes a
Speaker 3: lot of the problems with imposter syndrome and gatekeeping in
Speaker 3: organizations because if you remove subjectivity, you're really not putting
Speaker 3: someone in a spot to be the judge of someone else.
Speaker 3: And if you systematize things that like, can we just
Speaker 3: work together shoulder shoulder looking at the system and kind
Speaker 3: of you know, spread out this highly complex unit of
Speaker 3: sending a message on this platform that's got these vulnerabilities
Speaker 3: and explain how that actually works instead. But the trick
Speaker 3: was always that that was always looked at as a
Speaker 3: technical thing and always got chucked over the fence to
Speaker 3: the devs.
Speaker 1: Right.
Speaker 3: But if we bring into the conversation a way of
Speaker 3: describing these problems and solutions in a set of state
Speaker 3: changes that's understandable by both side, and that's where we win.
Speaker 3: Where we have this really collaborative environment now where we're
Speaker 3: talking about everything that everyone cares about. And so you
Speaker 3: know that goes to how we do specification. So we
Speaker 3: do a lot of spec a specification by example from
Speaker 3: the behavior driven design stuff with guys like Joshua Kariewski
Speaker 3: and Dan North and others that have really pushed this.
Speaker 3: Goyko is another one, so growing software with Objura, I
Speaker 3: forget what it is. There's a there's a growing software book,
Speaker 3: the Goose Book I think it's called that also talks
Speaker 3: about a lot of this stuff. But really it's going
Speaker 3: back to that human friendly thing. And the reason that
Speaker 3: event modeling is a story like thing is because humanity
Speaker 3: kind of built on stories.
Speaker 2: Right, yeah, how it's how humans work?
Speaker 3: Yeah, yeah, exactly like everything like you go to sales,
Speaker 3: you go to any kind of domain. A story is
Speaker 3: how we retain the most. Right, We'll never remember a
Speaker 3: graph like we have a really cool graph about how
Speaker 3: your system's done. Cool, but I'm always going to have
Speaker 3: to refer to the graph to actually use it. Where's
Speaker 3: the story really sticks in your head? So when I'm
Speaker 3: done with the event modeling workshop or a meeting about
Speaker 3: it and I was looking at it, actually retain at
Speaker 3: much higher percentage of what was discussed because it sticks
Speaker 3: in my head. As in a story format.
Speaker 1: And if you sing the story to the Barney song,
Speaker 1: you'll have even more.
Speaker 3: Mind Yeah, I mean, do what you like on your team.
Speaker 1: Right, it becomes an earworm. Now you can't get it
Speaker 1: out of your head, go to bed singing it every night.
Speaker 3: Now you're trapped exactly. Definitely, definitely. Oh that is really good.
Speaker 3: I'm gonna I'm gonna have to use that.
Speaker 1: I'll be here for the rest of the show, folks, I.
Speaker 3: Know I'm taking notes.
Speaker 1: For more tips follow me and media.
Speaker 3: Can I hire you, Carl, I'm gonna We're gonna like,
Speaker 3: we're gonna bring you on onto some of these difficult projects.
Speaker 3: Can you play tub something that's kind of repetitive, right, nice.
Speaker 2: To you.
Speaker 3: It just goes on and on ends.
Speaker 1: But barbaro, no, no, no, I'm sorry.
Speaker 2: Anyway, we should take a break, Yeah, we should.
Speaker 1: It feels like a great place to take a break.
Speaker 1: And we'll be right back after these very important messages.
Speaker 1: And by the way, if you don't want to hear
Speaker 1: these messages, you can get an ad free feed by
Speaker 1: becoming a five dollars month patron at Patreon dot dot
Speaker 1: NetRocks dot com. We'll be right back. You know. Dot
Speaker 1: net six has officially reached the end of support, and
Speaker 1: now is the time to upgrade. Dot Net eight is
Speaker 1: well supported on AWS. Learn more at aws dot Amazon
Speaker 1: dot com, slash dot net. And we're back. It's dot
Speaker 1: net rocks. I'm Carl Franklin. That's my friend Richard Campbell. Hey,
Speaker 1: and Adam Dimitrek is here. And we were just about
Speaker 1: to sing tub thumping songs.
Speaker 3: So can we get the tub thumping as the ultro.
Speaker 2: Music days get knocked down.
Speaker 3: A camp, it just goes on and on.
Speaker 1: Yeah, and again I apologize for not going to sun track.
Speaker 3: Well, that's totally fine. Actually it's it's on track. Is
Speaker 3: we're exploring why this kind of stuff works and the
Speaker 3: way why my stories highly connected, you know, are if
Speaker 3: we if we design our systems using tools that are
Speaker 3: friendly to the human brain, I think we will be
Speaker 3: way more successfully. So I think that's kind of the part.
Speaker 3: And you know, if if em moling really didn't come
Speaker 3: up as an idea, it actually was formulation of many
Speaker 3: different things that worked in the industry. So one of
Speaker 3: the things that worked was a workshop type of environment
Speaker 3: versus a meeting, so that there's constructive things going on
Speaker 3: and you're actually collaborating. There's no I just have action
Speaker 3: items at the end. Of a meeting, like we actually
Speaker 3: did stuff during the meeting, which is much better the yeah,
Speaker 3: exactly like my meeting.
Speaker 2: Right.
Speaker 3: We've been in those places where like I just want
Speaker 3: to go back to my desk and get something done,
Speaker 3: but I've been sitting in meetings all day, right, So
Speaker 3: we definitely have no meetings now, and.
Speaker 1: We're going to have a meeting to find out why
Speaker 1: you have been not so productive.
Speaker 3: Yeh, exactly, Maybe a meeting about the meetings to see
Speaker 3: what's meaning old cliche jokes at this point, I'm sure,
Speaker 3: but yeah, so you know, one of those things was
Speaker 3: the collaborative approach and having in person stuff. The other
Speaker 3: thing was I already mentioned was the specification by example,
Speaker 3: seeing actual examples to the system as a specification that's
Speaker 3: a little bit more friendly to the human brain and
Speaker 3: all that. We have obviously this idea of multiple models
Speaker 3: to make sure that we can express what a specific
Speaker 3: part of a workflow needs based on a common source
Speaker 3: of truth, which is very easily implement if you are
Speaker 3: doing events sourcing. Back again, as I say, it's not
Speaker 3: necessary to do event modeling, but oftentimes they're highly complementary.
Speaker 3: So there's also this idea which we touched upon of immutability,
Speaker 3: So everything in here in terms of the source of
Speaker 3: truth is not utable, and so this additive only approach
Speaker 3: is also it gives you, you know, caching is way
Speaker 3: easier when you're dealing with additive only, like you're just
Speaker 3: moving up point you're to validate cash and things like that,
Speaker 3: or see how far you caught up to so a
Speaker 3: lot of you know, technical things are are much better.
Speaker 3: It also opens up the door to functional style programming.
Speaker 3: You don't have to have a functional language. So all
Speaker 3: the f sharp proponents really do like events sourcing because
Speaker 3: of this immutability part, and like you know, growing ledger,
Speaker 3: it's really easy to feed that into your functions and
Speaker 3: do mathematical map produce on these things and all that
Speaker 3: kind of stuff left folds and all sorts of you know,
Speaker 3: functional paradigms. But you don't need that. You can actually
Speaker 3: explain those benefits in human language to business that you
Speaker 3: have a guarantee that anytime you've had this history, if
Speaker 3: you try to do this, you're always going to end
Speaker 3: up with this result. So this idea of a pure
Speaker 3: function enters into the arena as well where things that
Speaker 3: you test in your unit tests, etc. Are always going
Speaker 3: to be deterministic, so given the same inputs, you're always
Speaker 3: going to have the same output. That makes for really
Speaker 3: really strong unit tests and you know, brings a lot
Speaker 3: of benefits there. So that's you know, all of these
Speaker 3: things are are kind of at play. So you know,
Speaker 3: things like domain driven design with organizing things within bounded
Speaker 3: context so that things are related using ubiicuous language to
Speaker 3: make sure that the terminology is something that everyone understands
Speaker 3: for a particular context that ends up being embedded in
Speaker 3: the event names and the event model. So all of
Speaker 3: the things that you're trying to do with all of
Speaker 3: the kind of best practices that I've seen kind of
Speaker 3: you know, when I started a company, it's that we
Speaker 3: don't have people like I don't have money to spend
Speaker 3: on project managers. I don't have money to spend on
Speaker 3: product owners. I don't have money to spend on QA.
Speaker 3: I don't have money to spend on any of these
Speaker 3: How can we make a system that takes care of
Speaker 3: what those jobs took care of, or at least scale
Speaker 3: their efficiency so that I don't have to hire twelve pms.
Speaker 3: I can just hire one to do that to take
Speaker 3: care of these projects. And so if event modeling was
Speaker 3: kind of born out of needing to fullfill all those goals.
Speaker 1: I have a question for you about the back end
Speaker 1: databases that uses your event store. Is it a typical
Speaker 1: and Richard you might know the answer this too, is
Speaker 1: a typical practice to sort of have a system running
Speaker 1: in parallel or a database running in parallel that you
Speaker 1: that is not online to the customers, but you know,
Speaker 1: you keep a clone of it current all the time
Speaker 1: so that you know when you do need to go
Speaker 1: back in time and look at it from another perspective,
Speaker 1: you don't have to spend you don't have to waste
Speaker 1: time sort of dropping the you know, copying the database again.
Speaker 1: Is that is that something that you do normally? Yeah?
Speaker 3: Yeah, oh yeah, all the time. I mean it's so
Speaker 3: I know, I think I know where my background and
Speaker 3: nightmares come from when you ask that question, because I've
Speaker 3: been in systems where it's really hard to find if
Speaker 3: you need two gigabytes or four gigabytes of the production
Speaker 3: database to debug something, and that's those are not fun times.
Speaker 3: And so when usually when we run these things, yes,
Speaker 3: there is an active and a backup database of following
Speaker 3: database that can do that. A lot of times, technologies
Speaker 3: that Kafka can have something that keeps track of x
Speaker 3: amount of days or weeks worth of data to go
Speaker 3: and interrogate as you wish on the side. Yeah, and
Speaker 3: it's really easy with event source.
Speaker 1: Is that usually something that happens in real time or
Speaker 1: is it like an overnight Yeah?
Speaker 3: Yeah, yeah live. You want a live system, So a
Speaker 3: lot of times we will have that. A lot of
Speaker 3: times with most events stores, they are just sitting as
Speaker 3: flat files on discs, either as a giant chunks of
Speaker 3: you know, two hundred and fifty megabyte files that have
Speaker 3: the events serialized within them, and you can just literally
Speaker 3: just pull them as copies and then you're really you
Speaker 3: can really leverage you know, your infrastructure and the hard
Speaker 3: drive tech that you have to kind of have that
Speaker 3: work done for you if you're mirroring.
Speaker 1: I imagine part of this calculus is you know, how
Speaker 1: much time worth of events do we keep live? Yeah?
Speaker 1: And when do they drop off and get backed up
Speaker 1: or something?
Speaker 3: Yeah. So most mature events stores will have a hot
Speaker 3: and cold part where things go to a colder kind
Speaker 3: of storage that's slower, but it's there just in case,
Speaker 3: and it kind of makes sense to how businesses run.
Speaker 3: An active order will be on the SSD currently and
Speaker 3: it'll be very fast to work with those events, whereas
Speaker 3: obviously if you're coming back to the website, you know,
Speaker 3: a year later and your shopping carts still there, you're
Speaker 3: kind of like, hey, welcome back. Let's take a second
Speaker 3: here to see what the heck you were doing. So,
Speaker 3: and there's other strategies such as snapshotting and and closing
Speaker 3: the books, which is really making sure that the streams
Speaker 3: of data don't live forever, because that's not how usual.
Speaker 3: You know, businesses run like a trading at af your
Speaker 3: if you go to a stock trading exchange or whatever,
Speaker 3: they they end their day, right, a reconciliation, right, So
Speaker 3: there's a natural seam in the timeline for different things.
Speaker 3: And so you know, same thing. If we were doing
Speaker 3: this on pen and paper, the end of the year,
Speaker 3: you probably empty out your filing cabinet, put it in
Speaker 3: archives or something like that.
Speaker 2: Yeah, I mean, it's true that any retail store has
Speaker 2: an end of day, Like you have to draw a
Speaker 2: line somewhere to have measurable data, So you know, what's
Speaker 2: the interval, Well.
Speaker 3: It's just also about management of information. I mean, this
Speaker 3: is not rocket science here. This is not trying to
Speaker 3: figure out brand news storing mechanisms or technologies about organizing
Speaker 3: your information, just like you would with pen and paper.
Speaker 3: You really want to not be swamped with disorganization or
Speaker 3: too much information. So you're going to have a filing system,
Speaker 3: you're going to have an archiving methodology if you're in
Speaker 3: a serious business. And that doesn't really change that much
Speaker 3: when you think about it when you're going digital from
Speaker 3: pen and paper.
Speaker 2: Well, I would argue, usually you're not the one making
Speaker 2: a decision that's a business decision. Yeah, there's probably even
Speaker 2: general accounting practices that have to be followed for a
Speaker 2: bunch of that.
Speaker 3: Oh yeah, there's a lot of regulatory things as well.
Speaker 3: So those things are really very interesting to think about
Speaker 3: when you're thinking about the motivation for this. But having
Speaker 3: these good disciplines does give you a lot of things.
Speaker 3: So for example, I told you about spreading out you know,
Speaker 3: complex things, horizontal steps. What we found is that those
Speaker 3: steps end up being really good units of work. And
Speaker 3: we've actually said that we're going to have a standard
Speaker 3: price for each one. So when we do work. We
Speaker 3: do fixed cost only and we fix bugs for free
Speaker 3: because both the client and the subcontractors are happy with
Speaker 3: that deal. In fact, it's something that drives quality with
Speaker 3: the right carrots and sticks. If I go super fast
Speaker 3: and like do twelve steps in a day, I'm going
Speaker 3: to have a whole bunch of bugs. Well, our contract
Speaker 3: says that you have to fix anything before you get
Speaker 3: to work on new work, So you're not going to
Speaker 3: be able to charge for any work. If you just blit,
Speaker 3: you know, totally chat GPT way through twelve things and
Speaker 3: think they're popping up all over the place next week,
Speaker 3: you're not going to be having a good time for
Speaker 3: the next three weeks of fixing them. The things that
Speaker 3: you kind of went through pretty quickly, so it self
Speaker 3: adjusts really well, and I think both the clients and
Speaker 3: the contractors appreciate that. And also, those units of work
Speaker 3: are highly autonomous because now, as I said, we have
Speaker 3: different projections, different you know, abstractions for each piece. So
Speaker 3: if I do a bad job, I'm not impacting the
Speaker 3: person working on the on the piece of workflow right
Speaker 3: next to me, right as long as we're adhering to
Speaker 3: those pre and post conditions of every little workflow step,
Speaker 3: we're good. And if I do a crappy job, I
Speaker 3: can replace that entire workflow step and I don't really
Speaker 3: have to coordinate with the others. So this is like
Speaker 3: the pizza sized team for Agile kind of goes away.
Speaker 3: We can start to really measure the size of teams
Speaker 3: based on how mature our design is. That's the thing
Speaker 3: that pulls back. If I don't have time to make
Speaker 3: an event model, then I only have, you know, enough
Speaker 3: work for a team of size five. But if I
Speaker 3: actually take the time to build out and understand how
Speaker 3: the system is going to treat information, how many work
Speaker 3: workflow steps I have, then I can have the latitude too.
Speaker 3: Ten fifteen people work on the same thing, and we
Speaker 3: know that they're not gonna step on each other's toes
Speaker 3: and and things will click like lego. And that's kind
Speaker 3: of how other engineering disciplines work. You know, car manufacturing,
Speaker 3: all these other things are they have standardized pieces now
Speaker 3: where you know you don't have to You can get
Speaker 3: a rebuilt alternator from an alternative you know, some other manufacturer,
Speaker 3: and they work just fine. So we're trying to really
Speaker 3: make if you know this type of approach bring software
Speaker 3: development to be more of a true engineering practice rather
Speaker 3: than you know, being a lot of experiments and just
Speaker 3: feedback cycles as we really wanted to, like, oh, iterate, iterate,
Speaker 3: that's going to solve everything. Well, you know, we look
Speaker 3: at other industries, they kind of take time to design
Speaker 3: things a little bit. So we're kind pushing the needle
Speaker 3: back a little bit to the middle because you know,
Speaker 3: we came up, we came up through this idea in
Speaker 3: the eighties and nineties of this big design up front
Speaker 3: and the waterfall method and all this kind of stuff,
Speaker 3: and you know, take a whole year to plan something
Speaker 3: and then you know, things don't go as well when
Speaker 3: in reality, we one all the way to agile, right,
Speaker 3: the to just iterate, yeah, because we hate planning. So
Speaker 3: I think, you know, agile missed a chance to really
Speaker 3: focus on that small design up front, which is a
Speaker 3: big opportunity. And I think don't mean driven design specific example,
Speaker 3: all of them kind of attacked that a little bit
Speaker 3: and said, hey, that's a good way.
Speaker 1: You iterate too fast and you're going to cause problems,
Speaker 1: you know.
Speaker 2: Yeah, yeah, but I mean agile also said the customer
Speaker 2: sitting beside you, right, like, and that's hard to do. Yeah, yeah,
Speaker 2: the real part. The point here was that you don't
Speaker 2: do a whole lot of design up front because it
Speaker 2: separates even the customer. Have the customer involved and in
Speaker 2: reality they don't want to sit around with you.
Speaker 3: Yeah, you get another person in the middle called the
Speaker 3: product owners. Yeah, playing broken telephone. Yeah. So yeah, that's
Speaker 3: that's a lot of a lot of good things have
Speaker 3: come out out of it, and I think I think
Speaker 3: a lot of them, as I said before, are human benefits.
Speaker 3: Were gatekeeping and uh and and imposter syndrome go away.
Speaker 3: Like we've had people that have worked on our projects
Speaker 3: that are just fresh from another industry. There's a work
Speaker 3: Safe BC. Someone got injured on the job and they
Speaker 3: had to switch careers and work Safe BC augmented their
Speaker 3: pay for us. But they were able to start this
Speaker 3: because you know, each of these workflow steps, at least
Speaker 3: in event sourcing, is identical. Like there's only two patterns.
Speaker 3: So you're either working with a command handler or you're
Speaker 3: working with a read model. And if I'm a new person,
Speaker 3: all I have to do is like, hey, Tim, how
Speaker 3: did you do that command handler? I copy their code
Speaker 3: and just and all that. It's like the same pattern
Speaker 3: over and over again. So this repeatability is highly valuable
Speaker 3: because you get a lot of cadence. It also gives
Speaker 3: the excellent you know, estimates because you're doing the same
Speaker 3: thing over and over again. So you're sample sized growth,
Speaker 3: you know, mathematically speaking, your sample size for how long
Speaker 3: things take. You get a really good idea. Whereas if
Speaker 3: you were to throw a whole bunch of patterns all
Speaker 3: the time at every problem, you're going to have a
Speaker 3: smattering of small amounts of statistics for each pattern, and
Speaker 3: that's not going to be enough confidence to say that, yeah,
Speaker 3: I can do that for X amount of money. You're
Speaker 3: you're not going to have that amount of track record
Speaker 3: with that. So by repeating you know, a few core
Speaker 3: patterns over and over again, you really do that. And
Speaker 3: after ten like we've been in business for about ten
Speaker 3: years now, we've got like a ton of statistics to
Speaker 3: go on. And so when you know, when we say
Speaker 3: a project, will you know cost this much and take
Speaker 3: this much time, it's pretty spot on, especially if the
Speaker 3: client is there collaborating on the design saying yeah, these
Speaker 3: are the screens we want, Yeah, these are the steps
Speaker 3: that have to be taken to capture this information. From that,
Speaker 3: we can say, yeah, everyone's happy to sign on for
Speaker 3: you know, fixed costs and all that, and I think
Speaker 3: something that's really worthwhile and you're confident and you should
Speaker 3: be able to do for fixed costs. That I think
Speaker 3: is a sign of like maturity to be able to
Speaker 3: have you know, people take on that quote unquote risk
Speaker 3: and it's actually de risking a lot for both sides.
Speaker 3: And so back to that point, you know, someone that
Speaker 3: you know came into to work in software for the
Speaker 3: first time, they felt really at home because there was
Speaker 3: really good guardrails of how a framework within which to
Speaker 3: learn programming. So they can make all sorts of mistakes
Speaker 3: when they're making a command handler or they're making a
Speaker 3: read model, and they could iterate themselves to learn that.
Speaker 3: And of course their throughput is not going to be
Speaker 3: as much. They get paid the same amount for that
Speaker 3: piece of work as someone that's senior, so it might
Speaker 3: take them three weeks to do it. A senior person
Speaker 3: might take three hours if they're really really good. So
Speaker 3: we've seen a huge variance. It's also exposed a lot
Speaker 3: of the inequality in the industry, like a staff engineer's
Speaker 3: a senior engineer level one versus a level two, or
Speaker 3: there's like a five thousand dollars difference in pay. Well,
Speaker 3: the difference in pay for levels of skill we've seen
Speaker 3: is insane. We've had people make as low as three
Speaker 3: thousand dollars because they're new, to as high as seventy
Speaker 3: thousand in a month because they're so good. It's insane.
Speaker 3: How the variance of people's ability or incentive or devoting
Speaker 3: themselves to the amount of time, it's been very enlightening,
Speaker 3: and I just like the fact that you know, it
Speaker 3: kind of manages itself because when you have these standards,
Speaker 3: you have a system that kind of operates on its
Speaker 3: way on its own. You don't need to fill a
Speaker 3: whole bunch of other jobs to manage it, or at
Speaker 3: least if you have those jobs, you can scale out
Speaker 3: the amount of work under those jobs way further out.
Speaker 3: So you know, we've been pretty much a flat organization
Speaker 3: much like get hub started or Valve. It's just myself
Speaker 3: and everyone else doing the works, about twenty thirty people
Speaker 3: at peaks when we have larger projects, and there's really
Speaker 3: very little need for any kind of management like these
Speaker 3: event models kind of you know, we color them in
Speaker 3: as the project moves on. There's no backlog, so as
Speaker 3: we look at the schematic people just fill in the
Speaker 3: rectangles that represent the slices of the workflows. You know,
Speaker 3: they paint them yellow maybe if it's in progress, and
Speaker 3: the pink them green when they're done. And we always
Speaker 3: look at it and say, hey, this looks like it's
Speaker 3: fifty percent done. And some have done automation of miuro,
Speaker 3: for example the Whiteboard to kind of use its API
Speaker 3: to give you like a burn down chart equivalent. Right,
Speaker 3: they'll count how many of these slices are actually colored
Speaker 3: in versus not, and then you can see how many
Speaker 3: your own progress instead of have a nice little bar
Speaker 3: graph shows you what's going on. So we've replaced all
Speaker 3: the tooling with just an event model. But we're the extreme,
Speaker 3: like we just want to show what's possible, and most
Speaker 3: organizations are not going to be able to do that,
Speaker 3: we understand, but at least we kind of show what's possible,
Speaker 3: and then you know, for most people that's an answer
Speaker 3: somewhere in the middle. So we've had to integrate with
Speaker 3: Jira and other things for certain projects because that's what
Speaker 3: they have in their organizations. That's fine. You can translate
Speaker 3: these things and we're happy to do that so it's
Speaker 3: compatible with other things. But we always want to just
Speaker 3: push the envelope and and just show what can work
Speaker 3: so that people have the confidence to pick something in
Speaker 3: the middle.
Speaker 1: Where can we find these tools in guidance from you
Speaker 1: and yours?
Speaker 3: Ah? Well, I just yesterday I finally got a paper
Speaker 3: copy of Martin Dilger's Event Sourcing Understanding Event Sourcing Book.
Speaker 3: I wrote the forward for it because it's the first
Speaker 3: book that puts that writes about event modeling and event
Speaker 3: sourcing together. So it has in it examples that you'll
Speaker 3: find some of them online. I mean, I've been doing
Speaker 3: a lot of If you want to learn anything in
Speaker 3: a book, you can probably find it for free online.
Speaker 3: But this is like a concise kind of way of
Speaker 3: looking at it all in one place, and a lot
Speaker 3: of people want that. But yeah, you can see. I
Speaker 3: don't know if I can be legible or not, but
Speaker 3: yeah you can see. I guess the people who are
Speaker 3: listening to the radio they can't see what I'm showing.
Speaker 1: But anyways, Okay, it looked like a page with a
Speaker 1: white background, wait, hold on and black writing.
Speaker 3: Yeah, so it goes from from zero to fully implemented system,
Speaker 3: really good hands on book, and it's been on Lean pub.
Speaker 3: This is the first It's just got released on Amazon,
Speaker 3: so I just ordered as soon as I could. Cool,
Speaker 3: but it was a It's been on lean pub for
Speaker 3: about five weeks now and it's been holding the top
Speaker 3: spot wow for weekly sales the whole time. It's it's
Speaker 3: been something that a lot of the community has been
Speaker 3: asking for because a lot of people have been doing
Speaker 3: event modeling or trying to you know, promote it and
Speaker 3: use it because they like it and they want to
Speaker 3: carry it through to the rest of the organizations. So
Speaker 3: you know, I've been threatening to write a book myself
Speaker 3: on it, but running a business and doing that is
Speaker 3: a little bit too much. But I'm glad that Martin
Speaker 3: did it and included it.
Speaker 2: So I wrote the forward.
Speaker 3: I wrote the forward.
Speaker 1: Yes, is there anything that is there anything that you
Speaker 1: wish you would have written in there that you didn't
Speaker 1: have no space to?
Speaker 3: Martin's a kindred spirit. I met Martin in Munich in
Speaker 3: last year about this time, maybe a little bit longer,
Speaker 3: maybe an extra month, think the end of October something
Speaker 3: like that. Anyway, I was giving an event modeling presentation
Speaker 3: at their event driven meet up there and and he
Speaker 3: drove in, you know, hundreds of kilometers from his small
Speaker 3: town near Munich to meet me. And that's kind of
Speaker 3: I think when he started to write the book, he
Speaker 3: was very inspired by a lot of the work that
Speaker 3: the community has been doing. And the original article that
Speaker 3: I wrote was from really twenty eighteen that kind of
Speaker 3: got pushed. I think I wrote it on Medium. I
Speaker 3: forget where I wrote it, but it went viral in
Speaker 3: the fall of twenty eighteen October, and I don't know
Speaker 3: what the heck was going on, why my phone's going off,
Speaker 3: but it got the top story on Hacker News, and
Speaker 3: I'm like, what the heck? Why is everyone so interested?
Speaker 3: And that kind of gave me like, Okay, this is
Speaker 3: not just how we were. People actually want the same
Speaker 3: things as we want. They want to do things this way.
Speaker 3: So I made a website for it, eventmodeling dot org,
Speaker 3: and I basically stick all the resources on there. I'm
Speaker 3: not very good at keeping it up to date as much,
Speaker 3: but I try to stick in like links to books
Speaker 3: and research and the videos, the YouTube channels of examples,
Speaker 3: it's all on there, link to that. But yeah, the
Speaker 3: history of how this whole thing evolved, it wasn't I
Speaker 3: did not intend to make event well, it was just
Speaker 3: you know, we found a really good way of working
Speaker 3: that's effective and then captured you know, how we worked
Speaker 3: into both a process and the notation that people could reuse.
Speaker 3: And so that's essentially what event modeling is and from it,
Speaker 3: you know, other people are writing books on it. There's
Speaker 3: a lot of tools also that kind of Martin has
Speaker 3: an ad in to MIRO that allows you to more
Speaker 3: easily manipulate things that are event modeling on a mirror
Speaker 3: board to what to mural you know, MIRO, the real
Speaker 3: time board. It's now called MIRO the Whuro Collaborative whiteboard.
Speaker 3: So a lot of companies use MIRO as a whiteboard.
Speaker 3: I mean same you know, just like maybe dot net
Speaker 3: teams use the white collaborative whiteboard. Yeah, exactly. Yeah, so
Speaker 3: it used to be called real time board. Like if
Speaker 3: you look back in the day, that was kind of
Speaker 3: a very popular thing in the startups, and I don't know,
Speaker 3: ten fifteen years ago, but they rebranded I forget exactly
Speaker 3: how long to Miro because maybe those copyright things are
Speaker 3: just they wanted a unique name. I don't know, you
Speaker 3: can ask them, but anyway, they Yeah, so Martin's written
Speaker 3: an ad in for that. Other people have written plugins
Speaker 3: that basically take an event model and they and it
Speaker 3: interrogates it and creates all your tests for it, I
Speaker 3: like for your solution, which is really cool because yeah,
Speaker 3: these given when ND tests in the style of a
Speaker 3: specification by example BDD style tests are really good with
Speaker 3: event solutions. You just say, what's my given You always say,
Speaker 3: you know, your setup is always a set of events
Speaker 3: that you can just pull directly from the event model,
Speaker 3: and then your when what you're testing is the command
Speaker 3: that you're trying to poke the system with, and then
Speaker 3: your assertion is always that you it spits out the
Speaker 3: event you expect. So it's really awesome and in fact,
Speaker 3: actually there's another benefit of this is that things like
Speaker 3: integration tests and acceptance tests, we've pushed them to be
Speaker 3: subcutaneous and then have the green boxes from an event
Speaker 3: model and kind of capture long running processes. So we've
Speaker 3: kind of shoved all integration testing to be just a
Speaker 3: unit test. So even if we have like a end
Speaker 3: to end test of some long process. The projections that
Speaker 3: we use encompass that. And because there are pure functions,
Speaker 3: these run within seconds, so we don't use any mocks
Speaker 3: anything like that. It's just all poco pojo, whatever your
Speaker 3: language is. There are all the property bags that sit
Speaker 3: there for setting things up, and in fact there's a
Speaker 3: highly kind of opinionated way of doing things, to the
Speaker 3: point where I'm thinking that most people will rewrite their
Speaker 3: own test harnesses for unit testing, because you're taking slices
Speaker 3: of a history that you can predefine as in the ray,
Speaker 3: and then you can take slice length of zero from
Speaker 3: the top to say, what's the default view of this window,
Speaker 3: and then you take the next one that's your next
Speaker 3: test case. Okay, what happens when this event's in there?
Speaker 3: Does it change anythink great like that you can assert
Speaker 3: on that. So it ends up being quite quite neat,
Speaker 3: and in fact, below each slice in the event model
Speaker 3: we do have like an alternate little timeline that points downwards,
Speaker 3: and there we have a different sample of events and
Speaker 3: happenings that are particular to that workflow. So an example
Speaker 3: will be an invoice. The event model kind of wants
Speaker 3: to show me the happy path of how the system works.
Speaker 3: So you don't want about twelve different steps to show
Speaker 3: just how differently the event the invoice can look. It's
Speaker 3: just gonna take up way too much real estate. So
Speaker 3: we kind of go downwards and say that, Okay, here's
Speaker 3: some scenarios of like if you have a discount code,
Speaker 3: you're shipping to a different country, et cetera, et cetera,
Speaker 3: all sorts of different things volume, discount, reward points, whatever.
Speaker 3: You can put those events to make different scenarios down below.
Speaker 3: So you're not kind of polluting the space of the
Speaker 3: general idea of what the system does with the event model,
Speaker 3: but you're diving into those nitty gritty specifications that you
Speaker 3: need to build a robust system. What's really interesting about
Speaker 3: this NAI is that when I did this on the
Speaker 3: stream just last week or two weeks ago, I took
Speaker 3: a screenshot of that set of events and on the side,
Speaker 3: what does that invoice look like? Along the way is
Speaker 3: an arrow down. I took a screenshot of this an
Speaker 3: incursor AYI, which is a fork of vs code, pasted
Speaker 3: that into the chat window and say finish the tests,
Speaker 3: and it did exactly that. It made an addition to
Speaker 3: the test correct first try. I'm not kidding. First try,
Speaker 3: I was blown away. So yes, AI hallucinates, but not
Speaker 3: when you give a good specs relation like yeah, and
Speaker 3: we know what's more interesting is that AI has been
Speaker 3: trained on human interactions. We talked about stories, we talked
Speaker 3: about timelines. Guess what happens when the thing that you
Speaker 3: show it or ask of it is following storylines the
Speaker 3: things that it's been trained on. It's been trained on conversations.
Speaker 3: Conversations are like stories. So I think that's why it
Speaker 3: got it spot on because the format of what I
Speaker 3: was giving it wasn't the mockup of a UI. It
Speaker 3: wasn't anything weird like UML diagram with entities connected in
Speaker 3: whichever way. It was a timeline, and we showed how
Speaker 3: information changed. It got that on the first try. I'm
Speaker 3: not kidding you. You should try this yourself. If you're
Speaker 3: wanting to test where AI hallucinates where it doesn't, I
Speaker 3: can give you an example of where it does not.
Speaker 3: And it's these things of these given win then specifications
Speaker 3: or in the case of state views like I just
Speaker 3: have given then because there's nothing to test like given
Speaker 3: some events. This invoice will look like this. There's no action,
Speaker 3: so slightly different take on it, but the main way
Speaker 3: that it works as the same. So I've been floored
Speaker 3: just by you know how much this helps in the
Speaker 3: whole AI thing, just by having a better structure in
Speaker 3: terms of how you think about your systems, Like you
Speaker 3: get way more help from these tools. So yeah, I
Speaker 3: don't mind.
Speaker 1: Yeah, Before before we stop here, I had I want
Speaker 1: to get in the way back machine for a second
Speaker 1: and ask you if you remember a technology called Windows
Speaker 1: Workflow Foundation. Yes, man, why are you laughing?
Speaker 3: I do remember bistock? Do you remember bisdoc?
Speaker 1: Yeah? So what what was your impression of workflow Foundation
Speaker 1: back then? And you know, why don't we even talk
Speaker 1: about it anymore?
Speaker 3: I think, Well, it's a more general question to me
Speaker 3: about case tools and having Dragon drop development and you know,
Speaker 3: human facing kind of way to automate systems. I think
Speaker 3: we always wanted this way of like why do I
Speaker 3: have to talk to a developer to like get things done?
Speaker 3: Why can't I just have something that's good enough framework
Speaker 3: so I can stick the screens on some kind of
Speaker 3: an interface and then press go and it'll do it
Speaker 3: for me. I think that's what we've secretly wanted, and
Speaker 3: I think that's kind of what fell out of event modeling.
Speaker 3: So just like UML, I mean I talked to Grady
Speaker 3: Butcha last year in Hawaii or was it the year before,
Speaker 3: I forget anyway, he lives in Maui. It does really
Speaker 3: good work with conservation of whales and all that. But
Speaker 3: he's he's really interested in how UMLGA kind of taken
Speaker 3: away to be a case tool to generate code instead
Speaker 3: of being a general notation to do that. And I
Speaker 3: think the UML two point zero folks kind of went
Speaker 3: and said, we can build a business around mL to
Speaker 3: create solutions kind of for free or buy the business.
Speaker 3: And I think, I think what you're taught talking about,
Speaker 3: Carl's kind of this this approach of like, hey, we
Speaker 3: can take you know, a human recognizable way to talk
Speaker 3: about a workflow of information and kind of press go
Speaker 3: and it'll do it.
Speaker 1: I think without this kind of an answer to rational rose,
Speaker 1: wasn't it. Yeah?
Speaker 3: Yeah, the rough process, all these all these different all
Speaker 3: these different things that we've gone through. I think with
Speaker 3: AI it's it's reopening that obviously as we see you know,
Speaker 3: I definitely think that the programming languages that we use
Speaker 3: in the future are not going to be the same
Speaker 3: programming languages that we do to use today, at least
Speaker 3: not for the same purposes anymore. That level of abstraction
Speaker 3: is being bumped very hard right now up again, right
Speaker 3: just like we had from you know, assembler to compiled
Speaker 3: languages to whatever interpreted languages, et cetera. So I think
Speaker 3: the same thing's again happening out of very rapid pace
Speaker 3: because in essence, I think AI right now has really
Speaker 3: just taken what we do with stack overflowing Google searching
Speaker 3: from four hours to be four minutes type of thing, right,
Speaker 3: So that is the affordance of the level of abstraction.
Speaker 3: So you know, when I'm when I'm taking a snapshot
Speaker 3: of you know, some sticky notes on a whiteboard and
Speaker 3: putting it into cursor AI, and it's giving me the code,
Speaker 3: that's you know, I can feel the change, right I can.
Speaker 3: I know that that would have taken me to write
Speaker 3: those things wouldn't have been you know, a second or
Speaker 3: two or three or however long it took the chat
Speaker 3: to produce. It would definitely be taking minutes, an hour
Speaker 3: or whatever. And it even caught something that I there's
Speaker 3: an assertion in there that I didn't think of. And
Speaker 3: when one of the events was uh, you know, this
Speaker 3: was for a conference organizing software, and it was I'm
Speaker 3: going to change the name of a room because I'm
Speaker 3: adding rooms to set up the conference. The assert that
Speaker 3: the AI ended up putting in there was make sure
Speaker 3: that the old name doesn't exist in the collection already.
Speaker 3: I missed that, Like I just wasn't thinking, and I'm like, oh, yeah, right,
Speaker 3: of course, Like I could definitely have a bug in
Speaker 3: there where instead of renaming, I just added another room
Speaker 3: and left the old one in there, right, or something
Speaker 3: like that. So that's a really good assert and it
Speaker 3: did it for me. Okay, that's really good. So we
Speaker 3: all have like spikes of being really good, but we
Speaker 3: also have things when we're not on and we'll miss things, right,
Speaker 3: And I think AI draws a kind of a safety
Speaker 3: net at the average, so if you ever make a mistake,
Speaker 3: you're obviously falling below average of what's out there, and
Speaker 3: the AI will catch it for you. So you know,
Speaker 3: if you're expressing things in a story like manner and
Speaker 3: you're really in tune with what AI has been trained on,
Speaker 3: I think event modeling because of its story like nature,
Speaker 3: the way that these things are specified, they have basically
Speaker 3: given a very low probability of hallucination with these things,
Speaker 3: so you could go incredibly fast asked with event modeling
Speaker 3: and event sourcing. Event sourcing for the point that you're
Speaker 3: working with, you know, multiple purpose built models for just
Speaker 3: that one workflow step, which is a very finite scope.
Speaker 3: And I think AI does a tremendous job when the
Speaker 3: scope is finite, Like really you know it? Yeah, if
Speaker 3: you say, hey, build me an online store, it will,
Speaker 3: but it's probably not what you're the one you're imagining, right.
Speaker 2: Right, Yeah, it's not the one you want.
Speaker 3: Yeah. If you say, like, hey, I want to like
Speaker 3: add this item to my shopping cart, and this is
Speaker 3: the screen and the specific you know, it'll give you
Speaker 3: exactly almost exactly what you mean.
Speaker 2: Yeah.
Speaker 1: Well, Adam has been wow, drinking from the fire hose
Speaker 1: for the last.
Speaker 3: I guessed about this, but full.
Speaker 1: Of meaty goodness. So thank you very much.
Speaker 3: Yeah, thank you guys for having me. And if anyone
Speaker 3: wants to find out more event modeling. Dot org has
Speaker 3: all the all the links search for event modeling. It's
Speaker 3: the top link and definitely get the book from Martin.
Speaker 3: He's done such a good job, working to irishly on
Speaker 3: so many chapters day in and day out, so he
Speaker 3: deserves all the credits there. And he's been a core
Speaker 3: member of the community over in Germany doing that, so
Speaker 3: you know, I'm really happy for his success and it
Speaker 3: helps our entire community. There's also a discord group that
Speaker 3: we have if you have questions about this. Martin, myself,
Speaker 3: all sorts of other people are there to answer questions.
Speaker 3: It's a highly active group. Is messages there every single
Speaker 3: day about this stuff. So if it's event sourcing or
Speaker 3: event modeling, even domain driven design topics pop up in there,
Speaker 3: anything around this whole way of working, you'll find good
Speaker 3: people there to help you. I'll be there to help
Speaker 3: you if I'm not. There's others, So thanks guys for
Speaker 3: having me. And yeah, we have workshops too, so all
Speaker 3: sorts of things on that site. I hopefully we will
Speaker 3: have a few. Actually, we also had our first event
Speaker 3: modeling conference in Vancouver and one in Germany this year,
Speaker 3: so starting to grow. So anyway, we'll have to have
Speaker 3: your booth that one of these when we grow big enough.
Speaker 2: To have you. Yeah, sure, Kevin do that.
Speaker 3: That'd be fun, that would be really awesome. So thank
Speaker 3: you long overdu and I thank you so much.
Speaker 1: Thank you, and we are again. I wish we had
Speaker 1: you on before, but wow, what a show. Thanks again
Speaker 1: and we'll talk to you next time on dot net rocks.
Speaker 1: Dot net Rocks is brought to you by Franklin's Net
Speaker 1: and produced by Pop Studios, a full service audio, video
Speaker 1: and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S for RSS feeds, downloads, mobile apps, comments,
Speaker 1: and access to the full archives going back to show
Speaker 1: number one, recorded in September two thousand and two. And
Speaker 1: make sure you check out our sponsors. They keep us
Speaker 1: in business. Now go write some code, See you next time.
Speaker 3: You got jad Middle Vans