Mathias Verraes, Co-Author of Design and Reality: Essays on Software Design

The transcript below is unedited output from OpenAI Whisper.

====

Hi, I’m Len Epp from LeanPub, and in this episode of the FrontMatter podcast, I’ll be interviewing Matthias Verus. Based in Ghent or nearby, Matthias is the founder of Ardling, a software modeling and design consultancy with a penchant for complex environments. His focus is on design strategy and messaging-centric domain modeling. He’s also a popular conference speaker and particularly well-known for discussing domain-driven design and as the founder of the DDD Europe conference. You can follow him on Twitter at Matthias Verus and that’s V-E-R-R-A-E-S for anyone listening and check out his website at verus.net. Along with his colleague Rebecca Verus-Brock, Matthias is co-author of the LeanPub book Design and Reality Essays on Software Design. In the book, Matthias and Rebecca have included four essays exploring the relationship between design and reality, models and metaphors, and various aspects of domain-driven design. In this interview, we’re going to talk about Matthias’ background and career, professional interests, his book, and at the end, we’ll talk a little bit about his experience as a writer. So thank you very much, Matthias, for being on the LeanPub FrontMatter podcast. Thanks for having me. It’s my pleasure. Thanks. I always like to start these interviews by asking people for what I jokingly call their origin story. So I was wondering if you could talk a little bit about where you grew up and your background and how you found your way into the career you have. Yeah. Well, I grew up in Kortrijk near Ghent in Belgium. The way I explain it to people who don’t know where that is at all, it’s if you make a triangle between Amsterdam, London, and Paris, I’m smack in the middle. And yeah, I guess I just had a normal childhood. But I didn’t like school very much. And I ended up going to the music conservatory in Ghent to study. Specifically, it was a new thing they had just started, which was called pop music production. So we were learning like how to do studio recordings and sort of the technical side of that, but also composition and songwriting and arranging music. We had to learn a different instrument every year. So it was a very sort of mix of many things with the goal of, you know, teaching people how to or helping them get in sort of the space of producing pop music albums. I ended up doing a whole bunch of different stuff after that. Like I conducted a pop choir and I started writing music for short films and documentaries and commercials. I did studio recordings for orchestras, for film music, that sort of thing. But at the same time, I was a child, I was one of the first kids with a computer. We had like a Dandy TRS-80 which had Microsoft basic and nothing else. So if you wanted to play games, you had to make them yourself. So that’s sort of my first entry into computers and coding. And then even though I was doing doing music gigs, it was right when MP3s were becoming really popular and the whole music industry was crashing. And so I was like half looking for a way out, I guess. And also just like playing around with the computers again and building websites for various projects. I was involved in like art projects and stuff. And I got into open source and I started like publishing my own little plugins for CMS. And then, yeah, that sort of turned into a job. And I started a company with somebody in the CMS space, left at some point and did some various things. And eventually I started writing about it. I started speaking at conferences. And then people started asking me if I could go help them, especially with domain-driven design, which was sort of my focus there. And yeah, people started asking if I could go and help them. And so at some point I gave it a try. I was finished with a government project I had been working on for 18 months. It was not finished. It’s never finished. But sort of the part that I was there to help do was finished. And yeah, I started freelancing. And that’s sort of how it started. Yeah, helping organizations with domain modeling and software architecture and design. Started teaching as well. And actually, if I could stop you there. I mean, thank you very much for sharing that story. It’s interesting. You said you started teaching just at the end there, but you started by saying you didn’t like school. I was wondering if you could talk a little bit about what it was you didn’t like about school. Well, I went to a Catholic school. It was very Catholic, very strict. And it was never considered that I, because my parents weren’t very religious, but it was like the closest school. It was like the obvious place to go to. And so that didn’t really help. And then I switched to another school and it was even worse. It was in boys only school. Those still existed. And yeah, so I don’t know. It was just not working for me. I feel like if I had been in maybe like a Montessori school or something like that, it would have been much better. But I was so tired of everything school that music was my escape route, I guess. That’s so interesting. There were aspects of school that I really didn’t like, including I’m sort of a late to bed, late to get up person. I have been since I was like nine years old. And so it was like every day it was like, wow, this is the worst day of my life. That’s how they all began. And it wasn’t a bad or harsh place, but I went to like a rural Mennonite boarding school in Saskatchewan in Canada. And so I’m accustomed to sort of unusual learning environments. My experience wasn’t like Roald Dahl kind of terrible thing, but it just didn’t fit there, I think. And then when I got to the music school, that was like suddenly it was a revelation. There were like people like me, right? I could, you know, people who were passionate about stuff and even the teachers, right? We were learning more by, you know, they took us to concerts or to recording studios where they were doing some band or something, that sort of thing. And we learned more sort of playing around, being in this music environment for five years, non-stop. And it sounds like you got into it. I mean, one could pick kind of any decade in the 20th century and it would be interesting for music technology, right? But you were there. So you said, you know, when sort of MP3 started coming out and it sounds like Napster and stuff like that, what was this sort of technology like that you were being trained with to do sort of pop music production at that time? When I started, Pro Tools was this thing that people sort of mentioned that, you know, if you get a chance, you should have a look at it. So Pro Tools and especially Autotune was very new back then. And people were actually buying Pro Tools, which is like a music recording, digital music recording environment. They were buying Pro Tools just to be able to use the Autotune plugin for that. And that was very, very new. Like most studios were analog or yeah, actually pretty much all of them were analog when I started. By the time it was a five-year, the education was a five-year thing. By the time it ended, Pro Tools was ubiquitous and everybody was using it. And you were like the exception if you still did stuff on tape. So, and it’s not just that, right? But everything, like when I started, nobody had a home computer where you were actually doing, very few people, but nobody in my class, I was the only one who had sort of done a bit of home recording on an old, I don’t remember what computer it was actually. But by the end, like they weren’t accepting people in that school anymore for the pop music production if they didn’t already have that at home or had played with this sort of technology at home. So that’s sort of the shift that happened right there. So that was fascinating. But at the same time, it was, yeah, everywhere people were, music companies were just firing everybody. There was just no money anymore. There was no, the music industry collapsed. So it was a very, yeah, I guess, like a turning point for many things. It’s so interesting to talk about this historical moment. I mean, just for anyone listening who might not be old enough to remember or who wasn’t paying attention to this kind of thing at the time, there were like a couple of collapses that actually happened right around the same time. I guess I never thought about this in these terms, but they were kind of ironic, right? Because there was this sort of boom in the web and in sort of the construction of networks for using the web and in sort of stuff related to that. And then there was this terrible bust called the dot com, dot com sort of bust at the end of the dot com boom. But around that same time in the late 90s, file sharing of music became easy and popular through various tools. I forget what there was. I mean, Napster was the most famous one. Winamp was the pop music player back then. Yeah. And there was the one called GNU something, but anyway, but yeah, but, so this sort of like this incredible explosion of sort of computer stuff caused this explosion of the spread of music, which caused sort of a collapse in the music industry. And so it’s just, it is kind of like, again, I say sort of this ironic thing that like at the, basically the same time, the computer people who caused this sort of crash in the music industry had their own, had their own crash in jobs and stuff like that. But you found your way out of it. And that’s so interesting that you mentioned, you know, you had that first experience with a Tandy when you were young and making your own games. A lot of the guests on Leanpub, as I’m sure you can guess, are computer programmers and stuff like that and have a background in that. And so many people have an origin story for programming along those lines. And you can tell that this sort of person’s vintage by like, you had, you had to write your own programs. You sort of bought physical magazines, you know, things like that. One question I wanted to ask you going into this was, did your sort of, do you feel like, you know, your study of music helped you or influenced your understanding of software and programming and design? Well, I don’t know. I get that question a lot, actually. I don’t know, because I have nothing to compare it to. But people have said, you know, people have told me that it’s actually quite common that people from music get into programming. There might be like, I don’t know if any of that’s true, right? There might be some relationship between the fact that it’s music uses abstract language and abstract notation to express something entirely different. Like if you didn’t know what sheet music was and you see that for the first time, there’s no way you can imagine that that represents music, right? It’s so separate. Of course, we’re used to seeing that, but it’s just such a big distance from the language on the paper and what that actually represents. And so there’s that. There’s like a lot of things I have always felt are, I don’t know if that’s just music and programming. Maybe it’s a lot of other disciplines as well that have it, but patterns and structures and reasoning about structures and sort of, yeah, like, for example, there’s been this every now and then that flares up at a conference, right? This is programming art. And my answer to that is music engineering, because a lot of music is, in fact, if you listen to pop songs, right, there’s, of course, there’s genres, etc. But within a genre, there’s similarities. How does that happen? Well, because they share patterns, because they approach, how do I get from this point to that point in a similar way as this other song, right? So there’s patterns, there’s sort of repeatable, they’re not, well, you can steal bits of music, but the patterns are not stealing the exact music. It’s sort of solving the problem in the same way as other music does it. How does reggae make a rhythm or how does techno music do it? Those are patterns. And I was in film music, and there’s lots of things that, you know, how do you make something sound scary or something exciting or build up attention, right? There’s patterns there. And you can, you know, if you have that that that baggage, if you know, if you know the right patterns, you can sort of construct your own version of it, which is still original, but uses the same underlying philosophy to solve a problem. And some of it is very accidental, even like, you know, the music in Bonnie and Clyde with the banjos, if you recall, that has been used for car chases for many decades, even. I think they came up with it for whatever reason, because they knew a guy who played banjo, maybe. So, and same with sort of like the sound of Hitchcock movies, right? There’s, that has been imitated without being direct copies, but sort of, you know, the choice of harmonies and melodies and rhythms and instruments. So in that sense, yeah, maybe music is engineering and programming can be arts. I don’t think all programming is arts, but you can, well, you can use paint to make paintings or to paint your wall. One is art and the other is not. It’s the same with Goethe, I guess. Yeah, it’s so interesting to think about also sort of borrowing terms from these different fields to sort of describe similar types of activity. Like you write software and you write music and you write books. We’ve got one of our bestsellers on Leanpub is called composing software by a guy named Eric Elliott who produces, who does music as well. And he’s got like, I think his cover of the book is a kind of waveform. And he talks about sort of compose, not the word writing, but the word composing. And one of the terms that’s obviously very important for you and for anyone who’s familiar with your talks and your books and your blog and stuff like that is the term modeling, which is just fascinating because I mean, that’s when normally when one’s thinking of sort of like music or software or books, you know, the terms like writing or even composing are more familiar. But modeling is this word that comes more from like science, like physics and stuff like that typically. And it’s this level of abstraction that’s sort of at the same time as it’s kind of daunting to sort of think about, right? Like theoretical physics sort of building a model kind of thing. When you watch particularly your videos, when you’re sort of using post-it notes and stuff like that, it’s kind of like, well, you’re composing a model. And I imagine that I’ve never made music, but like, you know, you sort of like moving parts around and like, it’s this iterative process. And like, you sort of, you just get started and you sort of figure out where to go. And so I’m super interested in asking you about about models and metaphors and things like that. But before we get into that, we probably need to sort of like lay the foundation for the conversation by talking about what domain-driven design is and what kind of design we’re actually talking about, right? Because people might be thinking about all kinds of things that where the word design applies. So I was wondering if you could talk a little bit, just for, imagine you’re talking to someone, which I’m sure you have many times who’s like, I’m not a programmer. What do you do? And what’s domain-driven design? Yeah. Well, it’s design in the sense that it’s, you know, creating something that solves a problem, right? That, as Sherry Weinberg used to say, design is a bet on the future, right? You’re trying to structure something for a specific purpose, hoping that that future will exist. But I’m going very philosophical right away. More specifically, it’s just how do you build software, right? That’s the problem. That’s the question. And I feel we’re still in the stone age of that. So that’s what this kind of design is about. It’s not visual design. I like to call it invisible design. It’s like for software, there’s the bits you see, the user interface, et cetera. But there’s the iceberg under the water, basically. So that’s the area I’m most interested in. Domain-driven design specifically is, yeah, you could call it a way of thinking about software design. Some people call it an applied philosophy, which is maybe accurate, but maybe a bit too distancing or too abstract for people. But I like to think more of it as a discipline. It’s a discipline for how to build software. So a discipline in the sense of there’s a bunch of principles, and the more you try to apply that, the more you use techniques and methods to apply those principles, the more of the benefits you’re going to get. And so within that discipline, we’re saying, well, as the name suggests, domain-driven, we believe that a software design that is really rooted in the problem domain, right, where the people who build the software understand the problem domain well enough so that the opposite is somebody tells you, add a button there, and if I click it, it should do that thing. You can build software that way, but it’s not going to fit the problem very well or scale in complexity very well. You can do that at a small scale. But if you imagine building an entire bank like that, it becomes problematic, of course, because you have sort of a random huge assortment of stuff doing things that nobody really knows why they’re doing that and what they’re doing it for. So that deep understanding of the domain is like the core principle. And then how do you do that? Well, you’re always modeling, right? If I explain something to you, I have a mental model of what that is in my head, and maybe you have a mental model, maybe you have never heard of a mental model, maybe you have never heard of it so you don’t have it, or maybe you’re thinking of something else that you’re associating with this. But I’m trying to communicate my mental model to your head, basically, through language. So in the main design, we want to make those models much more explicit. Even if you’re just on your own writing a bit of code, you are basically modeling, right? So you’re giving an understanding of what is the problem like that you’re solving and what is my solution like? How is it going to work? Why structure that way? But we believe that doing that with much deeper collaboration between domain experts and engineers is going to help, or between engineers as well, right? Instead of just having models in our heads and trying to replicate those, let’s visualize those models. Let’s find ways of drawing this. And not just drawing, right? That’s another sort of core idea there, that these models themselves should be shared, right? If you have an entirely different model of how your business should work, then the engineer is going to end up with software that doesn’t work for you. So this is super interesting. What a great explanation. I mean, just one thing that you’ve mentioned in the essays in your book is sort of like concrete case study examples so we can sort of hone in on what we’re talking about when we’re talking about the concept of a domain. And it reminds me whenever I hear that people talking about domain driven design, I always think about this great Vanity Fair article from years ago about an NBC news presenter who got in a controversy and the company got taken over by a company that insisted that its executives have no domain, zero domain expertise, which is just fascinating in itself. But one way to think about when we’re talking about domain, right? And it was sort of news, right? That’s what they meant. These sort of executives are not supposed to know anything about news. What they were supposed to understand was business, right? At that level of abstraction. And the sort of concrete example that you use in one of your essays and in a bunch of your talks is a sort of offshore oil rig. And one can imagine, so you’ve got a bunch of people who are into business. They want to make a profit. They’re good at sort of being executives, right? Then you’ve got a bunch of people who are programmers. They’re good at programming. They understand a lot about programming and you bring them together and you’re like, now make an oil rig. You don’t know anything about oil rigs. And then you’ve got the people who work on the oil rig and the type of engineers who design them. Those are the real domain experts, of course. The real domain experts. But then now the sort of the super interesting challenges, like how do you… You’re these expert programmers. You’re these expert kind of, hopefully, kind of business people. And you’re these expert kind of people that flying on the helicopter out to the rig, expert at living there for weeks on end, doing this dangerous job. How do you develop a language? And the term is ubiquitous language in domain-driven design. And I was wondering if you could talk a little bit about the sort of like nuts and bolts of how like if you were brought into a project, how do you get all those people talking the same way? Yeah. So you’re hitting at the core of one of the problems, right? If you’re trying to build things for complex environments, it’s hard to understand everything and to know everything, et cetera. So all large complex projects are dealing with this. And any environment will develop their own language, right? Language is a very social thing, right? It’s sort of a natural, organic process that we form natural language, right? Where we build a language that’s also a problem typically. So we call it jargon, right? The oil rig engineers will have jargon, the business people will have jargon, the marketing people will have jargon. It serves a purpose, right? It helps them to abstract and to communicate much faster, same in software, right? If I had to say every time, well, send a message to this other service that is running there that is able to store information and retrieve it, it would be much faster to say, you know, store it in the database. So we built this jargon. But of course, if you have these worlds that need to, you know, collaborate and they have their own language, it becomes very hard, which any business person who has been in a meeting with software engineers will, you know, complain about that. Oh, they’re talking about all this technical stuff that I don’t know or understand. And so in domain design, we’re sort of acknowledging that, right? Language is messy. It’s organic. It’s evolving. It might be ambiguous, right? Because people are, you know, using words or they are adopting words from something else. Or, you know, maybe the business changes, maybe the market changes. Some of the language is sort of legacy, right? It sticks around, but it doesn’t fit anymore. Or they make up their own words or they mislearn the words or they have different words for the same thing. It’s very messy. But in software, that doesn’t work very well, right? We have very strict, well, we have programming languages that right now are still very much, you know, put a comma in the wrong place and the whole thing, you know, refuses to work. So and not just for the code itself, right? But just for clarity, you need sort of very precise language. So this formal language, right? The organic natural language, we call that the domain language. It evolves to fit the domain. In domain design, we’re saying, well, look at that domain language. Try to understand it and learn it and capture it. But when you do that, you’re also going to make it much more strict, more formal, right? You’re going to weed out the ambiguity. You’re going to define terms. You could say, well, from now on, this is what we call a sales order or this is what we call, I don’t know, a drill in the oil rig example. Define that and attach properties and behaviors to it, et cetera. And that language, so that strict language, it’s a design language, right? It’s not a natural language anymore. So we as software designers, as engineers, as analysts, testers, et cetera, we’re all part of the design. We built this language, but we should do that in collaboration with the domain experts. Because if we don’t, we end up with, again, this very sort of technical programmeries language that doesn’t really make sense to people outside of software. And you can end up with this disconnect between your design and reality, which is what your essay is about. And you talk about this very specifically. So I want to talk about the domain experts, because you have this great example of how this can work in practice. So for example, on this oil rig, for example, we’re thinking about an offshore platform, which I’m sure everybody can get an image of that in their head. And there’s this concept of an alarm. So maybe some software, some programmers are tasked with come up with this way of setting off this alarm. There’s going to be some threshold and various systems. It’s going to set off an alarm and log that alarm and how, when the alarm starts and when it ends. And so one could think, there’s this sort of, I’m always in a sense, a kind of data, a metaskeptic about data, basically, because people will be like, show me the data. And it’s like, sure, here’s when the alarm started. Here’s when the alarm went off. That’s how long the incident was. But of course- And that’s a very, very programmer-y information of it. Here’s the data. Therefore, that’s the truth. That’s the truth. But of course, on a rig, when the alarm goes off, you’re like, okay, fair enough, but- It’s noisy now and the lights are flashing and everybody’s running around. So yeah, the technique of involvement is being used to mess with you. That’s what an alarm is. But if you can’t solve the problem right away, you turn the damn alarm off so you can fix the problem. But then your data doesn’t show, your data doesn’t reflect the fact that when the alarm stopped, it didn’t mean the emergency was over. Exactly. So the logs are misrepresenting reality. And well, there’s a quote from John Gull’s book called Systematics, which talks about how systems work and fail, any kinds of systems. He hated computers, so it’s not just about computers, but all kinds of systems. But he says, reality is what’s reported to the system. So you believe within a system and organization, for example, that imagine that you have a feedback form, but it doesn’t work. And then management thinks, oh, nobody’s complaining, we’re doing excellent. So reality is what’s reported to the system. If we only log when the alarm starts and when the alarm is turned off, then all the incidents will look like very short incidents because what actually happens is people turn off the sound so they can focus on solving the problem, which might actually take a few hours or even longer. And in the essay, so my co-author, Rebecca Wurstbrock, she was consulting for this Euric. And they were sort of figuring out what problem to solve and what to work. She was hired to help think about design and how to improve it, et cetera. They hadn’t really a specific problem. But then at that point, an Euric exploded in the Gulf. So the company she was working with was doing sensors and, well, when you drill holes, I don’t know, I’m not an expert, right? But when you drill holes, it creates a lot of friction and noise and heat. And they use a chemical substance, a drilling fluid or a drilling mat, they call it, which they put in the holes as a lubricant, but also to push debris up and take it out. And then they measure the friction and the heat and everything. And they actually change the chemical substance of that fluid as they go to balance the properties they want. And that company was building the sensors and the software and that whole infrastructure. So they started thinking, well, this Euric exploded. It wasn’t theirs. It wasn’t their material. But still, they wanted to know, could this happen with us, basically? What are we missing? Are we overlooking something? Are we as safe as we think we are? So they looked at lots of things, and then they discovered the whole logging problem. And what you do in a situation like that is you start looking for all kinds of scenarios. You start asking, how does it really happen? You try to, what you should do, right? You try to move away from your mental model of how the system works, where everything seems to fit. But you try to move out of that and go to what actually happens. What happens when an alarm sets off, the noise, the people running around, what do they do, et cetera. And that’s how they figured that out, that actually those logs are misrepresenting reality. And then what you try to do is you find awkward scenarios. So you start looking. That’s a technique for figuring out something with a lot of complexity. You start asking for, are there scenarios where you don’t know exactly what’s happening or what should happen or where something is not really well understood or where nobody can tell you how the system reacts in that situation or how the system should react even. And so they started asking questions about what if two alarms sound at the same time? Well, that doesn’t work. You can only physically have one alarm. But if two incidents happen, maybe two drills, I don’t know, two things happen at once, what happens with the alarms? And that’s how they started. This is just one example but they started sort of teasing out these weird, awkward scenarios. And eventually the solution they came up with is that there’s something in between missing. So you introduce something new in the design. In this case, they call it alert condition. So it’s not the alarm. There was a direct connection between the sensors for the drills, et cetera, and the sensors detecting some threshold and sounding the alarm and logging that. And now they were separating that. They were saying, well, if the sensors measure something, it creates an alert condition. And alarms are really just the expression of the alert condition. So by separating that, they now could actually answer much more advanced questions. What happens if two alert conditions happen? Well, maybe one is more severe than the other. Maybe there’s rules about which triggers an alarm, et cetera. So you’re basically changing, you’re not just, you know, we think of it as solving a problem, but it’s by, we think of it as, you know, understand the problem, come up with some potential solutions, pick the best one, you know, maybe make some trade-offs and that’s it. But it’s by sort of engaging with the solution, by trying solutions sometimes that you start seeing what the problem is really like, right? This is a very indirect way. It comes from the logs are not reflecting reality to finding a much better model for representing the whole thing and improving like the software significantly. Which, you know, the longer explanations in the book, of course. It’s super interesting. I’m one of the, one of the things I wanted just to sort of like, you know, when we, when we, when we’re just to give people a kind of image of like actually doing this kind of work, right? It’s often, it’s often very specifically with people in a room with a white board with sort of and post-it notes. And I love, I mean, I’ve had Alberto Brandolini on the podcast in the past. So we’ve talked about event storming and stuff like that, but like, and can ban people and things like that. But the idea of like, you know, I mean, we’re all familiar with probably with the image of like, you know, Einstein in front of the blackboard, right? But the, the, I just find one thing I find so fascinating about all of this is the invention of the post-it note and the use of the post-it note, because you can, you can, it’s a thing, it’s an object, basically, it can be a defined object. So this is a note, this, this, this post-it note represents an alert going off, but you can, I’m using my hands for anyone who can’t see, but you know, you can, you can actually move, you can pick it up and move, move them around. And this ability to reorder and reposition things is actually a very sophisticated tool for modeling systems. The point of post-its or stickies in general, they shouldn’t be called stickies, they should be called removies because you can move them. That’s the main point. That’s why they’re so practical for modeling. Of course, you can just sort of, and I do this as well, not just like moving because it’s in the wrong place, but just, you have maybe, you know, a few post-its that represents, I don’t know, a process or a stream of things or something, but you can just move them and say, well, what happens if this happens first, right? I’m talking about these awkward scenarios. What happens if somebody pays the invoice before you even sent the invoice or before you even made it? Oh, that doesn’t happen. Never, never, never. Well, actually this one time, right? That’s how you get there, right? You start asking these questions. Does this never happen? Will this ever change, right? Where does this go wrong? What happens if this happens first? Well, actually we had a customer once and they bought the same thing every month, so we send them the same invoice every month. So they just paid, and we were, this one month we were late with sending invoices and they already paid, but then we send the invoice, but because we didn’t get, the original payment wasn’t matched to the invoice, the system thought that the invoice was unpaid. So it starts sending reminders. And then of course the customer is not happy about getting reminders for something they paid. And it was all resolved with a phone call, right? And some apologies, but you can now use that awkward scenario as a way to find a better model, right? The model was, there’s an invoice and then the payment comes in and the payment gets matched. Now you can make it, if you want to, right? If it’s worth it, make a smarter model that says, well, a payment remains somewhere in the sort of unmatched status. And when a new invoice is made, you can actually check for unmatched payments and see if that actually makes sense to match it, something like that, right? It’s a very trivial example, but you’re sort of teasing at the edges, at the weird cases of your understanding and pushing that. Even if you end up not changing the model at all, right? If you say, well, this is an edge case, we can solve it with a phone call. It’s not worth developer time, but it gives you insight in sort of what are the limits of my understanding. Yeah. And that’s actually, so thank you very much for saying that the limits of your understanding. It’s so interesting because one of the things you talk about is that how modeling is kind of like the cheapest kind of work you’re going to do. I mean, it takes time. Time is the most expensive thing we have, of course, but it’s so interesting this idea of like, okay, let’s think about this scenario. We can construct a model and it could be like post-it notes or movies and lines and words and metaphors and nouns and find all the nouns and all that kind of stuff. And then you can decide, but we’re not going to build that, right? Because we’ve modeled it out and so we know what we would do if we were to build that. But now that we’ve modeled it out, we can actually make an informed decision about whether it’s worth building. Yeah. All design is trade-offs, right? There’s this infinite space of problems and you select some that you actually are going to bother solving. And then there’s an infinite space of solutions and you can’t… Sometimes people leave, oh, you look at all possible solutions and you pick the best, but that’s unknowable, right? You cannot do that. You use heuristics. You are sort of edging your way and trying something and exploring a bit. And modeling is, yeah, it’s the cheapest thing you can do. People complain sometimes, right? Why are you spending so much time on the whiteboard? Shouldn’t you be coding? Well, if you make a mistake in your fundamental understanding of how it should work and you code the whole thing and you put it in production and people use it and now you figure out that it’s wrong, it’s going to be a lot more expensive than just throwing away some post-its and trying again. Well, you said earlier, right? A model, maybe being that concept of modeling being scary, it doesn’t have to be very formal, but it is like science in the sense that what a model is in science, right? It’s an incomplete abstraction of reality, right? It’s how we understand some natural phenomenon. And they can be very simple. Like my understanding of if I drop my phone, I know it will fall to the floor and possibly break. My model of gravity is good enough for my daily life. But I don’t know quantum physics. I don’t know exactly what happens at the quantum level if I drop my phone. I don’t need to know that level of detail. But when you’re trying to solve a problem, you want to get close enough to the level of detail or a little bit over even the level of detail that you are going to need so you know where that edge is. And then same as in science, right? What does a scientific model do? It allows you to make predictions about natural phenomena. I predict that my phone will fall to the floor if I let go of it. That’s the model that gives us predictability. In software, if I have an understanding of how my system or if I have a good model of how the system works, which is not like a big complex legacy system. Nobody has the full model anymore. But if you can have that or in some area have that, now your system becomes predictable. That’s one aspect of it. And in software, we don’t care about that alone. But we care about if I’m going to change the software, is it still going to behave correctly? We are always modifying software. A bug is a misunderstanding in a model. We thought something would work a certain way. Or maybe it’s the interaction between two things that works differently or whatever. So there’s a second level of understanding, which is if I understand how my system works, I can also understand how modifying the system will impact the rest of the system. So if I make this change to get this specific behavior, will it impact these other behaviors? And in what way? If you understand that, then software development becomes a lot cheaper, effectively. Because a lot of writing code is not the job. It’s reading code. It’s understanding code. It’s having to figure out where in this huge legacy mess of this bank, which has been building software for 40 years, where if I change this, what else is going to be affected? How much stuff knows about this thing or is coupled to this thing or is cohesive with this thing? That’s the value of good, deep modeling. Yeah, you reminded me of an experience I had one time. So I was doing a doctorate in English literature. And I had a colleague of a friend who was doing a doctorate in maths. And one day I saw him. This was in England. And one day he had his backpack on and he was obviously going somewhere. I was like, oh, mate, where are you going? And he goes, I’m going to Edinburgh. The penguins aren’t hatching at the zoo. And I’m like, oh, now I finally understand what you do. And he worked on mathematical modeling of fluid dynamics at the micro level. But he got hired to help the… And it had nothing to do with the fluid dynamics. He got hired to help the penguin eggs hatch at the zoo or whatever it was, something along those lines, because he was really good at this modeling. And what you’re talking about is figuring out what are the factors that are involved in this and what’s the higher level system that’s at work. And understanding the system, but understanding systems itself is the stuff that makes it so interesting. And you apologized at the beginning of the interview for sort of getting philosophical right away. But you kind of can’t help it when you’re talking about things at this level. And so you’ve got a really interesting essay in your book called Critically Engaging with Models. And I was just wondering if you could talk a little bit about the idea of critical engagement with models and what that means. Yeah. I guess it grew a bit from the frustration that people sort of jump on the next thing and it will solve their problem, right? And then you have the hype cycles, right? Where it gets hyped and then goes through a valley of despair and then sort of it finds its balance point where it’s actually being used for the sort of things it’s meant for. And so, well, we say models, it could be frameworks, it could be organizational models, it could be anything, right? It’s not, it could be software, it could be something entirely different. But the whole idea there is if you really want to understand, if you’re adopting some model of something, right? And the examples we use are organizational, so the Spotify model or team topologies or agile fluency or, you know, safe for like, well, safe is more like a mix of stuff as opposed to an actual model. But if you adopt those, like, are you doing that based on a proper understanding of how well that will serve your needs, right? And these things like what any model tends to do, right? When you see it, it can look appealing, it can make you feel like, okay, this works, this makes sense, all the parts of it seem to fit together in a way that makes sense. But it doesn’t show you what it’s not doing, right? So team topologies is a way for organizing software teams. It has patterns and interaction modes and sort of concepts attached to it, but it’s not showing what it’s not for, right? So if you throw it at your organization, maybe you have actually a different kind of problem that needs solving. So what we’re proposing is how to actually use these different models to compare them to each other, to sort of have them, well, almost compete. And by doing that, you figure out what sort of their different contexts are, like these models were created in the context. The Spotify model obviously was created in the context of Spotify. I’m actually consulting for Spotify, and some people there call the Spotify model, they call it the Spotify 2012 model, because it just happened to be how they did things at a certain point in time. But if you start comparing these different models, you start seeing how they put different focuses, they have different building blocks, you understand, you know, the value system behind it, right? For example, both Spotify model and team topologies care a lot about or highly value team autonomy. So they have something similar. If you’re looking for team autonomy, that makes a lot of sense, of course, to adopt these. But then if you look at Spotify model, it uses, it has chapters and guilds, which are basically two structures or patterns for, not for organizing the work, but for organizing how you learn. One is for how individuals learn, right? I want to, you know, I need to learn more about Kubernetes or domain-driven design or something else. Can I find other people to organize with and learn together? And the other is institutional learning, where, you know, you develop standards in an organization or, you know, RFCs or ways of doing things. So Spotify model, because of its underlying value system, which emphasizes both individual learning and institutional learning, has patterns, building blocks for doing that. Team topologies does not. You could fit it in there, right? You could say, well, I take team topologies and I’m going to use these theme types to organize for learning, but it’s not built for that. It’s not designed for that. And by comparing that, you see, oh, wait a minute, just adopting team topologies, like, team topologies doesn’t tell you we’re not, we don’t have patterns for institutional learning. It just says, here’s patterns for, you know, moving fast and high autonomy and limited collaboration, et cetera. You know, it’s built for purpose, but if that’s not your problem, it’s not the right solution for it. I’ve worked on a, for a client that does the software for the drug fluid pumps in hospitals for chemotherapy, basically that sort of thing. So putting poison in people’s body, they don’t care about, you know, fast flow and team autonomy. They care about safety, right? Am I going to give the right dose to the right patient at the right time? If not, we might kill somebody. We don’t care about releasing, you know, we’re deploying 50 times a day. No, we care about being absolutely certain how you organize for that. If you then use a model for fast flow, something’s not going to work, right? It’s going to feel very, you’re going to get friction. Yeah, that’s what you call those life critical systems, right? And, you know, there’s just very, it’s very different if you’re sort of like, if you’ve got a kind of, like say example for a game, like a video game, for example, like, or Facebook or something like that, where like deploying all the time might be kind of, in a sense, I mean, you know, anyone working at any of the big companies will be like huge risk, huge catastrophes can happen too, but they’re not like, you know, you’re not going to be able to happen to, but they’re not life critical, right? Yeah. Yeah. It’s, but yeah, the whole idea is just figure out if the models you’re adopting in your organization, in your personal life, whatever, if they fit and if they, if you have to change them, if you can adopt them as this, and even, you know, sometimes it’s fine to adopt something as this, even if it’s not perfect, but now you know the difference. And it’s interesting too, like the, again, it’s sort of like, you know, to sort of like make concrete example of when we’re talking about models. So models for learning, for example, I’m recalling, I interviewed someone a while ago who worked at Spotify and they said that, I think I’m recalling two things that I hope they’re both right. One was that when it came to kind of like equipment, there was just kind of like extra equipment around in the office. So for example, you didn’t have to like apply for a new keyboard or something like that, right? There would just be a keyboard there. And you didn’t have to sort of go through a sort of formal process of kind of getting new stuff. And this was just a decision that Spotify made, if I’m recalling correctly, about efficiency, right? And sort of a lot of people would be like, well, aren’t they going to take them home and steal them if you just have this equipment around or stuff like that? And like, yeah, there’ll be some leakage, but overall, it’s a better system. And I think I recall correctly as well as that you were allowed without asking permission to just use a budget to go traveling to conferences and stuff like that. And you were just, it was just up to you. That was just the decision they made because it was more efficient in the end to let people make their own kind of training decisions rather than try to make those decisions for them. And that level of kind of modeling is super, super fascinating, right? Because it’s not all programming. Yeah. Those two examples you mentioned, I don’t know if they’re true, but they sound very Spotify-like, so probably true. One thing you talked about actually that sort of really struck a chord with me that you mentioned earlier was about being in the stone age still when it comes to programming. And that reminded me of two examples I have from the podcast. One was actually I had the privilege of interviewing Jerry Weinberg years ago. And it was a great interview. I still remember it. And one thing he talked about was like, I mean, I think the first computer he ever encountered was himself, like his first job was being a computer or something like that. But he talked about being at sort of like an IBM meeting in sort of the early days when IBM got into computing and how the executives were aghast when they learned that programming wasn’t a one-off thing. Like, oh yeah, you programmed the machine, we’re done, get rid of those programmers. There was someone I interviewed who I think was a computer science professor in the United States who talked about Git being the moment when it’s equivalent to when surgeons learned they need to wash their hands. And that we’re still in these very early stages in a sense and I was wondering if you could just talk a little before we go on to sort of the last part of the interview where we talked about sort of very practical matters or directly practical matters. What do you mean when you say we’re sort of in a sense kind of still in the stone age? Well, we’re constantly rebuilding everything or trying to change it. We don’t know how to build software that will last a hundred or a thousand years. Some of it might survive, right? There are still things standing from how the stone age is still standing. Not because it was genius architecture, but because most everything else got destroyed, but that accidentally sort of proved to be a much more stable structure, right? Same with, you know, we look at architecture from, I don’t know, the Greeks or the Romans and we say, oh, they were geniuses. No, most of the stuff is gone. Some of it’s stood standing by accident, but we learn from that. We learn how to keep, you know, why the Pantheon is still standing, even though it’s, you know, this structure that as a layman, I would never imagine that it could last so long, but it did. So we don’t have that knowledge yet, right? We don’t know how to build long lasting software. Our demands are much higher, right? If you want to repair a bridge, you close it down, right? You reroute traffic for a bit. We don’t close down software systems, right? They need to be working 24 seven. Most of them, well, my bank still closes their software systems sometimes in the weekends. But there’s a lot of stuff we don’t really have patterns for. We don’t have literature for long lasting stuff. We don’t have literature for huge changes, right? We’re either like small incremental improvements or replacing the whole thing. And most of the time, even that fails, right? There’s, it’s called the second version syndrome, right? Where the second version of something never succeeds or almost never. So in that sense, I think we’re still very, it’s still very young. The way we program, right? It’s very, you have to learn this abstract language. You have to type it in sort of very precise thing. I think in that, like, I think all programming languages are bad, right? They’re all very primitive, but we’re being held back by programs themselves. Programs are right now in general, not open to switching to visual languages. And because of that, like, well, they exist, right? Scratch is a beautiful programming language for kids where you use blocks. It’s very clever. You could actually do that to, you know, to do refactoring in a smarter way, where you move the blocks instead of moving bits of code, right? Textual code. But because nobody seems to believe in it, because the investment to invent a language like that, that is actually like a next generation from what we have now is very high. So the environment is just not there for major steps in there. We did have one big major step, of course, which is machine learning, which is, you know, or genetic algorithms, stuff like that, code figuring itself out. But I also feel like that’s very, you know, it’s statistics on speed, right? It’s not actual intelligence. And there’s no evidence yet, as far as I’m aware, that we will get to actual intelligence with stuff like that. So it could go any way. It’s invisible. I don’t believe in 500 years we’ll be writing code the same way we do now. But I also don’t believe that the sort of current alternatives like low codes, apps and stuff like that are going to be the answer. I mean, they are the answer for some things, right? The history of programming language and software in general has been higher levels and higher levels of abstraction, right? We’re not punching holes in a card anymore, right? We’re not doing machine code. We can, you know, do very advanced stuff with very, very little code, right? If you, you know, I can deploy a service somewhere in minutes and have, you know, glued together some existing other services and I have an app. That’s higher levels of abstraction. But I don’t know. I feel like we’re not. And of course, it’s all very speculative because maybe I’m wrong and it’s like this forever, right? We’re now at the end. Well, I mean, you just, that’s such a great answer because you just gave us a very great example of critically engaging with models, right? Which is like, you know, does programming, like when you, even the term like textual programming, you know what I mean? Like sort of all of a sudden, you’re like, wait a minute, hold on a second. I was always in this model that I wasn’t aware of that like programming had to be typing and symbols and like textual symbols. The structure of a program is not text, right? If you think about it, you think in blocks of things, you think in relationships between things, you think in, you know, passing stuff around, but all of that is using just, you know, the characters typed in linear files, right? So, there’s that discrepancy between those two is, I think, to me, that’s the evidence that there’s something else that we haven’t discovered yet. Just in the interest of time, moving on to the last part of the interview, we were talking about sort of, as I said earlier, a little bit more practical matters and believe it or not, there are people who skipped to the last part of the podcast to sort of hear about the person’s experience as a writer and things like that, but you’re also a conference founder. You founded the DDD Europe conference. And I just wanted to ask you if you could talk for a few minutes about how, because we’re still in sort of, who knows where we are in the current cycle of the pandemic, but how did the pandemic affect that project? Yeah. Well, we were very lucky because we had our 2020 edition in early February, which was, you know, people were aware that this thing might be coming and we actually had like, you know, the hand sanitizers in, you know, in different places in the venue, stuff like that, but nobody was wearing a mask yet or anything like that. So we were very lucky that, you know, I have friends who organize conferences who lost a lot of money. We lost money as well, but not dramatically. And then, yeah, the first, it wasn’t just a conference for me, but everything in the first few, like before that, I was always traveling to clients. We were doing in-person training. Everything was, you know, was on site. And we spent the first, you know, two months basically canceling stuff and postponing stuff. But then, yeah, and then I started thinking how to, you know, how to approach this. And I didn’t like, I still don’t really like the typical online conferences, which is, well, there’s nothing wrong with it, right? But it’s not the sort of experience I’m looking for. It’s, you know, people have it on their phone maybe, and they’re watching the conference while they work. It’s like TV in the background or TV with a chat box maybe. And Domain Design Europe, the conference has always focused very much on, you know, interaction, on engagements. We had lots of like hands-on labs where people spent, you know, two hours in a small group with a speaker, you know, modeling, coding, debating, trying stuff, et cetera. And yeah, we were afraid that we would lose all of that. But coincidentally, I was in a training by Dave Snowden at the start of the lockdown, which was supposed to be an in-person training, but it was moved online. And so he talks about, you know, dealing with complexity and how to act in chaos and all that stuff, right? He’s a complexity theorist. Maybe that’s the best description. And so that was the perfect time to be in a workshop with him because he adapted the workshop to talk about crises and how to act in a crisis. And one of the things he talks about, well, which I already knew, but then I really got it, is in a crisis, you cannot innovate, right? Stuff is on fire, right? The first thing you do is put out the fire. That’s where your energy goes. Now, actually, to go back to Jerry Weinberg again, he once said, it may look like a crisis, but it’s the end of an illusion, right? So stuff has always been going bad, but now it’s manifesting. And that’s what a pandemic is, right? It’s not that a pandemic is unpredictable, but it had to happen eventually. Nobody knew when, but something like that had to happen eventually. But so in a crisis, you cannot innovate. You’re trying to save the furniture, basically. But what you can do is what Dave Snowden calls acceptation. So acceptation is the way he, his example is he’s been like anything that can be used in a hotel room that can be used as a bottle opener, he has used it as a bottle opener. So clothes hangers or whatever. That’s using something for a different purpose than it was intended for. And then you can iterate on it. So it’s not like pure innovation, but you take something, you use it in a different way. You try to create an awareness of where that happens. You find those promising things, and then you can iterate and actually build like a much better bottle opener maybe. And then you have invented something. So that’s sort of the context behind it. So I started thinking, okay, what do we have? What sort of things do we have and how can we abuse them or reshape them or use them differently? So we had all those hands-on labs. We had an audience that actually came to the conference to do the hands-on labs, right? Not just, it’s not an audience, basically because all these years we have been doing all these labs, et cetera. The audience doesn’t just come to sit in a room and watch a speaker. They come there to engage with the stuff and do all these things. So we had the speakers for it. We had the audience for it. We wanted to make something that was, even though it was online, that was engaging. And we didn’t want to have a traditional online conference that is just talks. So then the little, the expectation thing happening was basically deciding what if we just don’t do any talks at all? So it’s a conference with no presentations, nothing at all. And we only have hands-on labs online in Zoom and in breakout sessions and with Miro. And we spend a lot of time sort of doing test sessions and trying things out and seeing what worked and coaching the speakers and working with them if they had never done something like that. And then we had a conference, which was a bit smaller, but which was only hands-on labs. People were engaging groups all the time, working together, et cetera. Some people told me it was the online, so people were getting tired of online conferences already by the time that happened. But some people told me it was the online conference. I didn’t know I needed it, which was to me the best compliment. That’s just fascinating that we can’t be together anymore. So let’s go completely hands-on. Yeah, that was the idea. That’s just brilliant. And the last thing I wanted to talk to you about was just sort of briefly, but when did you get into writing? Were you always a writer and a blogger? Or was that something that you came to later? As a child, I was always wanting to become a writer, and I had stories and I tried to write books. And at some point I had a friend who also was sort of into it, and we tried to write, I was maybe, I don’t know, 12. And he lived far from me, but in holidays when we were together, we would write together. And then we started actually snail mailing a floppy disk back and forth. Oh, no way. And then each would write like a chapter or something. And yeah, we wrote like, I don’t know, it was like a 300, 400 pages novel, which probably wasn’t very good. In fact, at some point we realized it wasn’t very good because we had to learn to write while we did. And then we started over, but then that never took off anymore. And I don’t have it anymore. So I don’t know if it was any good at all. But then, yeah, I’ve always enjoyed writing. Well, I mostly enjoy having written and writing. That’s well said. Same as a musician, I was a very slow writer. It was very hard. But now I, so I’ve been blogging since 2011, something like that. But not very, very frequently. And there’s years where I wrote nothing at all. But then I started writing with Rebecca. And yeah, I’m learning to write all over again. She has written books in the 90s and 2000. And she’s written papers and everything. And she coaches and mentors people to write. So she was like the best mentor I could have. And the fact that we care about the sort of same topics, et cetera. It started that we started talking at the conference and sort of became friends. And then we started writing together. And I’m learning to write. I’m learning to read it again. And I’m learning to write faster because I used to sort of edit while I was writing and overthinking it. And like, yeah, but if I say this first, I need to explain this other thing and I would get stuck. And with her, it just sort of, yeah, just dump it, just write it like it’s happening. She’s pushing me to do that. And then when we start editing, it’s really like digging into it. Does this really express what we mean to say? What do we actually mean to say here? That sort of thing. And then we started because for the, you know, engaging critically with models, we did a bunch of research and we started reading some books. And then I was basically, she was teaching me to read again as well. Like, okay, here in the book, it says this thing, but where does it get that? Well, it’s referring to that elsewhere, but then, you know, I start figuring out how it all works. And then you, sometimes you discover new insights. Sometimes you discover that something is actually written very sloppily, right? They mentioned something and then they say something that actually contradicts that 10 pages later. And so, yeah, it’s been, it’s been a fascinating process. I can recommend anybody who struggles with writing to find a mentor like that. Yeah. You know, that’s, that’s fantastic. And then that idea of I mostly like having written, I think it captures the experience for a lot of people, particularly those of us who, I think, I mean, maybe I’m similar to you where like, it’s kind of like, as I’m writing, I’m like, oh, wait a minute, what about these million different connections and just like getting, getting something down on the page, like, and just finishing a draft can actually be the hardest thing. Just know you can’t say everything all at once. Most of the blogs I published are stuff where I had sort of enough time and I, I wrote a whole thing and published it right away within, you know, two or three hours, because if I don’t, I start overthinking it again and I never finish it tonight. Yeah. I know exactly what you’re talking about. And actually, it sort of leads me to the sort of the last question that I always ask on the podcast, if the guest has published a book or books on Lean Pub is if there was one magical feature we could build for you or one thing that when you were interacting with Lean Pub, had you shaking your fist at the screen and going, damn you, Lean Pub, that we could fix for you. Is there anything you can think of? If it’s magical, then, you know, do the writing for me. Transfer my thoughts directly to paper. Yeah, no, well, here we didn’t really use Lean Pub’s interface much. We just, we wrote it in, well, we switched platforms a few times, but we ended up with Notion because we can collaborate and do stuff. And then, yeah, getting that into Lean Pub was pretty frictionless, I guess. There was a few times when, well, maybe that’s the one feature, right? When a preview fails and you don’t know why. That’s my, that was the thing that was the most annoying, let’s say. Yeah, thanks very much for sharing that. So for anyone, for anyone listening who doesn’t know, Lean Pub has various, what we call writing modes. The simplest one is the upload writing mode, which was the last one we created, which was like, people are like, I don’t want to use, I don’t want to write your way. I want to write the way I write. And so you can just upload a book to Lean Pub and that’s like easy, easy as pie. And then you can use all of our other features, but we do have writing modes where you write in plain text and you write in plain text and you write in something called Markua, which is our sort of markdown for books. And so what that means is that you’re writing in plain text. So you actually have to type in the formatting instructions into your manuscript itself, which in the olden days on typewriters, there was an underlying feature that meant, if you handed that off to your publisher, I want this to be in italics. So that was, it’s not as complicated as it sounds, but sometimes it is as complicated as it sounds. And so you press this button in Lean Pub to take my plain text manuscript, create a preview of it in PDF and EPUB. And sometimes that build process fails. And one thing we’ve just never been good at is saying like exactly what line, the manuscript essentially turns into a program, right? Like, what line broke the book generation process? And we’ve never been as good at that as we should be. And we should have better sort of error messaging and stuff like that. It is something we will get to one day, but thank you very much for sharing that because I think that probably most of the authors that I asked this question to forget to complain about that very specific thing. So thank you very much for bringing that up. Well, Matthias, thank you very much for taking time out of your evening to talk to me and to talk to our audience about your work and a super fascinating sort of theory about domain-driven design. Well, thanks. It was a pleasure doing this. Thanks. And as always, thanks to all of you for listening to this episode of the Front Matter podcast. If you like what you heard, please rate and review it wherever you found it. And if you’d like to be a Leanpub author yourself, please check out our website at leanpub.com. Thanks.