1:13 - Season Finale - Event Modeling / Event Sourcing Give you Superpowers!

Ever dreamed of having superpowers? In all my 15 plus years of experience as a software engineer, I have witnessed such powers. They're called event modeling, event sourcing. How do you acquire such powers and profit from it? In the season one finale, let the creator of event modeling,Adam Dymitruk, tell you how

you are listening to diverse software engineers podcast, which inspires engineers to serve clients better, break glass ceilings, and enjoy lucrative work. Your hosts are Eric Lau, Chief consultant at Brainy Butler solutions. And Fatima Agheli, up and coming engineer. We focus on the soft essential skills which engineers, managers and clients need to upgrade their software projects.

Hello, divers software engineer listeners. This week, I am very, very psyched because I get to finally interview Adam to be talking to someone that I've known for years and someone that I admired a lot because he really done some some really incredible things with pushing the industry forward. There are a lot of people want to claim that they are really good at what they do, or they have really put a contribution to the industry, the purity claim that but they're really not that many that can actually do it and can say that these are the exact things that I have done to move the industry forward. It amazes me that you're out and that you're able to put some of these ideas in the soul cutting edge and have not just the mental intelligence to come up with it. But the offering in some ways even more important, the audacity and persistence to pull it into reality. So it is an absolutely great honor and privilege to introduce you, Adam to our listeners. Welcome, Adam.

Well, well, thanks for that crazy, awesome intro. That's way, way too kind of you. But yeah, I am, in essence, stubborn and don't give up. I'm happy that that's actually brought things forward a bit for people and made it easier for people to get some better patterns and practices into their day to day tech life. So I'm glad that you're enjoying it. And yeah, it's been, it's been a fun journey for me as well. So let's go on all this was obviously the lesser you know, who you are nominally, because your contributions are immense. But like I said, before, our audience are really just getting into the industry. So the idea that they're using the university term, the one on one, why don't you give us a sort of Adam to meet your one on one sort of one, it's that you claim to fame or your your contributions to the industry. Today, my contributions to the industry only started later in my career when I came up with event modeling, which was a result of trying to do better systems design and an implementations for, you know, scaling systems, all the things that you hear about. And also working in and creating an environment where you could create solutions quickly with high quality. So tried agile at the very beginning and practiced it for many, many years, was on the Agile Vancouver board and put together the conferences that were here in Vancouver. So there was many different ways that I tried to help the industry as everyone starts, they tend to find places, people or practices to follow and follow in their footsteps, better themselves by being like those that are that they seem to think are better. And then eventually, with enough experience, you make your own insights, and you start to become those who you followed. And so after many years, that's that's what happened. So it's really hard to find a good practice or person or mentor to follow. It's generally think more of a popularity contest out there with people following names that have a lot of followers or whatever. But for me, that was not the case. Finally, when I found something that did actually move things forward, and that was everything with event sourcing, basically looking at systems being built with just data being added, not you know, just rows and the table changing, but systems that preserved everything that happened and and that was more of a challenge to people when they're thinking about that, because there's been so many decades of traditional applications, and then the rise of frameworks like Ruby on Rails to get things done really quickly. But the quality aspect in terms of scaling those solutions, wasn't there. Um, there's several factors why that is,

before we get to that, because I bet you're curious now. Fatimah? Have you heard of some of the keywords Adam talked about event sourcing, even modeling? Have you? Do those words mean, mean?

Yeah, I've never heard of either of those words. So no,

not that I am I surprised by that.

We can get into that I threw them out there. But just as a just as an over kind of overview of what what it is for me, but it's based on traditional things. That's generally what I do now. And what the you know, adapt, like my company does is only create systems using this accounting like way to rate Information Systems, everyone thinks that programming and Information Systems is kind of something you, you study in computer science, and as a computer science, discipline, where you have all your technical things like for loops, and API calls, and whatnot, those become the detail really, it's about the information. The interesting insight that I got in 2008, was that it's a big advantage not to think about programming and information systems as computer science problems, but rather an accounting problem just from accounting, being able to know why something changed and be able to look at a ledger of information to find out why things are working or not working, or to use a ledger of things that have happened these events over time, as a way to set up a scenario. And then have that as your setup for your test instead of some some ways of, of using some frameworks to create the dependencies for your tests to work quickly. Event sourcing is kind of the name around a concept that basically says your source of truth should only be extra information you write down. So instead of changing a value in a table, like you know, decrease the count of what you have in your basket, if you're doing a website for a store, and you have your cart. And if you remove something, all you have is a table that shows what you have in your cart. Well, in event sourcing, you don't do that you add another event called remove such and such item from cart. And you keep track of everything that the user did to that cart. And anytime you want to show what that card has, you look at the history of what that person did to that cart, and calculate what it should show. So in essence, you're tracking all the actions of someone or an entity or whatever, any piece of information or entity in your system, such as a shopping cart, you're tracking what has happened to it, that's interesting, because it also changes the way you you would specify such systems, you can now see that everything becomes like a story. So we can talk about what happened to the shopping cart, instead of some archaic way of setting it up by putting some values in that table, you can say, Well, someone logged into the website, the, you know, looked at a product and and then they added that product quantity to to their shopping cart. And later, they changed their mind, they removed one. And so now the total should be one. And when they purchased it, that shopping cart had this value, and all that is calculated from all those pieces of information that that basically accounted for all their actions. So there's a very nice story like way of talking about systems. And well, that's very close to accounting, because that's how accountants work with your, with your taxes, or your financials and your company, they look at all of the debits and credits, the loans and interest that you accrued. When the bank paid it, at the end of the month, you see this ledger of what happened. And you know, at the end of the year, you can see that, you know, your percentage profit was such and such. They don't keep changing the percentage profit during the year. They just look at what happened during the year and then give you that so that mindset is very helpful. The other thing that it's really helpful with is that it allows you to have multiple ways of thinking about how you're not present information. Because there's certain things that are going to happen your website that don't really influence what you show, the the cards to have. You know, someone that As changing their profile picture, well, you obviously don't need to care about that event, if your job right now is to make the shopping cart page display what's in the shopping cart, right? So this that's called a multiple model aspect of event sourcing, which these events are sourcing the information from these things that happened, what that allows people to do, you know, if you're working on that, and maybe Eric is working on the profile page, you're working with different representations of how you interpret these things that happened to the system, and you're really unlikely to have conflicts with your work, you can work in parallel, and not really interfere with regular ways that people write systems, there's usually some sort of set of tables underneath that are related. If you change things there, you're quite likely to affect one another. And that's because usually, it's one big model that, that that represents the entire application. Whereas in this way, you're doing a lot more isolated sort of islands of work. And the only way that they're really related is that they're greeting from this same sort of storage of all the different things that happened to the system.

Yeah, I mean, I totally agree. And I, when I wrote the title of this episode goes, even sourcing even more going on, gives you superpowers. And first of all, I wrote that I really find those as being an all male just being like clickbait, clickbait, but no more I think about it, it really does. Because I don't know if the theme of you can appreciate it, I'll let you speak, give us your thoughts on what you've heard so far, it really gives you superpowers in threes Expressway, is that it frees you from having to plan everything. But a lot of times when you build these complex systems, if you do traditional, you have to anticipate future demand and future needs. And doing it for event sourcing really frees you from having to plan that far ahead. So you don't need to construct all these like like tables and all these complex things of extra columns and all that sort of whole equation like me, you may or may not need.

Yeah, I think to extend that it's, a lot of times when you're dealing with traditional systems, something happened, someone clicked Up button, like register as a new user or you know, add something to my shopping cart, you immediately have to think of everything that that will affect because it's got to fit somewhere into this, you know, lots of related tables. And you may need to investigate how that's going to affect everything. With event sourcing, you don't need to like like you're saying you don't need to worry about it, all I'm doing is I'm going to write down this event that it happened. And then anyone that cares about that happening, can or may or may not need to subscribe to that or take that into account. So it allows you to, to really put off a lot of the things that you need to think about immediately if you're doing a traditional way of developing systems. So that that allows quite a lot of speed. And in confidence to go forward quickly.

So Fatima, what are your thoughts?

You were asking me on? Whether it seems like like the title is accurate? I think very much it sounds like event sourcing makes everything a lot simpler. Definitely something very interesting.

Yeah, I think if you read a lot of things about event sourcing out there, you will find that people have posted the opposite. Oh, simply because they concentrate on whether they're not right, or you're right. It is actually simpler. However, when people try to super impose all of the traditional infrastructure and add this idea that you have to look at these events, they have what's called baby duck syndrome, because they haven't seen it before. They're learning new ways to write systems. It's it's novel, and therefore it takes them longer. And because it takes them longer, they think it's more complicated. But I've seen I've shown various simple examples of that, you know, there's a shell script that I wrote, which has no infrastructure whatsoever, it's just, it's just writing these events into a text file. Not even in JSON format, it's just tab delimited. And, and if you want to display you know, for example, I do is that to do list like a little Trello board, and it's on the command line, and all the scripts does is if every time it needs to display the board, it just, you know greps through all of the files that contain the events for the information needs to show and, and shows it so erases things if you've, you know, archived them. It knows Which column to put them in if they're to do or done, it shows, you know how simple the concept is. But if if you, you know, look up event sourcing and related things, you'll find a lot of the opposite being shown out there. Because that was the, the sort of novelty of it. But now people are saying the opposite. And you know, there's many people tweeting, that have actually done this for, you know, five or more years and have good experience with it. And they're way past that baby duck syndrome. And they're saying, why, why is this not the standard way to start every project? You know, there?

I'm certainly wondering about that. Now. You know, I'm at a point where if I have to start the project at any point, and then saying, you can't do event sourcing remodel, I'll be like, Why? Why? What are you doing to me, like, asking me code with my hand tied behind my back? Right?

Yeah, oh, they've, you know, there have been some people taken what people said about event sourcing to the extreme. And one of the ways that event sourcing became popular is that there was this idea that I could replay every single event from the beginning of time. And therefore, I could, you know, regenerate any report that I want with, you know, bugs fixed or extra functionality added or whatever, because I have all the information, and I could just replay all of these things from the beginning of the, of the project, whenever we started writing the system, that sounds really good. But then, you know, his company started using this, and they had, you know, 10 years worth of data out terabytes, the, you know, replaying all the events became very timely, other time consuming processes. So they're, you know, that the idea is that you, you don't need to, you shouldn't have to replay everything, you may want to look at everything that's happened. But like any real system, you know, the accountant, when you when they're doing your taxes, they don't necessarily have to go 20 years ago, to see what you did. You know, there's kind of a closing of the books where you, you just carry the previous balance forward from the previous year, and start the accounting from scratch that year. And, you know, in a trading system, that that timeline might be a day, you know, there's a clearing of the books, at the end of the day, in a, in a financial institution like that maybe your local bank that you bank at for your home banking needs, maybe they're closing the books for certain things is, you know, end of the month, they don't really have to look at all of the different ledger entries from years ago, you know, when you opened your account when you were a kid, until now, they, they have a balance carry over. And then they start looking at individual transactions for that month. And I always look at them and do calculations and recalculate things from that. But so that's kind of what what's missing in event sourcing from some people that have been experienced and see that it doesn't work. It's because they've taken it to an extreme,

absolutely easy to take to extremes or not knowing the nuances. I think for me, from a fundamental level, I like to use like a depending on analogy, or golf or chess, like if you're reasonably getting going to chess a bit more. And it all starts studying opening openings and chairs. And the thing is that one, when I first started studying openings, and I started using it, my game actually got worse, like I started losing more games, then as it was happening. And then one of the coaches that golf and chess, he was saying, like, yeah, it makes total sense. You know, analogy is like the golf, if you have to study in the opening, or you're doing a new golf swing, it will take you some time to get used to it. And while you're, you're still learning it, you're going to struggle, and you're going to do worse, that doesn't mean that it doesn't work, it just means that you need to be more patient revert Exactly. Every new takes time, your productivity is going to dip and you take some time before it goes back. But why do people learn new openings? Right? Why do people learn golf swing new golf swing?

Now there's, there's plenty of examples throughout humanity where we had to, you know, stop a practice that's no longer good. And and as beneficial, you know, horse and buggy and then cars. Turn it certainly took different skills to operate a car. And one might say that, well, that's just too complicated. I'm not going to do that. And I'm going to continue on my horse and buggy. But that that obviously didn't fast. So I think it's a it's the same thing with with modern approaches to, to information systems. Plus, there's a lot of, you know, parallel ways that that you have, that you have this approach being being done in the industry, for example, anything to do with blockchain, you have to think in terms of an immutable ledger that we're information as being added, if you're doing systems at scale, they all require a ledger of what happened in each node so that they can sync up. In fact, if you look at the insides of how a regular database like MySQL works, or anything like that, there's a transaction log, which is exactly a ledger that only gets added to. So there's, there's a lot of lot of concepts out there that can only be successful because of this approach. So, you know, it's just a matter of time before people see that, that using this approach to regular Information System, as you know, for anything is really the proper way to do it. And I mean, I, I present this always as a as a holdover from decades ago, because when computers became fast with, when the transistor was invented, and integrated circuits were started, the automation was was was went into overdrive, it was many orders of magnitude faster than it was with, with vacuum tubes, or whatever was used before, sort of mechanical switches and whatnot. So when you have, you know, 1000s of times the performance output, that's a, that's an incredible productivity boost. But people don't realize that at the same time, the storage mechanisms, the magnetic tapes, and whatnot, the they never had the equivalent at the same time, you know, there was there was no transistor for, for storage. So the way that's storage became precious, as you could process more information is needed to store it, you need to do it, you need it to do it efficiently. So unlike a pen and paper business, where you might file away different copies, carbon copies of the same form, in different filing cabinets, in different departments, that luxury was missing from an entirely automated systems that To give you an example of being able to keep up with this, you know, one of the first hard drives from IBM, in 1956, was what stored five megabytes or something like that, and cost $1,000,000.05 million million dollars, yeah, five megabytes or something like that, and cost cost a million dollars to buy, and then cost about around $30,000 a month to operate. And that's not inflation adjusted? in you know, that was very expensive in 1956. So, you know, that's, that's kind of why, you know, we can't store the old address and the new address for a customer, by E ledger kind of accounting. Because it's just too expensive to keep the old one around. Yeah,

I mean, you know, those are expenses. Like, definitely, there are a lot of things that, you know, just because he was done that before, doesn't mean it's the best way to do it now. Yeah, and I would like to talk about that, after these messages.

Celebrate your software projects or software careers, by requesting a free 30 minute consultation. For details, go to DSEpodcast.com.

Welcome back listeners. It is important when we learn anything, and I can apply certainly to this industry that everything is in context. So when you learn something, and you realize people build software in this way, the conditions in which those ideas came about have to be super important to consider, for example, the storage that storage was at a premium when a lot of these ideas became gospel really back in the 70s 80s. And even in the 90s. So so this is why I really feel like event modeling is event sourcing are really superpowers because they really turned a paradigm around in a very dramatic way. And I'm sure that for some of you have a lot of questions. There's there's a lot of information here. I you take all the time you want to digest it or dissect it, because I'm sure our audience are feeling the same way.

So in terms of starting a project with event modeling, as you guys are mentioning, um, I actually am still a little confused on how that modeling can be incorporated into code or a project. So how exactly would you even start to go about that?

Okay, well, the key differences between Between event sourcing and event modeling, so you have event sourcing, which is like we discussed already kind of a way to just keep adding information about what happened and using that as kind of the source of truth. Now, event modeling is a way to use that timeline perspective, to specify what your software will do. And at its simplest form, it's really opening up a mural board or anything else really where you can draw collaboratively or not collaborative, collaboratively, if you're doing it by yourself, and plan out our design for what your system will do. You may have heard of UML, and other types of diagramming tools, and then obviously wireframes, for making the UI designs. And event modeling is kind of a little bit of both in a simpler way. So essentially, it's a storyboard much like you would make for a movie. And the interesting things about a storyboard is that it has keyframes at the top as to what important pieces of this you know, what, which, which scenes have, what items in which characters and what they're doing, visually. And then underneath, on the storyboard, you have your plot, any, any narration that's happening is usually written there, what the actors are saying. So you have kind of the plot underneath, so that the movie makes sense, right. And then, you know, visually, it's appealing, and it's conveying the story as well and has the right perspectives and whatnot in the right situations visually displayed. So they're modeling is really making up a storyboard for your system. And at the top, you have all the different screens with example data that someone will see as they're maybe signing up for your data, or sorry for your service, and then maybe picking a product to buy and putting it in the shopping cart, and then you know, going to pay for it. And you you show what the screen will look like when when they're ready to put in their credit card. You know, from the beginning to the end, you show exactly what that one user will be experiencing, by example, visually. But underneath, what you're doing, is you're showing events, that gets stored along the way. So that keeps track of what information gets stored in the system as we move through the story forward. And it's done by example. Now, the interesting thing about an event model, then, is that you have a way to, we call it slicing up the whole solution. Because if I want to see how much effort it's going to take to make that system, I can look at how many steps this storyboard has. And that's a really good approximation on the complexity and how long it's going to take to build the whole thing. The other interesting thing about an event model then is, if I'm working on one screen, and you're working on the next one, and then Eric is working on the one after that, we have this storyboard, storyboard to refer to, to see what we expect the system to have, let's say you're maybe displaying the shopping cart, and I did the first that you know the previous, the previous step, or someone added something to the shopping cart, from the storyboard, you can you know from the event model, you can see what the shape of the data is, what other fields are, and how that's supposed to be displayed, that you can match the two quite easily. So in other words, by looking at the event model, you're not relying on me to finish my piece of work so that you can start yours. And likewise, if if Eric is working on the subsequent screen for the checkout piece, where he you have to, you know, add your credit card in, and then pay for it. He knows what you did in terms of displaying the shopping cart, and what that transaction should be in terms of total dollars, and all those things. That event model shows, by example, exactly the shape of that data. And so Eric Can, can work on the checkout screen without having to wait for you to finish yours. Right. And so that's kind of a really, a really neat concept is because it really makes it easy to design a system. And that's kind of what we're missing from, from software right now. We hear all about agile and just doing, you know, small iterations and doing very little with kind of blinders on as to what we're going to be working on two weeks from now. But that's, that's a little bit extreme. Because if I knew What Eric needed, where you knew what Eric needed, and we had an event model, we could make sure that we didn't have to go back and add some extra fields or something that we forgot about, this rework actually starts to add up very quickly as the system grows. And it's it's one of the bad parts of agile and you know, more of a history lesson here agile came about because things were very stuffy and formal, in the 90s, where you had analysis, parallel paralysis, and these designing, you know, designing systems would last for a year. And by the time you wrote it, you really didn't want that anymore. So these were really, really long timelines. And people said that that was waterfall and all these old practices. of actual reason for that isn't anything to do with waterfall, it's to do with the way that large companies made contracts back in that day, because large contracts were handled by two separate companies, for legal reasons, the, the company would hire one contracting company to design the system, and then they would hire a separate company to build the system. And the reason they wanted to have two separate companies is so that, you know, they, they, they feared that if they had only one company, that they would design themselves a system that was extra big, and they could have a large budget and, you know, make more money. So their idea was that I'll have one company do the design and the separate company to do the implementation that way, they're not going to, you know, make a large design. But the interesting thing happened is that even though the designs weren't big, it was working, they wanted to make small designs, because they definitely didn't want the implementation company to have a lot of budget. But they took a long time to make that small design. So they still wanted a larger budget. And, and so that's essentially what still became a battle of budgets, in between, you know, how large systems were being built in the 70s 80s. And probably early 90s, at least, until the.com, boom started. To get around that, you know, people said, this is a very unhealthy way to work people, you know, these are Dilbert like office environments. And, and so people said, We need a better way to do it. So the the reaction was really the pendulum swinging to another extreme, where, you know, let's just not, let's just not do any planning. And let's just work on the next most important thing, which is kind of like what agile is all about. Event modeling really is a way to bring back those core pieces of design that were good, none of the fluff, etc. and make sure that the storyboard is something that everyone can use the programmers, the testers, the people that are in charge of the requirements and guiding the business. They're all using the same storyboard to communicate as to what this is supposed to do. And all of the interesting things about infrastructure, and DevOps and all these other things, they're there, but they're kind of a fixed cost, because you're not going to redo your pipe, you know, your ci, CD pipeline, your your continuous integration and continuous development pipeline, all your GitHub hooks, you're not going to redo them all the time, just because you're adding another feature. So those are static costs, the costs that continue to add up is all the different ways that you're adding yet another screen or storing more information. Those are the variable costs. As you grow your company, you're adding more and more features. And so that's the part that's important to be repeatable and predictable, high quality and all those things, even though you're doing new things. You're using the mechanics from the previous step. And so when you're doing an event modeling type of project where you have that design, it's not uncommon to just keep copying the previous steps that you did, because the infrastructures the same, and just change the information. And you know, maybe this screen has these text boxes and this button, and the text says something else. And when you press the button it, it sends this information instead of the other information, but it's always the same mechanic. So once you get going with an event modeling project, the speed at which you go was incredibly quickly. In fact, most of the time you end up finding out that the other people that are telling you what to do, they can't give you work fast enough. So that's a good thing.

Absolutely. It's, it certainly can is a game changer, the way that wow work, I just want to sort of summarize the exam online to me, like for me, it's kind of like Goldilocks and, you know, once you know, you're the, you know, I think with waterfalls, I too much planning Yeah. And then, you know, with agile is too little as if like, you know, pretend you don't need any Yeah, and and even modeling is so just right. And when he goes back to the notion of coupling of a team, are you familiar with that term?

Um, no.

Okay, so coupling, when we talk about software, he's talking about how much a piece of software is reliant on other pieces of software, or rely on other parts that they doesn't control. So you can imagine that, you know, any software I'm beyond this basic, the most basic form hello world, stuff like that, I got to enquire inputs from other systems, like other libraries, other API's and whatnot, you cannot build a system without any coupling. Because if we don't mean you just busy doing everything, why is called monolithic system, you just have to do everything. And it's a nightmare. But you also don't want a system where you are super, super like, like a couple all these other things, and where you completely depend on them do everything. But at the same time, you know, of Agile thinking, like, Oh, we just keep we built these things like, no, it's not true, you want some coupling, because at the end of the day, you still you don't want to reinvent the wheel, every time you build a feature, you want to build five features. So that

while there's always coupling, you just want to keep it to a Yeah, responsible level, or at least understand where it is. So that you, you can be ready for it and how coupling is addressed? Absolutely.

I mean, I mean, really, you know, couplings can be beautiful.

Yeah, because, you know, it's like, you're going to need the user name in a number of places. And therefore, you can see that all these different pieces of functionality are coupled by the username, and then the, the format that it's in or whatever. And so yeah, if you'd have no coupling, you really have no system, you need you need coupling to actually relate information and tie it together.

It's just bad coupling, just bad coupling. Oh, it could be excessive, right. It could

be excessive, but it's also it's also I think, I think the problem is where people make coupling the evil thing. Well, it's not it's unnecessary thing that we have for systems to work, what people are truly afraid of, is accidental coupling, and coupling that isn't known about until you go to make another feature. So because that coupling exists, now you have to unpack these previous features you made and adjust for, you know, whatever piece of information, you have to add. But if you had an event model at the beginning, you would know that that piece of information is needed in these places. And so when you built those previous features, you would have built that field in to be taken care of at that time. And you wouldn't have to go and unpack that feature again, and refactor, you know, refactor it when you're developing something down the line.

So every team I mean, we help we come up with the top bar specific example or or, or instance of how coupling comes into play with that Hellboy?

Sure. Yeah,

let's use a very simple software, let's say you have a software that basically let's just have an address, and it just, you know, like tells a basic information about let's say, the, the elevation, the elevation, the temperature of the of that moment, like, like you, so you can build this where you are completely rely on like on the Google API, you just like you're slave to it. So if Google changes interface, your hose, you know, it's one of those things where you really need Google? No, no, you don't, you just need a whatever service it is, like gives you that information. You know, a lot of these things that if you have event modeling, event sourcing, you don't really care where this information comes from, you're coupled to the information, but in it, but it doesn't have to come from one one source. As sometimes when you build software that you don't think about the need to do a couple of things, then then, you know, you're trying to do that later on. It can be painful.

What do you think? I can imagine someone listening to this podcast and thinking, Well, you know, I really kind of took care of that. The interesting thing is, event modeling applies to traditional systems as well being there's way more coupling there because you have a single data model really that kind of need to keep an understanding of, at least if you have an event model for it. You show all these things. It's so if people got to this point, and they're still listening, they would say, you know, I can do these things in you know, without event sourcing. The problem is that you start seeing all the events this Up here on an event model for a traditional system. And then as you're, as you're doing more and more projects with an event model for a traditional system, you're, you start to think why am I throwing away this really good piece of information here that reduces the coupling that I need, allows me to build more models so that I don't have to, you know, couple things that I thought I needed to cobble together, and I can make my own little sandbox for displaying that page, those, those ideas start to come to fruition. And so I think it's really healthy for people by looking through the lens of what coupling is, when they're first trying to do event modeling. And they don't do event sourcing, because they're just, you know, doing another project with Ruby on Rails or whatever. And they're not going to change in either dev practices, but they want to try to design their software beforehand. And I think that's really great. I think that really starts to open people's eyes to better concepts, because design is going to make you think, just going and blindly typing is gonna, you know, make you not like working on the simple what you thought was a simple project in the first two weeks, and then two months later, it's like, I'm just gonna drop this, because there's so many little accidental, you know, complexities that are happening here, because I didn't think of how the whole thing was going to be working. And so that modeling gives you a way to just get the design done super fast, and get you those insights so that you can keep that same productivity and speed throughout your whole project and give you kind of a pattern to repeat over and over again. And that'll give you something that actually should increase your speed as to how quickly you can add things.

Yeah, absolutely. Event modeling, I am a convert now. And I really feel that even modeling, it is a superpower because it just lets you build faster, build better. And if listeners are wondering what's in it for me, case, you got a means to build big I paid more, you can enjoy your work more. And I guarantee you I'm gonna throw my Charles Barkley impersonation, I guarantee event modeling will change your life gave you more fulfilling work, and you are better off for it for the rest of your life. Do not say this lightly. And it's definitely something that I will for 100% of my weight behind that. And we will continue all this conversation after these messages.

Celebrate your software projects or software careers by requesting a free 30 minute consultation. For details. Go to DSC podcast.com.

Hi, Alright, so we're getting to this Oh, about event modeling event sourcing. I O listeners was wondering, well, I've never heard of it. Maybe probably most of you never heard of it. And then you go, Whoa, all this information? Sounds great. I see the point. But how does it apply to me? How do I get started? And what? How would you respond to that?

When I'm looking at a new technology or a new tech stack or something that is new to me? Yeah, I have, I have experience in putting systems together. So I have a slight advantage. But I also see where the guidance to where you want to use, sometimes you you try and start a project you just don't know where to begin, and how to keep yourself organized to, to do things in a in a particular order or something like that. And so when you look at an event mxolisi the screen that I have, that's the first one that the users are going to see when they open up the web, the website, and they have a button to register. Well, no, I mean, if you're if you're writing your own, if you know your own project, you know, let's say you're writing out of the hotel system or something just for fun. If you have an event model in front of you, you can basically concentrate on, hey, I'm just gonna make this registration page work. And you can follow the line from the button to the command and from the command to the event. And then for now, maybe you'll just save that event on on disk as a file in some JSON format, and then you're going to make, you know, read model or state view the green boxes, and they're going to say, Well, how can I get that information? Well, maybe I'll just look for these files on disk. Or maybe I will have something that populates a table, if I want to use a database, but you know that you've done it when you've got that information, and maybe just output it to the screen in the console dot log or something. And then you see that that green box is connected to another screen, you say, Oh, this means you successfully registered with such and such name, etc? Like, where do I get that information? Oh, it's that green box. But now you can look at, I just need to make this screen. So it really allows you to compartmentalize, you know, each piece of your system, and slowly fill it out by just following those lines. A lot of times, we get so sidetracked with different things that we want to do. It's like, Oh, I made a user table is this, should I just now skip to the admin screen and make sure that, you know, we can display all the users for you know, this other admin? Well, that's a distraction, why don't we just continue following the thread, and keep building the system for the next screen. So I think for people that are starting out, and computing, and programming, it's really important to have this, this little roadmap or plan of how even your smallest little projects should evolve. And especially if you're still in school and need to collaborate on, on on projects with other students that, you know, once you're, especially maybe if you're in a boot camp or something,

tell me about it,

you're going to be working with others. And one of the fastest ways for to, you know, divide and conquer and understand how what you're going to build is going to work is through this event model. And you can look at different parts of it and follow those lines. And, and really finish the system without much, you know, needless kind of meetings to think about, you know, how things are going to how things are gonna go. So for things like hackathons, there's it's it's a, it's a secret weapon for hackathons, for sure. The the team, the teams that the teams are, that don't Yeah, the teams that are not doing, you know, event modeling, or have a much lower chance of winning the hackathon or getting something truly complete. Compared to to the teams that are using an event model. We've done that at UBC and, and other occasions where, where you had a limited amount of time. And just doing that very quick, rough event model for the first half hour, if you're hackathon is six hours, to get everyone on the same page as to what parts need to be built. And then people just take different parts and start to color them in on the whiteboard. That's an amazing way to to work. So. So people that are starting out, if you're working by yourself, you can certainly allow yourself to focus on on different parts of the solution, not try to build too much at once, because then you'll get frustrated and give up on your project. And then in a school setting or a Code Camp setting, we have to work with a team to do something, it's very valuable, because you can see exactly which parts, you know, each person is going to going to work on. And you know, there are other diagramming methodologies, but I don't think they're very, very good in communicating the size of effort for each step, or as the event model draws out complexity horizontally. So for some complex piece, there's really no way to encode that into into an event model, because it has to be always done by example, from left to right. So you're not allowed to do certain things like say, Oh, I can represent an if statement in this in this in this event model that's not allowed. It's supposed to read like a book. And what that you know, so if you have like, a branching out, you know, like an if statement, let's see if someone's logged in or successfully or not, if they put the right password in. On a traditional UML system, you might have a little activity diagram or something where you would split that off if you know, logo does not correct and show this screen, if it's correct, show this screen. Sounds good, right? But it's, it loses the story. And it bakes in a whole bunch of complexity in their event model. What you do is you say, Well, if I want to show that we can, that we have a failure to login screen, then maybe I'll show the user first failing to login by putting in the bad password, but then right after they retry with the correct password, and they continue You along. So these things are supposed to read like books. And every time there's a bit of complexity you want to show, it just continually tries to push you in a way that will give the story more length to show that there's complexity there. And that's why you can use it more easily to divide up a system if you're, if you're working on it by yourself just to see what you're getting yourself into. Or if you're in a group project at school, or you're in a group project that at a code camp or a hackathon, it's a much better way to then honestly see just how much of what your system is supposed to be doing. which parts of that whole process are taken care of by who? So, hopefully, that helps you.

Yeah, that's, um, that was very informative. Thank you.

Yeah, like, I was just thinking, like, you know, to go back to my projects, old school projects, and like, even like, school watches were like, oh, you're building some sort of, you know, two or three screens as a go for people. And he got frustrating, because I remember why Well, usually happens these things, one on one on TV or co gram, and the rest of just, you know, either help Gavin karma, really, they can't really participate? Because it will they do just wind up having we do the work like the doesn't integrate well, hold on. People, if you have different ideas, what what the system was supposed to do, is I remember those assumably enough about those tower planters were like, boy, you know, we just have a common understanding and able to have a loosely coupled system where we just okay, you're working on own thing, and then we're only worried about how we're going to put it together. All these minimally, you have to be aware, I have to plan ahead of time, then, yeah, it really makes a big difference.

Yeah, having having all that it's kind of like I also call it a blueprint, because it's where everyone can go in to get their ideas, broadcast to everyone else. So, you know, UI designers, project managers, programmers, testers, we all seem to have our own set of documentation that we keep. And that's really divisive. It really adds walls between silos of people. And that's where the extra meetings and translating what the, the other designer wanted to what the programmer is going to do. That's where all that translation problem starts. And that you need a whole bunch of extra communication just to get everyone on the same page. So the van model aims to remove the fact that everyone has to have their own documentation style, and have one blueprint that everyone can understand and work off of that erases a ton of meetings. Because we already know what the system will look like and what it will do, when we're going to be done with it. So that's, that's another good feature of it.

So Adam, should allow listeners love to know more about these things. It can be overwhelming, because now let's say you say difficult, it's just there's a lot. Where word would you recommend they go to find out more information?

Oh, yeah, for sure. So I think the first thing to do is to go to event modeling.org. And there is a link for the oldest blog post on there, which is the original article that I wrote. It's called what is event modeling, and they spell modeling with one L, it looks nicer when you get the stickers printed out is still North American valid spelling. So event modeling.org is where I would definitely recommend someone go and read, it takes about seven minutes to read the entire article, it gives you steps of how you can run event modeling sessions with others and things like that. So I think that's the number one resource to check out. And then I have a lot of recordings of the meetup. So that's on YouTube. There's a lot of different subjects being discussed how they change with the use of event modeling, and you know how it affects your day to day. Software Developer life. So if you just go to YouTube and search for event modeling, it'll come up very quickly. It's actually called event driven systems or something like that. So you'll you'll see that it comes up quite a bit there. Obviously, follow me on twitter at a dimetric. And then event modeling as well on Twitter, at event modeling. Those two accounts should give you I post almost every day about the subject. So if you're interested, we'll definitely see a lot there. And I think those are the main places but then of course to interact live with people. We have the event driven meetup, which happens every Friday, and it's online. So anyone from anywhere can join and discuss and ask questions that happens at 10:30am pacific standard time that the Vancouver Los Angeles time zones and the alerts every Friday, sometimes when we get too busy, we do cancel a week, because there's too much work. But for the most part, it's every week, we have that attend 30 for a couple of hours. And we have sort of a chat, through zoom. But it's also broadcast on on YouTube Live. So the YouTube channel has the live broadcasts that you can see. And they'll get announced that you're subscribed, you'll see them come up, and you'll get a notification if you turn on your notifications. So those are those are the main sources YouTube, Twitter, and of course, the main site is where I would look for for all information about event modeling.

That sounds great. I mean, I've been doing modeling media, I certainly familiar enough with it. But I always find that that it's like a house, like it's a great game, you know, like, like chess, like, you know, and he's on a really great endeavors like is, it's easy to pick up and get the bare basics of it. But I know that there's so much to it. And, you know, I'm learning every day, and it's definitely a privilege really to be able to be part of this. So thank you, Adam, for what you bring.

Great to have more and more people, there's always more people coming in and joining the community. It's definitely a net positive influx of people. If it weren't once people discover it and take advantage of it. It's really hard for people to not use it anymore. So yeah, I'm happy when people discover that they can be a lot more productive.

Speaking on the topic of that modeling, and source modeling, I'm just kind of curious on how it seems like it's such a important and useful tool. I'm curious on why it's not used as often or why, as Eric mentioned, certain projects, you can't use it.

Yeah, so anything that's new is gonna have is going to have some resistance. And there's a number of things and they think, you know, one of those is definitely the structure and the politics of an organization because not everyone around you in your organization is going to want to learn new things, they want to do the same thing they did yesterday and get the same paycheck. So it's kind of it's called don't move my cheese. And so a lot of the resistance is going to be for human reasons, it's not going to be for the fact that it doesn't work or things like that there. There may be places where it doesn't work, but they're the exception. They're not, that's not the rule. So by default, event sourcing is going to be the best way to treat data. And event modeling is going to be the lightest most productive way to design systems and collaborate. So those are two things that we know now is, you know, after doing this for a number of years, for for, you know, for building projects, using both techniques, we have proof that that's actually true. But why is it not adopted? Well, first of all, there is, like I said, this inertia of people, just knowing their current toolset in their current approaches, they don't want to drop any of those things, because that's what they signed up for. I would say that's the biggest reason that may not move forward. For there may be more political reasons besides that, but I would say, you know, most of the time, it's really the human aspect of not wanting to do something differently. And there may be valid reasons for it. I mean, they're just maybe there's no time to have people change gears and learn new things. There may be anomic reasons for a company not to do that.

I think economic is really just boils down to our way of seeing that the cost of moving human capital or order overcoming inertia. inertia is very real in human psychology. People are comfortable with things and they don't like change. We say want to change marveling or love is that less optimal to change as we like to think we are anything really that's true, Li a paradigm shift. That truly is transformative. I've always followed this sort of three step path. One is the first thing It will get ridiculed to go Oh, that's that's crazy talk you're like capital going your earth surrounds the sun. That's absolutely crazy talk right Earth has to be the center of the of the solar system and the universe right? In your back in those days that was just ridiculous wait laughed out like, we can't be true. Dan is violently oppose. And after a while they won't go till dawn. It's so obvious it's self evident.

And there's also you know that saying First they laugh at you, then they, you know, they disagree with you and then and then they will finally adopt, you know what you're doing and then you win right?

And and they will say they figure it out. They say figure it out. It's so obvious like All right, thank you listeners for listening. Take care of yourselves. All right. Bye. Bye.

Thank you Goodbye.

congratulating yourself for listening. By engaging with us. You are already well ahead of the pack. Please subscribe, share with others and post about on social media. For feedback and suggestions for future episodes. Please go to the podcast website, DSC podcast.com.