Henning Schwentner, Co-Author of Domain Storytelling: A Collaborative Modeling Method

Len: Hi, I'm Len Epp from Leanpub, and in this Frontmatter podcast episode, I'll be interviewing Henning Schwentner.

Based in Hamburg, Henning is a software developer, consultant and coach at Workplace Solutions or WPS, a business software company in Germany.

You can follow him on Twitter at @hschwentner and check out his profile on the company website at wps.de/henning-schwentner.

Along with his colleague Stefan Hofer, Henning is the co-author of the Leanpub book Domain Storytelling: A Collaborative Modeling Method.

In the book. Henning and Stefan set out the process of how storytelling can be used as part of the Domain-Driven Design method for software development and product planning and design, generally.

In this interview, we're going to talk about Henning's background and career, professional interests, Domain-Driven Design and Domain Storytelling, his book, and at the end, we'll talk a little bit about his experience as a self-published author.

So, thank you, Henning, for taking time out of what I'm sure is a beautiful evening in Hamburg, to be on the Leanpub Frontmatter podcast.

Henning: Thanks for having me.

Len: I always like to start these interviews by asking people for what I call their "origin story," so I was wondering if you could talk a little bit about where you grew up, and how you first became interested in software?

Henning: I grew up here in Hamburg, where I'm now talking in this interview. My first computer back in the 90s was an Amiga 500. That's where I started to get interested in - first, of course gaming - and then later, programming. Then I started with programming languages like C and C++ at that time.

And then the first development experience I had was with Java, when Java came out with version 1.0, I think in 1995 or so? I've used that language and other languages ever since, and later it become my profession.

Len: I've heard lots of stories from people over the years on the podcast about how they got their first computer. Was yours a gift from your parents, or did you start using one of your parents' computers?

Henning: Actually it was a gift from my father, I think for my 12th birthday or something like that. I wanted to have that specific computer, that Amiga. Because a friend of mine from school - he already had a machine like that, and I knew it was a great gaming machine. I knew this is what I wanted to have.

Len: I was going to ask - a lot of people, of course, their first encounter with computers is with games. How did you start programming?

Henning: I would say, with the typical word kind of stuff. I started to have a computer because I wanted to play games. But then I saw all these opportunities that you have with a machine like that, and that you could make the machine do what you wanted it to do. And this typical feeling of power that you have when you write your first programs.

I think in a way, that's probably the typical nerd way to start programming. When you're a teenager and you spend time with a machine or with a computer.

Len: And did you study programming in university, or Computer Science?

Henning: That's right, I studied computer science. Or in German, we say "Informatics."

Len: And did you - most people listening to this are probably more familiar with the North American education system.

Henning: Yeah.

Len: Did you do a four-year degree where you had to specialize in something, and take electives in other courses? Or did you just study Computer Science and Engineering?

Henning: I studied Computer Science in the old German system, where you got a so-called "Diplom." Which is - now in Europe, we changed the systems - or, we made their systems more similar. And so then, I think they can be compared to the English or the American systems. So now we too have these Bachelor's and Master's system. But in the old days, it was like you were doing a Master's, but without a Bachelor's degree first. You couldn't start before that, so I had a five years study in Computer Science.

Len: This is a question that comes up all the time on this podcast, but, so it's 2019 now. If you were starting out with the intention of having a career in software development, would you study at university and take the four or five years to do that, or would you choose another route?

Henning: I would do it again. I would study Computer Science again. I mean, the times have changed. So now we have this different system. A Bachelor's in Computer Science now typically takes three years, or three and a half years. And that's what I'm recommending younger colleagues do today - do that, and then see if you work in the industry - and maybe you go back to university.

Or what we are doing in our company, and I know other companies are doing as well - is that a lot of our colleagues start as working students. So they do one and a half or two years, they study at university. And probably, before that, they got in touch with programming, and then they started in our company, working in real projects. And then seeing, what does all this theory from university mean in practice, when you do it for the real life. And typically for me, that goes well hand in hand.

Len: I don't know so much about the United States, but in Canada in Computer Science departments - I believe it's quite typical for people to have co-op programs, as they're called here, where, in the summer - instead of getting a sort of random job out in the world, you actually get a job in your industry. And that can be really helpful for sharpening people's minds - whether they really want to do what they're doing.

Henning: Yeah, exactly.

Len: And knowing what they really need to learn when they're in those years.

Henning: Yeah, exactly. Especially if you ask me - I think one thing you don't learn at university is that it's so important to not only to work with computers, but to work with other people. Software development is very co-operative work today, because you don't write programs alone. And you don't write programs for yourself, you write it for other people, and you do it with your colleagues. So it's very important to develop some sort of soft skills which you usually don't learn at university.

Len: I was going to say - I've got quite a few questions for you about cooperation, because I know this is an important part of what you do, and your view of business practices generally.

But before we talk about that, I wanted to ask you - I checked out your profile on LinkedIn when I was preparing for this interview, and I saw that you've been working for WPS for 14 years.

Henning: Yeah.

Len: that's a long time to work for one company.

Henning: Yeah, it is.

Len: I was wondering if you could talk a little bit about what WPS does generally, and what you're doing there now, and maybe one or two of the biggest changes you've seen. Because, again, 14 years is a long time.

Henning: Yeah, okay. So what are we doing? WPS or Workplace Solutions, we're a consulting company. We're helping other people or other organizations develop software. Plus, we are developing software as a service for other companies.

The third thing is that we are giving a lot of trainings.

Henning: I'm giving a lot of trainings, especially in DDD and Domain-Driven Design. Because many companies today have these big old software systems, legacy systems, monolit- style. And then they go to the internet, or they go to a conference and they see, "Oh when I have a monolith, what I need is microservices." And then they go on, and when they are lucky - they see, "Okay, the main part is not the technology, it's not that I need a distributed system. What I actually need is a well-cut system, so that I take this big monolith and give structure to this thing."

And the basis for this is typically as found in the domain. We look into the domain, and see what other sub-domains are there - so, what's the organization of the domain? And then take this organization, and use it for the software modules.

That's what we as a company do. We consult in these kinds of systems, enterprise systems typically. This is what I actually do, especially training and consulting. Although my real profession is being a programmer, is being a coder. But of course - as you know, you make more money doing consulting and training, than coding.

Len: And what would you say is one of the biggest changes that you've seen? It could be something as high-level as the introduction of Agile, or something technological.

Henning: Yeah, I think the introduction of Agile, of course that was very important.

But I have to say I was lucky, and when I started at the university, I started my studies in 1999 - so in the last millennium. And then the first semesters, we were just learning how to program. And then when I got on, to see how is it working when you work in a team and not working alone - then, already the professor that we had there, read about Agile, and saw that Agile is a good thing, and that's what we need.

So my education, although it's now 20 years old, already started with a very Agile mindset. I'm still happy about that. Because I still see today a lot of Waterfall style projects, and still many teams haven't done the Agile shift, and have maybe heard about Agile, but never came to it.

So yes, I think Agile's one of the biggest changes. Another change, maybe - that's happening again and again - is that people see that, yes, technology is important. But the more important stuff is what's happening in the domain.

\The software is not an end in itself, but we are programming the software for somebody else, for the user. And if we're doing our job well, then our user has an easier life or a better life afterwards. And if he or she doesn't, then - yeah well - it's nice that we spent a lot of time programming, but it doesn't make a lot of sense. There's an element of design - and that's now coming again, because of the microservices stuff. I think that's another big change. And of course, when we talk about technology - this whole topic cloud is a, game changer again.

Len: Just setting the stage a little bit, for people who might not be so familiar with some of these terms - let's paint the cartoon picture of things. In the olden days, basically, company executives didn't understand or want to understand - I'm putting it very crudely here - anything about software. Software was like bricklaying in their minds. And so what they wanted was - they had a system that people would call Waterfall, where you can just put it crudely to say, you set out exactly all the steps that people needed to do, and then you just set the programmers on their computers, to go type out all those steps. And over time, because of changes in technology - partly - that enabled new practices. But partly because people started to see the limitations of that approach, inherent limitations of that approach, people started doing things a little bit differently. It was actually very difficult, and a fight to get this.

Nowadays, I think a lot of people who come across this - non-technical people who come across the term "Agile," hear it in all kinds of crazy ways that seem a bit kind of iffy. But actually, it was a very pragmatic thing, and it had to be fought for. It's very much transformed the way software is developed in many organizations. And many organizations had existing code bases that needed to be changed.

But it's not just the code bases that needed to be changed, it was the practice of developing the code that needed to be changed - and the understanding that executives had.

And from this, in part, came the concept of Domain-Driven Design, where there needed to be - people started to understand that it wasn't - it was the executives and the programmers, but also the people in the middle. The people who were delivering the service, and the people who were using the service, all needed to be talked to - and all needed to be able to talk to each other, in order to develop software properly.

I watched a video preparing for this interview, where you and your colleague Stefan talked about the example of an application that you developed for the Port of Hamburg.

Henning: Right, yeah.

Len: I was wondering if you could just explain a little bit about - better than I just have, what Domain-Driven Design is, and how you used it to develop this really cool application for a very important part of German industry?

Henning: That project actually was fun. And I'm still happy, because it's an example where you can easily describe what's happening. So it's a pity that we are not - that we only have the audio stream now, because you can easily see what's happening.

So, why is it called Domain-Driven Design?

It's called "design" because we want to design the software. That means we want to design the software architecture on the one hand, but also the user interface, in a way. And it's "domain-driven," because we say - or Domain-Driven Design says - Eric Evans, the father of this says, "We want to look at the domain and see what's happening there, and see which actors are there, and what are the objects they are acting with. And all this stuff, we take into the software. And not only into the software interface, user interface - but also into the software architecture."

So that means, in this Port example, that we built software for manoeuvre planning. We planned how ships can come in and out, or sail in and out through, the Port of Hamburg. And before they actually do that in real life, we simulate it in the new software. So and what our - a concept from real life, of course - the ship, is there and then we have to manoeuvre. And we are using special maps, so called "depth maps," where we can see how deep the sea and the river are.

And all these things that we're using to make for our work - or that the nautical officers that do in their work - all this is put into the software. But we say, "We have this depth map as an important work object, and let's have a class - in the software, in the code, for a depth map. What are we doing with a depth map?" That's how to map it further.

And so, there's the idea of Domain-Driven Design. We take the stuff from the domain - from real life, and put it into the software. That means we don't get lost when we look into the software, when we look into our model or domain model.

Len: That's such a great example. As you say, I'll definitely link to the video on YouTube where you and Stefan do the talk and show everything. Because it is really fascinating.

And just to paint the picture a little bit. So the Port of Hamburg is a sort of inland port - it's connected to the ocean by a river.

Henning: Yeah.

Len: And you need to navigate ocean-going ships down the river into this city port. And so what the port workers have to help do these ships navigate, is basically the ship's captain will make a call saying, "Give me a path," and then you have to give him a path. And one of the really important things is that you need to make sure he or she doesn't scrape the bottom of the river bed when they're navigating into the port.

And so they have these maps that have little numbers all over the place, showing the depth of the water in particular places. And what the navigation people would do is actually have a cut out, a paper cut out with the silhouette of the hull of the ship. And then they would actually move that - they would put it on the map, they would literally put that piece of paper on the paper map, and they would move it along, and they would chart out a path that way. And then they would actually write down the path on paper, and send that to somebody to give it to the - to somehow communicate that to the ship's captain.

Henning: Yes.

Len: And so you guys were brought on board to try and come up with a software application that could actually help improve this process by digitizing it, basically.

Henning: Yeah, exactly. It was still five years ago, it was a classical paper process. So they had - as you said, they had these paper depth maps, and these paper so-called "ship silhouettes." Those are these things that have the same form as the hull of the ship. And what we also want with DDD, is that we want to keep the language - we want to take the domain language and put it into the software. That's called "ubiquitous language" in DDD, because we want to use the same words everywhere. That's why it's called "ubiquitous." So we want to use the word "ship silhouette," not only in real life, but also in the code.

I thought about it earlier when you said, "The captain of the ship wants to have a path." That's a good example, because the right nautical word would be, "He wants to have a route." And DDT is very picky about that. Because we want to ask developers to understand the real language from the domain. Not use our words, but use the words from the domain. And that's very hard to do. That's one thing why we are writing this book about domain storytelling, because that's a way to find out the domain.

Len: This is a very interesting issue that gets to the heart, from what I understand of Domain-Driven Design, of the sort of revolution that it represents. I'm not a technical person myself, I'm sort of resident non-technical person at Leanpub. But of course, I interview programmers and work with programming book authors all the time. And one thing I've come to understand is that naming is famously a very hard thing to do in programming.

You have to give names to the logical objects that you construct in your code. And one of the things that Domain-Driven Design is built to do, is actually have a naming process that can allow things to be communicated across that divide I was explaining between-- because when you talk about designing something for the user, the user in this case - you have an example from your book, I believe, of designing a system for booking movie, cinema tickets.

Henning: Yeah.

Len: So the user there isn't just, as a normal application developer might think, "Oh, the user is the person trying to use the app to get the ticket booking." The user is also the employee of the company who's trying to help that happen.

And so if you can have a language where the people who are using it can actually communicate with the programmers, and the programmers can communicate back in the same terms, the theory is that that will really help you design better, and maintain products in a far superior fashion than you could in the past.

Henning: Yeah, exactly - that's right. That's what we want to do. We want to understand the language of our users, of our domain experts, and bring that into the software. And yeah you're right, there's a famously hard thing with naming. There's this famous quotation of - I have to look that up, I have a slide actually with his name on it, and the quote is, "There's two hard things in Computer Science, cache invalidation and naming things." DDD doesn't help with cache invalidation, but with naming things. The idea is just use the names that are already there in the domain.

And what we are doing with this language is building a model. So when we code, we build a model of the real world. That's why it's called a domain model. Because it's a model of the domain, of parts of the domain, parts of the real world that we transform into the software.

Henning: The thing is, we don't take everything from the real world - we only take the things that are interesting in the context we are working.

Len: So in the example of the Port of Hamburg, the domain might be the enterprise of running this port, getting the ships in and out safely.

Henning: Yeah.

Len: And within it, there are things called "bounded context."

Henning: Yeah.

Len: If I have that understanding correctly. And so what you do - and we'll get to the details of how the Domain Storytelling is done in a second - but essentially what you do is, you have a model for this domain, and then you try to isolate the various contexts within it. So there's these domains within the domains as well. So the people who run the ships that do the sounding every day, to make sure they know how deep the port is in various places, are one domain. The people who are communicating with the ship's captains to give them their routes are another domain. And maybe even the communication back and forth can even be conceived of as a different domain?

Henning: Yeah, that's right. We would call it - to be exactly, we would call these kinds of domains sub-domains. To show, okay - these are parts of the big domain manoeuvre simulation or are running a port. And what we want to do with these sub-domains is, we want to find different modules in our software.

When you build software systems today, we typically build big software systems. And big means it's hard to understand and hard to change. Because you have to understand everything.

And that's why DDD says, and that's really a great thing - "Hey, let's not build just one model, just one domain model - but let's build several domain models. Smaller models that are easier to understand, easier to maintain, that are less error-prone. Because they can easily be understand. And let's separate these models with clear boundaries. And that's what these bounded contexts are about.

One bounded context is one software model that - or one module, one software module, that contains one domain model. And the domain-driven part about that is to say, "Hey, let us look into the domain, see which sub-domains we can find, and then let's make one module - one so-called "bounded context" for every sub-domain, so we don't have one big piece of software where everything is connected to everything, but we have several pieces of software that are connected to each other by very small and very clearly defined interface.

Len: And crucially, if I understand it correctly - the idea is that the way these modules work and the interactions between them, are modeled on the way the actual activity is being undertaken by people in doing their jobs, and using the services in real life. Henning: That's right, yeah. That's why we want to know, in a very detailed way, what the domain experts, what our users are actually doing in their life.

Len: And that brings us to Domain Storytelling, I think. So, I'm wondering - just moving on, and that's the subject of your book, Domain Storytelling: A Collaborative Modeling Method. Just moving onto the next part of the interview, could you talk a little bit about what Domain Storytelling is, and a little bit about the history of the idea.

Henning: Maybe I'll start with the sub-title - it's called a "collaborative modeling method." Why's that? That's because in the last couple of years, different people saw that it's a good idea to not model these - to not build these domain models alone, but to build them collaboratively. And collaboration here means we want to have the domain experts on the one hand, and the developers on the other hand.

So we want to have direct communication between the people that are using the software, and the people that are building the software. And we want people that are building the software - the programmers, the developers - to understand what's actually happening in the domain, and build this domain model. That's why it's called "collaborative modeling."

There are a couple of methods like Domain Storytelling for collaborative modeling, and these are - these came up in different parts of the world independently. Domain Storytelling came up in the University of Hamburg in the late 90s and the early 2000s and had - it was developed at a German university at a very scientific, very German name. It used to be EGPM.

That's short for exemplarische Geschäftsprozessmodellierung. That's no joke. This is actually not one word, but those are two words. But yeah, if you don't understand the language, that might sound very strange to you. That would mean in English, "business process modeling by example," or something like that. EGPM, exemplarische Geschäftsprozessmodellierung, yeah.

And with this name, it couldn't gain much success out of the university. But I got in touch with it, other colleagues got in touch with it when we were studying at the University of Hamburg. And also Stefan, when he did his PhD, he got in touch with this method. He studied in Austria at another university, but he came to Hamburg for his PhD thesis.

And a couple of years later when we finished our studies and used the method for different projects, Stefan said, "Hey, these ideas are good, but nobody except us knows them. Let's give them a more easier name or a better international, understandable name and a less academic name. And let's make this method more international." That's why he came up with this name "Domain Storytelling."

And then we showed it on several conferences to the DDD community, the Domain-Driven Design community. And it fit well. And so now today, there are other people from other countries as well. And on one conference where we presented it, where we did this video afterwards, we said, "Okay, this was a great conference, really a lot of fun. We need a book about it. Because people - its not enough just to hear it in talks, they need to read about it."

And that's why, when we decided to start this book, Domain Storytelling: A Collaborative Modeling Method, then we saw what's the right thing to publish it, and as we were both Agile developers by heart - then we thought, "There's publish early, publish often." So that's why came out with Leanpub.

Len: I've got some questions definitely to ask you about that in the next part of the interview. And I'd like to ask you a little bit more about Domain Storytelling.

But before that, I cannot resist the temptation to do a bit of a digression on German compound words. I know a little bit of German, but I come through it largely through encounters with philosophy. And when you understand the way the way compound words work in German, it's just fantastic. So terms like Naturwissenschaften and Geisteswissenschaften - and from Heidegger, like to Zuhandenheit and Vorhandenheit, and things like that -I think one of them is Backpfeifengeschicht? [Apparenly here Len accidentally coined a new term meaning "Punchable history" - eds.]

Henning: Sorry, what?

Len: Like, punchable face.

Henning: Oh yeah, yeah.

Len: Gesicht, sorry - Backpfeifengesicht, yeah.

Henning: Yeah, right.

Len: But punchable face. Or Sitzpinkler.

Henning: That one's a nice, yeah.

Len: Which is someone who sits down to pee. Sorry, but it's actually like - it's brilliant and funny and actually a very powerful linguistic thing, that we more or less lack in the English language. If you want to look it up, look it up. German has many wonderful words from the mundane to the profane that are just fun to learn.

Henning: Yeah, fantastic, yes.

Len: And so with that temptation -

Henning: It's good that you followed this temptation. Because you mentioned Heidegger, and that's - when we talk about the history of Domain Storytelling, then we also have to talk about Heidegger. Because exemplarische Geschäftsprozessmodellierung, the scientific form of Domain Storytelling - it was developed in a bigger frame.

There are a couple of computer scientists working on something that's similar to DDD, but also has a very German name. It's called Werkzeug- und Materialansatz. That means "tools and materials approach." So there's also an English book about that. And this Werkzeug is also a compound word.

Len: Stuff, right?.

Henning: And Zeug, stuff - Zeug is also a very important word for Heidegger in Sein und Zeit. I don't know the English title, but it's probably being and time.

Len: Being and Time, yeah.

Henning: Yeah. He goes deep into the stuff, into the Zeug. And Heinz Züllighoven, the guy who invented the tools and materials approach. He also had a big - Heidegger had a big impact on him and these ideas for that, so -

Len: That's fascinating, I did not know that. One thing I should mention is that one of the reasons I know some of these terms is from reading Being and Time, which, even in translation into English, people have to use a lot of Heidegger's words in German.

Henning: Yeah, I do believe that.

Len: So you don't always translate "ready-to-handness" or "present-to-handness." You might just use Zuhandenheit, Vorhandenheit. Even if you don't speak German, you come to know the German terms. Because it's just handier to know them, than to use some weird English approximation.

That's actually why I brought up German compound words, is because they capture ideas in a way using language, a precise way of using language that actually no other use of language can really do.

Henning: Yeah. That's exactly what this ubiquitous language is about, that we earlier talked about. This idea of having the exact words from the domain. Maybe these words are used in a wrong way or in a misunderstood way. But we don't care about that, because we want to use the words in exactly the same meaning our domain experts are using them. And all these fine differences that get lost when you translate, we don't want to lose them. That's why we don't translate the words when we go into the software.

Len: I didn't know we'd be getting into hermeneutics, but I'm happy to do it.

And so, one of the origins I believe of Domain Storytelling, was with cooperation pictures.

Henning: Yeah.

Len: But it didn't begin the way - it turned into something else, in the beginning there were these cooperation pictures that were then translated into text.

Henning: Yeah.

Len: And so, I was wondering if you could talk a little bit about those cooperation pictures and what they were?

Henning: These cooperation pictures that were in the late 90s, that we talked earlier about, when scientists from the University of Hamburg in Computer Science, said, "Okay, let's try out our ideas in the real world." And then they came into - I think it was a hospital where they first tried it out. And the idea of these cooperation pictures was, "Okay, we want to make visual the interaction between different actors in the hospital or later in other domains."

So they put it into a picture. And what they also did was, they made interviews and wrote down what they heard in these interviews. So they asked the people, "What are you actually doing?" And then they wrote it down, to gain this understanding, this knowledge of the domain. And then they got this idea of, "Okay, these cooperation pictures, that's a good idea. Because it's easier to see these pictures than to read all this text."

And then the next dimension was that they saw - this was done by the other person, by other persons. They said, "Okay, what we need in this picture is actually, time. Because we don't just want to show the cooperation, we also want to show what's happening afterward." And that's when they got these sequence numbers into the cooperation pictures.

Cooperation pictures, today we now call them a domain story and picture, which shows the cooperation, also the time, also what's happening - who does what with what, who is the actor, what is the activity, as we call it? What is the work object? So the actor does something with a work object.

Len: So to spell this out - the way domain stories are created initially is in workshops.

Henning: Yeah.

Len: And the inspiration came from these cooperation pictures. But what happens is, you gather a bunch of people together, like the person who has to make the route through the port, and the person who has to make the map, and other people in the area. And then what you do is, you develop - generally, if I understand the process correctly - there are three sort of categories, you might call them.

One is the actors, or the subjects. This would be the people doing things. But I imagine it could probably be automated processes as well.

Henning: Yeah, exactly.

Len: And then there's work objects, which could be a piece of paper, literally. Or it could be a Word document, or something like that.

And then you have activities. So the subjects are represented with a certain icon, like a little silhouette of a person or something like that. And then the work object might be a little rectangle or something like that. And then you have an activity, which is denoted by an arrow.

Henning: Yes.

Len: And a little textual description of what the activity is. And then really crucially - I think you mentioned this, but you had little numbers and circles. And these introduce a temporal development to it, or at least a sort of causal sequence.

Henning: Yeah, yeah.

Len: So subject undertakes activity to create work object. And then work object is - there's an activity of transferring that to someone else. And so you're really, it looks like - it takes the form initially either on a smartboard or a whiteboard of icons and arrows and words. What is happening there is that actual real processes in the world are being modeled based on communication that all the people involved in the process undertake with each other in these workshops.

Henning: Yeah, exactly. And the idea is - that's the collaborative modeling part of it, that we use these domain stories as a tool for active listening. So we let our domain experts, our users tell their story. We ask them, "What are you actually doing?" And then they tell us. And we paint this picture, this cooperation picture or this domain story - and show them, "This is what I have understood." And then the domain expert who is telling his or her story can then say, "Yes, you understood that right," or, "No, you understood this wrong. This has to be done in a different way or in a different time."

So we can easily deal with misunderstandings. That's a basic idea, that we want to have a clear and sharp understanding of what's happening in the domain. And that means we have to communicate in a way that these misunderstandings can be thrown out of the way, or moved out of the way.

Len: I've got almost a selfish question, I should say, but one thing I've encountered, just reading about technology in the past is - the management of aircraft carriers. And in control rooms or whatever they're called for aircraft carriers - I mean, an aircraft carrier, it's a logistical challenge managing one.

Henning: Yeah.

Len: You've got all these planes, maybe with folded up wings, and you have to manage how they're going to be raised to the top of the platform. And then when they're going to fly off, and when they're going to come back - you have to know where everything is, like literally any -

Henning: Where other people and all the stuff are, yeah.

Len: Where are the people? Getting goods from another ship, loading them onto an aircraft carrier that might actually just like be out to sea for six months straight without docking, things like that.

Henning: Yeah.

Len: And from what I understand, historically this was done in a similar manner to what you described in the video, which I'll link to - having this sort of paper silhouette on a little map and what they would do. And even really sophisticated aircraft carriers, ones that might even have their own dedicated satellite and like a nuclear power plant running it - they would actually have little like toys on a flat surface that they would move around.

And so someone in the story, as I understand it - the one I read - someone decided, "No, no, no - that's ridiculous. We've got this big fancy technological marvel, why are we still using little toys on a flat physical surface?" And someone tried to develop something, and they went back, in this particular example. The aircraft carrier went back to using the old analog process.

Len: So I guess the question I have for you is, in your company - have you ever encountered a situation where someone approached you saying, "We've got this old analog process, we want a complete software solution." And have you ever come back to them and said, "Hey, no - part of it actually needs to stay the way it is?"

Henning: That's a good question. And actually - yes, I think to be honest, most processes, there are parts that will stay out of the machine. So when we look into the cinema example, like you mentioned earlier - there of course, the person is saying, "We don't want to have a machine doing that. We want to actually have the cinema-goer or the customer watch this movie."

And of course, we want the real ship to come into the harbor when we talk about this, this port example. Or when you buy a car, of course you want to get the real keys to the real car. And we would model all the stuff in the process, but we wouldn't put it into the software.

And that's also an important thing about Domain Storytelling or other business process modeling tools - that we model the whole process, and then we see this part here - that role is done in software, or that will be done in software. And these other parts, they will stay out of it, and it's good that they're not. So that we see, where is the technological marvel going to happen, and where not.

Plus, also it's a very good example that you said with the aircraft carrier. Because I think it's pretty similar to this manoeuvre simulation in the harbor. Because we replaced the paper solution with a big touch screen solution, a so called "touch table," it is now. But still, it feels like in the old days - we now have the toys that you mentioned in the computer.

But it still makes sense to have these toys, because it's very easy to understand and it's a model that can be used with a low cognitive load when our users - in this case, our nautical officers are doing their manoeuvre planning. So they don't have to spend their brain power on thinking, "Oh, how do I have to use this great and powerful machine?" And this should not get into the way. That's why we want to have an easy to use user interface.

Len: That's a really interesting example. I was interviewing some people who work for the Financial Times recently, they've worked on the digital transformation there. And one of the things they talked about was how - journalists often are working to deadline, and they've got to get things right. And so, you've got to be very thoughtful in the way and the timing with which you present them with new features. Because even though the new feature might be very powerful, if they go into it and they need to get something done and anything's changed - even if it's an improvement, they have to learn it.

And so then, not only do they have the cognitive load when that happens - but they have the cognitive load whenever they go to interact with their tools, that, "Oh no, maybe something has changed, so I've got to be prepared to kind of like suddenly be a superhero every time I want to like type some words out and post them to a website." And so, being judicious in your thoughts about the tools that you present people with, and keeping in mind the real world thing that they need to accomplish, is really important.

And it doesn't necessarily mean more complexity. The simplest solution might often be the best. Which sounds straightforward when you say it, but the history of software development is full of people not learning that lesson.

Henning: Exactly, exactly. Yeah, and everybody else knows many examples where they have used software that has an awkward interface, and a strange mental model, and makes it hard for the user to understand what's happening actually, yeah.

Len: This has come up a couple of times in this podcast. I mentioned that I'm not a technical person. But when I started learning - when I started working with Leanpub, I had to get to know how to work with programmers and things like that. And one thing I often found frustrating was with some of our employees, they might have the expectation that if I can't explain the use case for something in terms they appreciate, they resist the logic behind it. Like, "Well, I would never do it that way." And it's like, "I don't give a shit."

And that's not just me being mean to you, it's me being mean to myself. It's not about me, and it's not about you. It's about this objective situation that we've determined here, where we need to deliver a system. I guess what I'm saying is that like, a lot of people think of programming as being this kind of faceless thing. But there are faces behind all of the software that you use, and people have personalities. And having these high-level theories, like Domain-Driven Design, is very important, because.

This is one thing I wanted to get to, was the concept of cooperation, and how important it is in your work. I believe you or your colleague Stefan mentioned in - either in the book, or in your talks - that a business can be conceived as a bunch of cooperative practices. That's what a business is.

Henning: Yeah.

Len: And we need to keep in mind that we remain ourselves when we do our work, but there are actually these higher-level processes going on as well. And having collaborative systems, like say, with using the same names to refer to the same things - even though you're pulling the lever or writing the code for what happens, when you pull the lever is very important.

Henning: Yeah, exactly. Yeah. I think that at least two dimensions to cooperation are there. One thing is - as you said, software is not something that's faceless or that is filled by some person I don't know. And software is nothing that exists independently of these people. So that's what - naively one would think software, that's shiny steel or chrome standing there, that may be beautiful, and it doesn't have to do anything with humans.

But the opposite is true. The software is totally dependent from who has built it, and from the taste and the skills and other things of the people that build it. Today we call this sociotechnical systems, to say a software system is nothing that can exist without the human or the society or the team that builds it. So you say it's not a technical system - and really it's a sociotechnical system, because it interacts with the people that build it. That's one dimension.

And of course, the second dimension - it also interacts with the people that use it. And this stuff also has implications on the software. So we don't want to build the software somewhere out in space, we want to build the software very tightly close - very, very close to our users, to our domain experts. Because we want them to understand what's happening, and we want to support them and their work.

Len: Moving on to the final part of the interview, where we talk about your book and the process by which you're writing it. You mentioned this a little bit, but I was wondering if you could talk a little bit about how you found out about Leanpub, and why you chose us as your platform for self-publishing your book? Which I know you've been working on and planning for quite some time.

Henning: Yeah. I think we started to work on the book when we came back from this conference, that was the DDD Europe and Amsterdam last year. That must be in February 2018 or so. That's when we wanted to start a book. And then we said, "Okay, let's build a small kernel of things, and then see where we can publish that." And we knew Leanpub from other books from the community.

There are now a couple of books finished and unfinished on Leanpub. And we knew that it's a good thing to have the possibility to publish a book that's not finished, because it already helps other people doing their stuff. Plus, it helps you as an author, because you get the feedback and all the stuff earlier, and can then put it into the version.

And it was already started. We published the book, I don't know? A week or so ago, and there's already feedback from people telling us, "This is not working," Or, "This is a good idea." But this kind of feedback, you want to have.

Len: I'd like to talk to you about feedback in just a second. But before we do that, one thing - so as listeners to this podcast probably know, Leanpub enables in-progress publishing, so you can publish a book when it's incomplete, as Henning was saying very succinctly. That's helpful to readers who need the information now, who might not want to wait for the typical full book publishing process to be complete. A chapter on something that can help them accomplish their task now is great, even if the full book isn't finished.

But it can also be good for authors - because they get to get feedback early, and they also get motivation and positive - or even negative reinforcement when they publish. But one thing that involves then is deciding when to publish for the first time. And so I see that your book is marked as about 45% complete.

Henning: Yeah.

Len: And I wanted to ask, how did you and Stefan decide when the book was ready to hit the publish button for the first time?

Henning: We have two parts in the book, the first part is more introductory, and the second part is for what different settings you can use the method. So we talked about DDD and demand started telling us, it fits nice with DDD. And for both DDD and the last, that's strategic design. But also for really in the small, that's technical design - so for finding context boundaries on the one hand, and for finding a domain model on the other hand. But this is only one use for it.

You also can use the method for finding shadow IT, for finding the requirements and other stuff. And we have written some words in the second part for the different uses you can have.

We also think there are other uses that we haven't thought about yet. And our goal was to say, "Hey, let's bring this first part, this introduction part into a state where we can - or we believe it helps other people to use the method."

So that's why we said, "Okay, now - this is not great what we have there. But it's okayenough that somebody can read it and understand what the idea is." And that's why we said, "Okay, let's hit the publish button. Let's say this is about 45% complete, and now let's go iteratively over it and now make it better and publish." Then, when we have the time to write a new chapter, for example - we'll publish again.

Len: And for people listening who are curious about the process, have you planned monthly releases, or "It will be 100% done by this time"? Or are you just kind of going with the flow?

Henning: That's a good question. I think actually we would love to give ourselves deadlines, or a deadline. Because we all know when you have a deadline to get to, then you are more productive, because it focuses you on the work. But, and since we are writing the book more or less in our spare time - to be honest, it doesn't work that way. So it's always this - okay, somebody takes two or three hours on the weekend and writes a small part, a few sentences. Or is coming back from a job in another city, and they're sitting in the train or in the airplane - and then writing there.

Since we're not full-time authors, we don't have the time to say, "Okay, now let's take four weeks off and just finish this book." This is not how it's working for us. I think that's probably another reason why Lean Publishing is working well for us. Because - yeah, I hope that we finish the book within the next month or year - or months, or a year. But, when big clients come with big and interesting projects, then the book will have to stall a bit, I think.

Len: Thank you for sharing that story, that's so great.

Henning: To be honest.

Len: I think for a lot of people, it seems very daunting. And that's one of the reasons we like to have this third part of the interview be about the actual process of writing - so that people who are interested in hearing about that, can hear other people's stories, and know that they're not alone.

Henning: Yeah.

Len: Or even learn like that there are these models that you can use for doing it that don't necessarily require really strict timetables, and things like that. And that it's a bit of an organic process getting any book done, really.

Henning: Yeah, I think now we have about 70 pages or so, and it took us - I don't know? 18 months or so. That's a long time for not much paper in the end.

Len: You mentioned feedback is important, and that's an important thing to a lot of Leanpub authors. I noticed that at the beginning of your book, you have a specific section where you ask people for suggestions to improve the book. You share your Twitter handles, and a specific email address, and you've also got a Slack channel. How has that been working out? Have you been getting a lot of feedback?

Henning: Yes, we did get feedback, mostly on Twitter right now. Also a bit by email, but that was more from colleagues that we wrote, "Hey, our book is finally out, download it here." And then many colleagues and clients, they said, "Hey, that's great. I'm going to download it and I'll come back to you when I've read it, and give you some feedback." Since it's been out now for a week, there are a couple of readers who really came up with good ideas and changes, and so on. But I think most of the readers need a bit more time to really read it, because they are in the same situation. They of course don't have the time to take a week off to read deeply into a topic like this.

Len: The last question I always like to ask in these interviews is, if there was one thing we could build for you on Leanpub, or one thing we could fix for you that's been bothering you - can you think of anything you would ask us to do?

Henning: Yeah, thank you Len - that's a nice question. But I think at the moment with the platform, I'm totally fine. What I actually need is some magical guy that is finishing my book.

Len: Well, thanks very much for sharing that. Unfortunately we -

Henning: Maybe not a guy, maybe something like a time machine, or a machine that stops the time. Gives us the time to write it down. That's what we would need.

Len: I think we would all love that. Unfortunately that's beyond the resources that we have as a software company, but we'll keep it in mind.

So, thank you very much Henning, for taking the time to do this interview, and for writing the book and for being a Leanpub author.

Henning: Len, thanks a lot. It's an honor for me that you are interviewing me.

Len: Thank you very much.

And as always, thanks to all of you for listening to this episode of the Frontmatter Podcast. If you like what you heard, please rate and review it wherever you found it. And if you'd like to try being a Leanpub author yourself, please go to our website at leanpub.com. Thanks.