In this Episode
Alberto Brandolini is the author of the Leanpub book Introducing EventStorming: An act of Deliberate Collective Learning. In this interview, Leanpub co-founder Len Epp talks with Alberto about his background, how he got into programming and eventually consulting, what the EventStorming process is and its relation to domain-driven design, the "dungeon masters" of company software, and at the end, they talk a little bit about his experience as a self-published author.
This interview was recorded on April 23, 2019.
This interview has been edited for conciseness and clarity.
Len: Hi, I'm Len Epp from Leanpub, and in this Frontmatter podcast I'll be interviewing Alberto Brandolini.
Based in Faenza in northern Italy, Alberto is a consultant and popular conference speaker and trainer. As the CEO and founder of the IT consultancy Avanscoperta, Alberto offers a 360 degree approach to his clients, covering areas from software development and high-level architectural decision making, to project management and organizational change.
Alberto is the inventor of the EventStorming workshop methodology for improving processes and visualizing large scale complexity, and is the author of the related Leanpub book, Introducing EventStorming: An act of Deliberate Collective Learning. In the book, Alberto sets out in detail what the EventStorming process is, and provides guidance both for people interested in participating in EventStorming workshops, or conducting an EventStorming workshop themselves.
In this interview, we're going to talk about Alberto's background and career, his professional interests, EventStorming, his book, and at the end, we'll talk about his experience as an author and using Leanpub to self-publish a book.
So, thank you Alberto for being on the Leanpub Frontmatter Podcast.
Alberto: Thank you.
Len: I always like to start these interviews by asking people for their origin story. I was wondering if you could talk to us a little bit about where you grew up, and how you first became interested in software and IT?
Alberto: Well, I've been traveling a lot, but I grew up exactly where I'm living now. Faenza's my hometown. And even if I lived somewhere else, and still traveling a lot - I actually get back to my roots. I realized I just need to be driving distance from an airport, that's good for me. I enjoy my local food, and I travel on the weekends. I travel basically all around Europe during the week.
I think everything started for me when I was 12. I got the Sinclair ZX81 Spectrum, as a Christmas present. I started coding at that time. The dream was to build my own video games, and that's how my generation started. I'm still coding after more than 35 years now, and yes, the idea about coding - I would like to solve problems, would like to make somebody happy with some code. But then the more I advanced in my professional career, the more I realized actually coding by itself was not only the answer. So I needed to take care of everything else that was happening around the coding.
Maybe it was the context? Maybe it was just the collaboration, which was not working? Maybe it was the mood of the team? Maybe it was - one customer, I actually had to tell him, "Look, you don't need a coach, you don't need a consultant. You just need to open some windows here, because there is no oxygen in the afternoon, and everybody's having a headache after two o'clock." The answer - it was trying to make things work, and looking around about the reason why things were not working.
And this also led me to experiment after experiment, to EventStorming - like a consequence of a lot of little variations. The biggest one was, at that time - the whole story started something like actually five, six years ago - at that time I was traveling with an IKEA paper roll in my backpack. And this is kind of a weird thing. Like, why is a software consultant going around with an IKEA paper roll in his backpack? I mean, it was the type of thing - you can buy it in the kid's area, for people or for kids to draw.
And the reason why, was, I was sometimes given a meeting room, and the meeting room was very small, or maybe used a flip chart. There was a whiteboard, it was too small. And I said, "I'm not solving small problems, I need a larger surface. Because I need to visualize solution to large problems, and I don't have enough space." So instead of waiting a couple of weeks to have a good booking on the most important meeting room of the organization, I don't have to wait these weeks in order to have the room. I have my meeting room in my backpack. So that was the attitude. "I'm not following your rules. If I have a problem, I need to solve the problem." If the problem is, "I need to visualize a complex solution," I'm going to bring my own whiteboard with me.
Actually with one customer, I went further. I asked for whiteboard. They said, "Oh yes, you're going to have it." And then they told me, "Are you going to have it in three months when we move to the next building?" The morning after I came with my car, and I brought a big whiteboard in in my trunk. I started doing a modeling session in the corridor, and the manager came to me and said, "What the hell are you doing here?" "Well, I was asking for a whiteboard." He said, "In three months." "Okay I just need it now, so I brought mine." He was completely offended, because the company was really rich. And it looked like I had to use my own money to cover their shortcomings. The morning after, basically, we had 20 white boards. Because he was so offended, and I realized, "Okay that's one way to make things happen." Just start with your own stuff, and then - you don't wait for permission or stuff like that.
Len: Speaking of doing things your own way - I've got a lot of questions to ask you about EventStorming and how it got going. And I've heard a little bit about that story from one or two talks you've given about having the roll of paper in your backpack.
Len: I wanted to I wanted to start by asking you - one of the recurring questions on this podcast, because so many people who are Leanpub authors, are programmers or people who got their start in programming. I wanted to ask you about studying at university. You have a post from a few years ago now, from 2014 I think? Where you wrote, "I remember my days when I was a university student, I hated it." In the post you talk about how basically, it was just this this rote learning experience, where everybody's just going through a meat grinder. And then you get exams at the end of your term, and things like that.
If you were starting out now in 2019, in a career in software engineering, would you go to university?
Alberto: Probably yes, but not only. Well, a little disclaimer. My organization is also offering training classes. So we are in the consulting and education market. But there's something that we learn as - We started learning better learning techniques, better learning approaches, nd teaching techniques.
And the university as an institution is flawed. There's a fantastic TED talk from Kevin Robinson, saying that, "University is optimized for creating University professors. Students are something like a byproduct. What they think are the best students, are actually hijacked to become the next generation of professors."
Even music schools have suffered the same dysfunction. It's not really optimized for the learning. And some dysfunction might be like, not so much feedback loops... Now, I'm talking about the university I was in. And nobody has students, "How was this lesson?" Nobody asked the students, "How was this course?" But, students are a weird beast. Because you're asking somebody information about something they haven't really mastered yet. But still, they can tell you if the lesson they just took was incredibly boring. That's already something important.
The thing that I really didn't like at the university was, there was not a feedback loop. Nobody ever asked us - only one professor of 30, approximately - that actually looks back, and look in our eyes, and says, "Okay, you didn't get it. I'll try again, my fault." That is teaching, but everything else was just like crap. The thing is, as systems - universities cannot really keep up the pace, especially technical universities.
Not every university is in need of improving, keeping up pace at the same speed. If you're teaching history, history is not changing at the same pace as technology. I mean, it will change. Or if you're teaching languages - it's moving, but the core stays the same. Still, universities as institution, don't have all the feedback loops in place. They don't ask the market what they should teach. They don't - I mean it will really sound weird, but there are so many things that they don't ask - and they are having internal feedback loops.
Having said that - some of them are better, some of them are really bad. There's a little bit about being Italian also here. But learning is too important just to leave it to an external institution. So I would say, what is going to happen progressively - self-learning is going to get more and more important. And what we are trying to say to our customers, but to our colleagues too, is, don't delegate it.
I have kids who are teenagers, are going to get closer to university. And okay you got to take a degree, probably. It's oing to give you a better placement on the work market. But it's not the whole story. If you just think that, "I got a university degree, and this is going to be enough" - tou're going to be a commodity on the job market, You've got to be special, and this specialty comes from your individual learning, from the perfect mix of your passions, your curiosity, your opportunities for having experience - and the connection you can make between interdisciplinary experiences.
I am a software developer with a special ability in drawing comics. And I realized the other thing that made me special when I facilitate workshop, is - I used to be a drummer, with not exactly a jazz background, I was a little bit more of a rocker - but I was good at improvising. When you are on stage, and your guitar player is starting with a solo - you have to follow. You don't get to stop, "Oh sorry, I didn't understand this." No, you keep up the pace, the show must go on - and you have no idea what you're doing, but you pretend that you do. And this is exactly the type of cross-disciplinary influence that made me good in being a software developer.
Len: One thing I really liked about what you said was, there are two sides to the coin of education. One is what you're being provided with, and the other is what you are doing yourself - the initiative that you're taking, and it's sort of, I don't know if it's exactly ironic? But it used to be that actually universities were understood to be more like that. Basically, when you attended a university in the olden days, and I'm talking about a couple of centuries ago, the idea was that you showed up and, and what you had was the opportunity to be near a library and near books, and attend lectures by leading thinkers in an area. But the idea was certainly not that university was a place where you went to be trained, more or less, for a job. I mean there would be things like the law and the priesthood and things like that, where there would be things that were like training, but it was more like, "Here's this wonderful resource. You've paid and you've got the time to sort of be there, now what are you going to make of it?" - was the idea, and it was this two-sided thing.
That's a very good point about how universities are optimized to create the next generation of professors. As someone with a doctorate myself, I'm definitely a beneficiary of a system like that. I was a fish in water. But not everybody was, and a lot of it was about anticipating becoming the prof, and not necessarily anything else.
I wanted to ask you a question now. This is going back a ways. But on the subject of education, you're the second person I've interviewed in the last couple of weeks who participated in the Erasmus program for foreign exchange in Europe, and I was wondering if you could talk a little bit about your experience with that? One of the reasons I like to talk about things like this is, in the context of the like Brexit - the importance of moving around and going different places and learning about the rest of the world.
Alberto: Well, for many, many reasons, I took an Erasmus year in Finland. That was 1994, 1995 and I met my wife over there, and two daughters happened as a side effect of this experience.
As a student, I actually didn't do anything special. As a survivor, as a learner it provided me a relativistic point of view. I thought things were obvious because I only saw things from the Italian perspective. Then I went to being in a cultural environment that was completely different. In Finland it was a lot less cult of personality in the role of the professor, a lot more availability and friendliness and informality.
But at the same time, there was also talking about how education was organized. Let's say in Italy, the university is providing mostly a fixed plan. You have to take the whole sequence of exams in order to get a degree. But there is not much variation between individuals. It's probably okay with some professions that need to provide coverage to disciplines, let's say medicine. You would not give so much freedom, you cannot choose to ignore infections in your path. That's okay. But in some other places, it just creates commoditized roles. "I finished my degree, and I'm exactly just like the other student. And so in the job market, I tend to be really, really weak."
I met a person in Finland who was, at the same time, taking a degree in electronic engineering and philosophy. I still don't see the connection between the two, but there is one person on earth that could find this connection, and maybe have a niche market. And the stupid thing in Italy was, this is actually forbidden. I mean, why do you forbid a person from taking two degrees at the same time? It's a personal choice, no reason to block it. I suspect there's an IT problem behind it. Like, how do I record this in a database somewhere? And so let's block it. Nobody would like to do this.
But I experienced this freedom. I saw, "Okay, this is possible." You can think about designing your own career. "Why not?" There's no good reason for not doing this, provided that you're not economically a parasite on the public. But if you can do it, if you can use this money as an investment and get two degrees at the same time - good for you, good for everybody. You are the person that could make connections.
If you want even more background about it - Erasmus was great, and also actually made me a lot better at speaking English. Italians are not very good at this, and I was forced to became better, because Finnish is very, very tough to learn. I had one year, and I realized I could become maybe become decent in English, and have a decent conversation with people. So we started hanging out with people from the United States, England, France, Germany and whoever was there. That was fun, and the moment I started dreaming in English I realized - okay, something opened in my brain, and it's working.
Len: That's a fantastic story, thank you for sharing that. It turns out you're not only the second person I've interviewed in the last couple of weeks who did the Erasmus program, but who also met their wife in that time.
We'll move on to discuss domain-driven design and EventStorming in just a couple of minutes, but just to understand a little bit more about how you got to be the CEO of a consultancy, did you work in industry for a few years?
Alberto: Well I would not use the word "CEO," but I worked for a consultancy company for seven years. And then I became freelance, and I realized, "Okay, I need to do something bigger than just my name." So I started my own little company. The company's still really small. We are just like five employees. We have around a dozen external collaborators. The thing which is really good is - those guys are really, really highly talented, some of the best talents in our field in Italy. Some as trainers for some classes, maybe as collaborators.
But the thing which is working really well - we spend a lot of time working with really smart people, and we make new stuff happen. We don't we don't follow the books, we are actually writing them. And it is not exactly a metaphor. We are trying to do new stuff, because we are confident we can we can make it happen. We always had a plan B. But if you have the best talents around, you feel like, "Well let's try to do some more interesting stuff. Let's try to do something different today."
Len: And so before we talk about EventStorming, I thought we should lay a little bit of groundwork. I was wondering if you could talk a little bit about domain-driven design. I know it's a huge topic. I interviewed Michael Plöd recently about it. But if you could just give a little bit of an introduction to what that is?
Alberto: I'll try. The thing about domain-driven design is, it's an approach for software development, where learning is really crucial. Where all of this focus about the learning is exactly because - in many projects, learning is actually the bottleneck. One other thing we have to acknowledge is, not every software project is the same. There are some software projects which are a little bit more than cut and paste. You just have to build something which was more or less like the thing you developed already for another customer. Blah, blah - kind of boring if you are smart. You already done this - a little bit of customization
Domain-driven design becomes really important when you're dealing with software projects, where you can't understand everything upfront. Typical examples are finance, for software developers. Okay, you can read books - but you can't understand everything in one shot. Or you get in some domains, which are evolving so quickly - that everything you learn a couple of weeks ago, is now obsolete. Because things are changing, and you're riding a wave, and whatever you learned three weeks ago, is no longer valid. So you have to change the underlying software.
The idea about domain-driven design - you don't want to lose these details. You want to make sure that your understanding of the domain and your code are as much in sync as possible. Every distance between, "Oh this is how I understand, and this is just the code which is running works," is risky - creating a gap, and it might make the procedures around the software, that are bumpy. And get to the point - to even inject pain in software developers - you have to remember this, you can make mistakes, mistakes can be costly and create an unhealthy environment.
The thing that I experienced in a good project applying domain-driven design is, it's just like we solved very complex problem. We had a team of people that was feeling safe, because our software was rock-solid, it could not break - even if we were managing millions in banks, and stuff like this.
Software is a machine, it has to run predictably. The moment you have this confidence, then you're a different person. You're not just crossing your fingers if you're deploying something in production on Friday. It's just another day. Whenever we deploy something to production, it just runs. Or if it doesn't, we roll it back in five seconds. And this confidence, "Oh well I can breathe, I'm relaxed. I'm not leaving, not having nightmares at night." - it just creates a safe environment for, "Let's make another experiment, let's try something new."
If you don't feel confident, you don't try, you don't make experiments. It's about the learning, and the confidence. Because it's a vicious cycle. Just like if you are stressed, you don't learn, because of the chemicals in your brain, when you don't make experiments, then your code is actually becoming horrible and holding back your organization.
While if you play with the code - if you feels like, "Oh it's a game, why don't we do this?" From the outset, you don't even look like you're learning. And then you're doing something amazing. You're smiling with your friends, and making it happen. That's exactly the place where I like being. Solving very complicated problems, with an approach that allows me to do that.
Len: There are a lot there a lot of really interesting threads to pull on there. For example there's this little bit of a tension between having a determinate system, one that you can have confidence in exactly what's going to happen, and experimenting. And then - you can do an experiment, because you don't know what the outcome is going to be. And having a foundation of predictability on which to do experiments, is really important.
One can imagine a sort of nightmare scenario for a software developer, where there's a group of executives who are running a business who decide they want something. And then they have a group of people underneath them who are tasked with bringing that about. And then they assemble teams beneath them, who assemble teams beneath them, who assemble teams beneath them. And then you end up with some very specific requests. Like, "Hey, computer guys, go make this happen." And domain-driven design is meant to say, "That is a very bad idea for doing things." At least somebody along the way in the business side of things should have some understanding of the way the technology works. And people on the technology side should have some way of understanding the business domain and how that works.
For example, if you're working in finance, as you said, the people on the development side should have some understanding of the regulatory situation, and the way that can change, and the policy - how a user is actually someone who’s maybe defined by policy.
And so EventStorming, which you invented - is this very unique idea for getting a group of people together from different sides of the business, to understand what they're doing - even if they're already in the midst of doing it. Is that a good way of putting it? Please say if it's not.
Alberto: Yes and no. I try to de-emphasize this, because whenever somebody says like, "he invented," it makes me feel like I had a plan. No, I didn't. I just was traveling with an IKEA paper roll, and some friends asked me to model a complex process. And I said, "Okay there is no time and space to do a proper UML diagram, let's just use the paper roll. Let's get the stickies, assign colors to the stickies. This is my process." But I did it in less than 10 minutes. My colleagues who were facing the same problem didn't even start.
So I look around say , "What's your solution?" And they were looking at me, "What the hell are you doing?" "I just cast my solution - and maybe it's not good, but I have a prototype, where's yours?" And I said like, "Zero, zero, zero, zero - okay, this round is mine. Just like playing poker." I realized, I had something. Because it was really, really quick in having a solution. But they thought I had a good solution, that was a little bit of a trick - I just had one. And then I was completely ready to destroy it if somebody was coming with a better solution or with a variation. But now we had something to discuss.
And so it started as, I said, "This interaction is interesting. Let's use it in some other contexts." And we started making experiments - initially the educational workshop, then in projects. And a few years later, I used the variation on the same technique to design startups - to do to do management consulting, and to design software. It's very, very flexible - and I realized that now I know a lot more about the mechanics and the reason why it's working. But it didn't go like, "Okay, given all the books that I've read, given this problem - what would be the solution?"
No, t didn't work that way. I did something just because, I was between friends, it was a Saturday, and it was a challenge, a little game. "Okay, I would solve it in a different way." So that it is not exactly a metaphor, but - you do different things in a different context, with a little pressure - but not too much. And then, okay that was a good idea.
Len: It's a really fascinating model, when you see it. You can see pictures of it if you search for "EventStorming" online, or of course if you get the book. But essentially, this roll of paper is literal. You and the way that you've worked it out now, is that you go to a room, and you have this roll of paper which you roll out as long as you can - taping it to a wall at about eye level or so. And this represents from left to right, a time sequence.
Len: Or at least a process sequence. And what people are asked to do is to take these post-it notes, or sticky notes, in various colors - and the colors represent types of things, let's say.
Alberto: Yes, but we usually start with only one color - which is orange, for a weird reason.
Len: Just on that note, so orange is domain events. I was wondering if you could say what a domain event is, and why orange?
Alberto: So, I don't even call them "domain events." It was really a term from domain-driven design. Now I just try to call them "events," so it makes things easier.
It's the building blocks for storytelling - something that happens in a field, in a domain, in a given moment in time. When I pack the room with different people invited, everybody knows a portion of the story very well. And they probably know the whole story, but not that well. Ao it's just like starting to build a story in an unordered way, chaotic at the very beginning.
It's just like, "Okay, this is what I know." And I don't care about the surroundings. The second step is, "Okay let's try to sort it out - to try to make the story, which is consistent from the beginning to the end." And this is where people start talking, because, "Oh, I thought you were doing it that way. No, we do this before this step. Okay, this has to happen. We don't do this if you don't receive an order. But sometimes we do this - even if we don't have an order, provided that the customer is trusted." So the story becomes more complicated, richer in precision.
What we are using is is the innate ability of humans to do storytelling. The stories have to be consistent. We gathered around the fire centuries ago, around stories. So we know when the stories are bullshit, and everybody's correcting somebody else. "No, you're missing this event. This is not always happening this way, and there's also this scenario." This collective effort, to make the storyboard solid, creates a collective understanding, which is a lot deeper than collecting requirements, and so on.
Fetting back to domain-driven design, the illusion that I discovered - it started like - we are software developers trying to understand the domain, and this is an accelerator for our process of learning. Now I am calling bullshit a little bit more. Like every person in software starts with the illusion that I'm talking with the business people. The business people know their business. That is bullshit. The business people don't really know the business. They won't ever admit this - but their knowledge of business is not as sophisticated as software people need, in order to turn their requirement into software.
Software needs precision and people are really expert about everything that happens in their own department and silo. This knowledge is usually really, really good - but a single person doesn't know the whole story with the same degree of precision that we need. But they won't admit it.
In order to turn this complexity into software, we've got to make sure that this complexities table is not unlimited bullshit - or friction and misunderstandings in the border between one silo and the other one. And so what happens is, we see the business actually clarifying the business to themselves under the eyes of software developers.
Okay, now this is a story I can understand - and that the story is compelling, is clicking. I don't see endless branches. "Now this is making sense to me. Okay, I can turn this into code," or "I can write the portion of the code which is solving your most important problem.
Len: It's really interesting how much, in your writing, and in your talks - how dealing with people is one of the most important things. And you emphasize the importance of inviting the right people to an EventStorming workshop. You also write about the distinction between a startup, where it's not necessarily that difficult to get everybody in the room, and they're all excited, and they can't wait to have a comprehensive understanding of everything that's going on. And then the big company - where getting the right people into the room, I mean even knowing who to invite might be hard. Getting them to come might be hard. And you actually have a concept of a "dungeon master" in a big company as well, which I wanted to ask you about in a moment.
When you're brought into a big company, how do you get the right people to come to a meeting?
Alberto: Well, it really depends how big a company is, and how willing are they to actually solve the problem. As a consultant, it might be a matter of how big in the hierarchy is the person that called you in, basically? Because if this is coming from too low in the hierarchy, and you're begging for attention - the magic is not going to happen. You can do it iteratively, try to do, "Okay that's a good result in a local space," and then let the word spread out, somebody might call you later for a higher level meeting, a workshop. And that actually happens sometimes.
But as a consultant, I can tell you - if it's very hard to invite the right people beforehand, okay let's not even try - let's do something educational. Take your time to get political momentum inside the organization, and eventually we're going to run the very important workshop later on if possible - or maybe never. But usually it is already happening.
There was also another thing that - it might be funny, maybe not? May be presumptuous? But there was a person telling me, "Okay, I know your tactics, Alberto. Now you're giving talks in conferences so that you can get more customers." I thought about it, and said, "No that's actually the opposite. I'm giving talks in conferences, not to get the wrong customers." I'm actually kind of aggressive when I'm on stage, to make sure the wrong customer is never inviting me.
I have only a selection of customers that want to do exactly what I promise, deliver, and I like to do. The wrong customer is never calling me. This is the perfect place to be in the market. I have only a few weeks per year where I can work, I don't want to go in wrong places. And this is really helping me a lot. So I don't know, many other places are wrong - they won't ever do an EventStorming. They may need it, but it's not my problem. I'm a finite resource, so -
Len: And what is a "dungeon master" in a big in a big company?
Alberto: Oh, it might even be in a small one. The dungeon master is actually a byproduct of some dysfunctional software development environment. I named it after a talk from my friend [?]. The dungeon master is usually the author of the previous version of the software. Or it might be the person that is still around as a architect, maybe became CTO? It's usually a very nice person, and feels like it's a needed one, but the evil behavior is not conscious.
It's just like, you can picture this person's personality's torn in two. He would like to write a new version of the software which is going to be better. But not that much better, because unconsciously he might feel like, if the new software is solving the problem of my old software, then I am stupid and maybe...
The other thing, it happens where a difficult partner, like the author of the previous version of the software, rhe software is not exactly finished - of course it's not, no software is perfectly finished. But he's still around, and is doing a lot of manual intervention. Sometimes overnight. Sometime when nobody else is watching. It's not because it's a secret, it's just because that's the only time I am not interrupted.
But at the same time - this mastery of this little environment, which might be kind of fragile - makes this person the only person actually allowed to touch a sensitive portion of the system. It becomes dysfunctional once you get apprentices, I call them "minions," just in this case - because you can never beat your master, because the master always knows something that you don't. Because the holes in the existing software would never, ever be documented. Because if you document the holes, well probably it would have been better for you to close the holes instead of documenting them.
This is the spiral - you want to change stuff, but you always fail, because you can never be as good as your dungeon master, because the master knows the secrets. Then if you fell like probably quitting the company or lowering down the bar, it's like, "Okay, am I going to be minion? It's fine, you touch this area - I'm never going to change the software again." And year after year, this becomes completely dysfunctional.
It's weird in projects to deal with a person like this. Because you can smell this continuous contradiction, "Yes, I'm here to help - but not really." And it's not an evil person. It's a person which is trying to help, but not really.
Len: It's very striking. Even if you've never seen it before, it's probably recognizable, as soon as it's described that way.
You've got another concept that I found quite striking, which was-- I don't know if I'm getting too specific for you? But hypocrite modeling.
Alberto: Oh wow.
Len: I've got I've got a little quote here, which you define as, "Unnaturally pushing complexity outside the software." Does that does that ring a bell, or is that maybe too deep in the weeds?
Alberto: I think I don't remember this one. I remember writing about it, but I don't remember the reasoning and the context behind it.
Len: The reason it struck me is that, I've seen it a little bit, just myself. I'm not a developer, but I've been involved with developing a couple of projects. And often - the reason it's such an important issue to me is that - as Marc Andreessen said, and I bring up on this podcast all the time - and this was years ago now that he said it, but, "Software is eating the world."
And everything that we do, the world is being built on software now. And so the way software is built is the way the world is being built. And when things that are specific to the way software is built leak out into the world, that's a problem that we're facing now, in ways that we might not have faced in the past. The reason I like the concept of hypocrite modeling was the idea that people can be letting the methodologies that they're using to build their software, determine how the products are in the end, can actually be a serious problem I didn't put that very well, but--
Alberto: Well actually, that was not bad. You actually made me think about my focus in the last years. Now it has a little bit more specific name, I learned the term a couple of years ago, which is "socio-technical." We're using tools. Tools are forcing collaboration in a given way, and are shaping the way we are interacting with our colleagues. This might be true for a group of people collaborating over Slack or Trello, or thing like this. But it is also true for a team of software developers, which is more or less forced to build software on top of an existing architecture. And this is exactly where the dungeon master becomes a behavioral pattern in this area.
Just to point out the possible difference. If your software architecture is decoupled, you can have two teams that could go on more or less independently. They will have a little bit of interaction. But if the same teams are sharing something which is a little bit more fragile as a form of interaction, like a database, their architecture - we force them to have a lot of meetings, to make sure that my change is not breaking your stuff. And these meetings are poisonous, are boring - and are dangerous. Because people hate these meetings so much that they will try to postpone the development because of this. So the architecture is forcing too tight collaboration.
And a lot of communication which is - I would say more than 50%, is blame. "You brought my bill. You introduced a bug in my software, you should be more careful. You should not touch this area."
"Well, if you had the proper architecture, this stuff is never going to happen." As a metaphor really dumbing it down, I would say, "You can save your relationship with your spouse by having separate bathrooms." And just like, "There is no discussion on the protocol where to put the table down or up. Because you have two separate things, and this conversation is never going to happen. And then you only talk about love or more important things and not about the toilet."
Sorry for the gross matter, but it just provides the idea - giving you the topic to talk about, and this topic is, "Well, let's talk about something else."
Len: It's really interesting. So you didn't invent EventStorming, but in a moment of inspiration under pressure, you came up with this this process, that eventually became named, EventStorming. And it began to spread. I was wondering if you could talk a little bit about what that experience has been like?
Alberto: I actually don't recall exactly the timing. I guess one of the pivotal moments was - I was already well-connected in the domain-driven design community, and I was providing this little workshop in a conference in Italy. And yes, a blog post on that was already spreading some interest. But probably a pivotal moment for the diffusion was being a kind of a special guest for a Vaughn Vernon DDD tour. I think it was year 2013 or 2014. I don't exactly remember the date. But I was a special guest in the Belgian and the Polish edition.
It was a large workshop, something like 70 attendees in Belgium, more or less the same number in Poland. And usually when you have these numbers, the average is not really good. But that the average attendees were really, really smart. We ran this worship as one of the closing activities, and I have 70 people running multiple EventStormings in parallel, and they loved it. They started to practice and experiment, and the little community was born.
So it was a lot of people from Belgium, the Netherlands, even France and Germany, that came to that workshop. And suddenl, I had the little team of experimenters that understood something: they didn't understand the whole story. This was creating all the variation I needed, because I was doing a lot of stuff with more or less my recipe. And they were practicing in ways that I could not even imagine, because, for me, they were wrong.
But they were okay. We started a conversation. It was a like a Darwinian explosion of variation, and what we saw was the variations, were surviving. That was a little little boom.
I realized, "Okay, now I have friends practicing with this, asking for feedback, giving me feedback, and all this stuff." This was something like magic. People like my stuff and use that, and told me it was useful. And then it was a little bit of a drug for me, like I got addicted to this, "Well, well - you're using my stuff, so I will tell you also this and this and this variation. Try this, try that." It's kind of a good feeling. If there is one moment it is that.
Len: And eventually you decided to write a book, and that's been quite a journey as well. How did you get started writing?
Alberto: I felt like I had to. I started with a blog post, and the blog post was telling - just to leave it out of the story actually. If you see the blog post now, it's badly outdated. Because the sequence, the process that I described at that time - is not the one that I'm using anymore.
I actually don't recall exactly what was the thing that was forcing me to write. I felt the call. I felt like, "Okay, let's do this." Well now, let's be honest - Leanpub had a great role in this. Because it just allowed me to try to write a book.
The story for me was, I already tried to write something, and every attempt on some other topic, basically collapsed around page 40,50, under its weight.
And Leanpub was providing me the opportunity for trying to see what happened in writing. And now I have a connection with some paper publishers, more traditional ones. But I'm actually happy that I was dealing it in this way. Because maybe that book would never came out.
I'm very bad in managing the pressure, and I know what happens with publishers. Their deadline is not exactly your deadline. I mean, there's a way to drive you. But there's a little bit of this pressure. And I might do great things under pressure sometimes. I had fantastic ideas, or I might just completely freak out and say goodbye to everybody, because, "No, no, no, no, no - this is insane, I don't want to do this."
Leanpub allowed me to run the experiment. It was weird at the beginning. I already had something like a 50, 60 page manuscript that I was writing in Pages on my MacBook. I'm not exactly a programmer, but I'm still coding. I'm also a visual person, and one bit of advice that I found most disturbing at the beginning - was, "Just start with some text and then you fix the pictures later." I found this close to offensive. I am a visual person. I need to make sure that I find pleasure, get a little reward, seeing a page which is looking exactly the way I want.
I was spending a little time with fonts at the beginning, even on Pages - crafting the template and the story. Because I realized later that the thing that was making me go on page after page, was the little sense of beauty of a completed page. Just a little bit decorative. Sometimes I found myself rewriting a paragraph, just to make it fit in two lines, so that the picture was getting in the same page. This is annoying, this is probably wrong on so many point of views - but it was me.
And since it was my pleasure that was giving me the energy to keep writing as I like - I had to not to pretend to be a monk. No, I need this little micro-reward, and the page needs to be beautiful.
Also I spent a couple of weeks trying every possible Markdown editor. I actually hated Markdown at that time. Now I'm okay, now I found my combination. Actually I'm using two, I'm using Sublime or I'm using VS Code - and I'm happy with both. But at the beginning, oh yes - I discarded a lot of stuff. Because Markdown was the standard - but not exactly a standard. There was a little thing that would make a lot of difference.
Len: You've touched on something that's very deep Leanpub, but very deep publishing as well. Which is - in the past, I mean like pre-1980s - when people wrote, there was never an expectation that what you were writing is how it would look in the end.
For example if you're handwriting on a page, you expect to give it to a publisher and then they'll set the type - in the old days - things like that. But then desktop publishing became a thing, and I've had the privilege of interviewing some of the people who did the earliest book publishing on desktop publishing - I mean, this will expose me as being of a certain generation - but when the Mac came out, and you could have a visual representation of a page - and be typing on it, and see the words in some approximation, on a screen, as they would appear on a page - that was a magical thing.
And then you would have a machine called a printer. I don't have one really anymore. But you would hit "Print," and then it would look like what you what you did on your screen.
Len: And this was an amazing thing. One of the challenges that we've had at Leanpub, is dealing with that impulse to want to see how it's going to look as you're writing it. I think it was my colleague, Peter, who founded Leanpub, who came up with the phrase that "formatting is a form of procrastination." And we don't say that flippantly. It's like, it's because we want to do it too ourselves, all the time.
It's this constant struggle, when you're writing, this really constant internal struggle. Because as you say, you know it's just part of you to want it to look perfect.
Len: But at the same time, you know that this desire for that type of perfection isn't necessarily going to translate into anything that other people might care about in the en.
Len: But nonetheless, that impulse is-- For some of us, that impulse is just there.
Alberto: Many of the authors that were suggesting this to me, were talking mostly about coding books. Okay, that is great. I mean the support for coding is fantastic. It's just like, format the code just as it is, and you're actually giving extra value. Support for pictures - well it's just like, okay, then I say it again with pictures. I can believe you that it will include pictures. But I would like to see it with pictures now.
The other reason for me is just, I'm drawing my own pictures.
So my set-up when I'm in my writing days, is - I'm typing with my MacBook Pro, and I'm drawing with my iPad. And then if there's a little bit of image editing to make it fit in the space, in the page, formatting - taking and making sure that you're not having backgrounds. So all this type of stuff. I tried a few experiments about how to make images, and then I finally stabilized on the iPad.
But it's still me doing two things, and I would like to see the result. Like it's a little prize. It's not like a blog. A blog could end in a day of work, a book will - it's taking me ages to finish.
And so I need some prize. I need some rewards along the way. And this reward is, "Okay, now this chapter is looking perfect. This page is looking perfect." I need this, it's the emotional part - it's just like tasting the dishes you are preparing along the way. "Okay, intermediate - this is smelling, this is tasting exactly as it should." And while you're cooking - it's in the oven, you're not even smelling it - you're assuming like you've been doing everything perfect, it's going to be cooked in two hours. No, something is missing. I need to taste. I need this little thing in between.
One of the things that I was doing also, to have this feedback was - okay, double screen. I have a separate screen for book writing, which is vertical. So I see pages vertically, and I can scroll down. This is where I'm typing in Sublime, and this is where I see the preview of this stuff. Okay, that creates a lot better feedback loop when writing for a book. And so I have these two surfaces for writing, three screens. One for the iPad, one for the IDE and one for seeing the preview. This is my setup, on a good writing day.
Len: Thanks very much for describing that. It's always great to hear the details of how people approach different things. And particularly in your case - where images are so important, that you're drawing yourself, it's interesting to hear about the role that the iPad plays.
And so, you decided to publish your book before it was finished?
Len: I believe you published the first version in June of 2018, and you haven't published a new version since then.
Alberto: No, actually--
Len: Is that wrong?
Alberto: I should have published something since - I mean, maybe the last official might be that one. Actually haven't had the count of how much I progressed in the private version. Because I committed to something a couple of weeks ago. And maybe it's time, I should release something more.
To be honest, I worked a lot on another Leanpub book around Christmas time. I finished the chapter for the Eric Evans celebration book of the 15 years of domain-driven design. And of course, like every time, I say, "Oh don't worry, it's going to be something like six pages." It turned out to be 25. And it basically took over my whole Christmas holidays and everything in between.
But it looks like it was a good one. I got good feedback. I added a lot of pictures. I clarified that I need to adapt and include this writing inside my book, because it's actually a chapter about EventStorming a domain-driven design and bounded context - which is fitting perfectly.
Len: On the subject of feedback actually, I noticed that you at one time set up a public Trello board. Did that experiment work out?
Alberto: Not really. It was an act of goodwill. And then the vicious feedback loop I was trapped in - the book was working, the community is growing. The community is still growing. So as a business - I don't know what might happen in an alternative future, when the book is already finished, and I completed it, just getting the revenues. But this is actually selling well. At the same time, people are buying the book and they want to be my customers for facilitation, for services and training and everything else around it.
It's not a strategy, it's not like - "the book is not finished, so you call me to understand how this is going to end." It's not like that. But it's like - there's already enough value to trigger the curiosity, and instead of waiting for the books to be finished, people are contacting me. And I've been traveling all around the world in these last three years, actually doing really interesting stuff, and being in unexpected places. And, oh well - that's exactly what I want it be. This is sucking lot of time from book writing. Not exactly for the writing, the writing's still something that could happen on a plane.
That's exactly what happens when I'm traveling. But the drawing doesn't. I mean my set up with two screens and the iPad is not really fitting a plane. You can type on a plane, but you cannot draw. I mean the plane is shaking. It's very stupid and frustrating to try to draw rectangles on an iPad while you're tray and your surface is shaking. And so this magic is only happening specific days with not so many interruptions, and in protected zones.
nd now we're doing this protection a little bit better, but is still very, very hard to say, "This is a no calls day. This is a no interruption day." Sometimes we have this privilege, apparently we have it and then, a phone call, or - yeah.
Len: It's such a great story, thanks for sharing all that with us. For us, it's always exciting when we see new books come up - and especially bestsellers like yours. But when it's connected to something that someone has created, and then it drives new business to what they're doing, and spreads an idea - it's always very exciting to see.
The last question I always like to ask on these podcasts is - if there was one thing at Leanpub that we could build for you, or one problem we could fix for you - is there anything you can think of in your in your dream world that you would ask us to do?
Alberto: So, can I have two desires?
Len: Oh sure.
Alberto: One is small, one is bigger. So the small one is - there's something in the feedback loop for images that makes it one extra step. If I could see the preview and make it feel like a shorter loop - that would be great. I actually haven't tried, maybe this is something that has been fixed? Like if you set up the local preview, the local path and the remote path might be different for the images. But I would say image handling. That is the thing. It's not bad, I'm getting used to this. But an immediate preview, and see what I'm drawing immediately, that would make me incredibly more productive, I would probably finish my book - liar.
The bigger thing is, I realized if I ever moved to printed paper with my book, I would probably not fit the portrait format. I will probably need a landscape with foldable pages. That's a really big dream, but I am in a domain where the most relevant information is in pictures, and these pictures are pictures of something that might be ten meters long. So if I put it inside a printable page, it's not readable anymore. So centerfold opening, okay now I can see this - yes it's in a size that could be readable, so you can see the forest and the trees at the same time. It's not exactly what Leanpub was born for. I know it's a lot of extra stuff, but you asked me about dreams.
Len: Thanks very much for that. With respect to the first dream, being able to see an immediate preview is something that we've been asked for in the past. It's something that I can see one or two of our writing modes, where that's actually something that might be achievable in the near term. I don't make any promises on the podcast, but this is something that we've thought about in the past, and it and it is something that we're sensitive to people wanting. Because writing in Markdown, and then hitting a button to generate a book - and then the mystery is revealed later, is one way of doing it. But another way of doing it would be seeing immediately, what would this look like? If you're working in our in browser editor, say - you could be working in a panel on the left and writing in a panel on the left, and see the preview on the right immediately with images - that would be fantastic.
With respect to landscape mode, that's very interesting. We've actually been revisiting recently the way we deal with our print-ready PDF output, in response to authors talking to us about it. Because, basically - when you write a book in Leanpub, you can just go somewhere and click a button to export a print-ready PDF, which can then be uploaded to Amazon or Lulu or other print-on-demand services that usually want PDFs. And how we determine book sizes and margins and things like that is something that we're updating.
I think you are the first person to request a landscape mode. I'll make sure to communicate that to my colleagues who are, as we speak, coming up with new specifications for how we ought to deal with that. So maybe, fingers crossed - this might be something that we'll be able to offer.
Well thank you very much Alberto, for taking the time.
Alberto: Thank you, enjoyed it.
Len: I looked up where Faenza is, and in my imagination, it is right in between Venice and Florence.
Alberto: Yes, more or less. But with specific things. Like we have good wines, we have a lot of pork meat, and we have cars and motorbikes.
Len: I was just about to say, "I'm jealous," and now I'm even more jealous.
So, thank you very much for taking the time to do the podcast, and for being a Leanpub author.
Alberto: Thank you for all the support - I mean a lot of the stuff that I do was not possible without you. So a big thank you from my side.
And as always, thanks to all of you for listening to this episode of The Frontmatter Podcast. If you like what you heard, please like and review the podcast in iTunes or wherever you found this podcast. And if you'd like to be a Leanpub author, please visit our website at leanpub.com.