Simon Brown, Author of Software Architecture for Developers: Technical leadership and the balance with agility

Len: Hi I’m Len Epp from Leanpub, and in this episode of the Leanpub Frontmatter podcast I’ll be interviewing Simon Brown.

Based in Jersey, Simon is an independent software development consultant, popular speaker, creator of the C4 model for visualizing software architecture, and the founder of Structurizr, a set of tools that help software teams visualize, document and explore their software architecture.

You can follow him on Twitter @simonbrown and check out his website at simonbrown.je.

Simon is the author of the Leanpub books Software Architecture for Developers: Technical leadership and the balance with agility, The C4 model for visualising software architecture, and The software guidebook: A guide to documenting your software architecture

In this interview, we’re going to talk about Simon’s background and career, professional interests, his books, and at the end we’ll talk about his experience writing and self-publishing.

So, thank you Simon for being on the Leanpub Frontmatter Podcast.

Simon: You are very welcome. Nice to meet you finally.

Len: Yeah, you too. It’s been a long time that you’ve been around Leanpub, and we haven’t spoken.

It’s funny, I was saying before we started - before I hit record - typically we begin by asking people about their origin story. But you just had an interview that you did yesterday, where you talked about multiple origin stories, including your own.

So of course, we’ll link to that in the transcript for this interview, because it’s a really fun interview. But I guess I’ll start by being a little bit more specific, in your case. Where did you grow up, and what was your first experience with a computer and programming?

Simon: I actually grew up in Jersey, on the island of Jersey. My first memories of computing, I think - my dad said he imported one of the first personal computers into Jersey in the. I’m going to get the dates wrong, but I’m going to say late 70s, early 80s.

The first computer I remember actually playing with kind of properly was the BBC B Micros, which were very popular in the UK in the schools, when I was a school kid. I think I probably played with a computer before that, but I’m going to say the BBC microcomputers.

Len: Would this have been the thing where you were typing in programs from magazines, or things like that?

Simon: Oh yeah. It was like, “Line 10, print something. Line 20, go to 10.” Then once you get bored of that, you can change the colors. Then once you get bored of that - we had a bunch of magazines, I think they were called “Input” magazines. It was one of these weekly periodicals, where you’d buy a magazine on week one, and you’d get like 50 lines of code to type in. Then that didn’t do anything, so you had to wait till week two to get the next 50 lines.

Of course, what would happen is, there’d be a typo somewhere in the 100 lines. But they’d only realize three weeks later. Because all of these things are printed, of course. So then five weeks later or something, there’ a, “Oh by the way, line 54 of this first program four weeks ago, is wrong.” It was just the funniest thing ever, of course. Then you lose the cassettes and the disks that these things were stored on. And, yeah, it was just horrendous. Some of the programs were spread over months, and they just took so much time to type in. But that was fun.

Len: That’s fascinating. I’ve actually, I’ve never, in all the stories I’ve heard of people using magazines and stuff that to do programming, I’ve actually never heard of serial publishing of programs.

That’s really interesting. But you’re -

Simon: It keeps you coming back, doesn’t it?

Len: Yeah, definitely, definitely.

Simon: You have to complete the program, even if there’s a typo in it.

Len: It’s interesting that you mention that too. There’s this old nightmare story from gaming, of, I think it was the first King’s Quest game, where one of the solutions to a puzzle was, I think, was typing “Rumpelstiltskin” backwards. But, I think it was the original version of the game, they had a typo. So even if you were clever enough to figure out it was Rumpelstiltskin, and you had to do it backwards, you still couldn’t complete the quest, because of -

Simon: You never win.

Len: There was a mistake in the game.

Simon: Wow.

Len: Then it was only through back channels or gossip or magazines, that you could actually find out. It’s just a really interesting way to get into programming, compared to now, obviously.

Simon: Yeah, totally.

Len: Which is something I’m going to ask you a question about in a moment. So you studied Computer Science.

Simon: I did, yes.

Len: At Reading, I think?

Simon: Right, yeah,Reading University in the UK.

Len: I think you and I are of the same vintage, but what was studying Computer Science in the early 90s? I mean, this would’ve been just when the popularization of the web was happening, and things that.

Simon: Yeah. So when I started my university course, I started it in 1993. I actually started doing a joint Computer Science and Cybernetics course. It turns out that Reading University’s actually one of the more well-known, well-regarded places for Cybernetics. There’s a professor there, what’s his name? Kevin Warwick. He’s one of these people, certainly when I was at university, he was getting, he was planning to get stuff implanted in his arm, so he could walk around the building, and tap himself in. This was back in the early 90s.

So yeah, I started on a Cybernetics-Computer Science course. The Cybernetics stuff was interesting. It was all robotics and artificial intelligence, and stuff that.

But there was a bit too much hardware for my liking. So after the first few weeks, I ditched the Cybernetics thing, and chose much more of a pure Computer Science.

When I started doing the Computer Science course, we did lots of stuff Modula-2 and C and POP-11 and Prolog and occam, and lots of, I guess academic-style languages. You’re right, the web was in its early infancy.

In my third year project, which would’ve been 95, 96, I actually remember pitching to one of the professors about my final year project. “I want to build something that would allow me to do HTML in a ‘what you see is what you get’ style editor.” I was basically discouraged from doing that, because it was too hard and too new, etc. So my final year project ends up being a traditional C++ Windows GUI application. So yeah, none of the web stuff really got into my course. I was a couple of years early, I guess?

Len: That’s really interesting. So would you have been able to then use the web to learn programming, things that you weren’t learning class? Were there lots of resources available at the time?

Simon: Not really. Because all of those languages that I’ve already mentioned, all of the material for those languages was in printed paper books. Conveniently, in most cases, written by the authors who were lecturing the course. So, yeah, not entirely sure what happened there. But, yeah, there wasn’t much in terms of web-based stuff, to support and supplement our course material.

Len: It was in a different subject from Computer Science, but I once had a professor tell me when I was in grad school, “If you want to make the real money, write the intro to X textbook. That’s where the cash is.”

So, of course, nowadays, skipping ahead a couple of decades, things are very different, when it comes to learning about Computer Science and programming, in particular, online.

One question that comes up often on the podcast, in form or another, is, if you were starting out now with the intention of having a career like the one that you’ve had, would you do a full four-year university degree in Computer Science? Or would you try another approach?

Simon: Ooh that’s a really tough question, isn’t it? I mean, from one perspective, having something, a Computer Science degree, in theory, should give you a very good grounding in lots of the more academic stuff. Some of the more structured and formal foundations that are really applicable to industry.

In real terms, however, many universities are still stuck, in some cases, doing the stuff I did 20 years ago, albeit with different languages. This is one of the complaints I see quite often - students coming out of university, and they’re being thrown into their first job, and their first projects and product. Nothing they learned at university is useful right now today.

I mean, this actually happened with my degree as well. My first job out of university was working for a small consulting company. We were using powerbuilder, which was a mid-1990’s 4GL type environment. Most of the powerbuilder apps were frontends to a Sybase relational database. I did literally no database theory at all on my three year course. That’s a really good example of some skills that were being used in industry back in the mid to late 90s, that weren’t covered on the course. The same thing is happening today.

That said, of course, there are some university courses out there, where you’ve got some lecturers who are doing, half the time lecturing, and half the time actually doing stuff in industry. So I think if you can get yourself on one of those courses, it’s potentially a much, much better starting point.

But, yeah, is it useful today? I don’t know. I honestly can’t answer that question. My gut feel says it’s useful. But in reality, maybe it’s a different story.

Len: Thanks very much for that answer. It’s one I hit people with, and often people are like, “Wow, what a hard question,” is an answer. But some people are very straightforward. They’re like, “No. No way I would ever do it again.” Other people are like, “Absolutely.” It just speaks to how difficult it is. Particularly devoting four years of your life. If you’re in a place, where, when you’re young, and if you’re in a place where tuition’s very high, for example, then that compounds the commitment that you’re making.

Len: My position on it is, the difficult thing is that, if you’re very calculating, and you want to do return on investment things, the argument gets very difficult to make for it. But four years to spend in study in your youth, if you can afford it, just brings with it all these really profound benefits that you - my clever phrase is “must be possessed, in order to be perceived.” You have to go through a long period of real hard work and study to see how that is, in itself, valuable. But, of course, you need to have the ability to do that, in terms of money and time.

But that just makes it inherently difficult to convince someone who doesn’t possess it yet, that, “You will have this magical power at the end.” Especially when not everybody does get that in the end.

Simon: Right.

Len: Sometimes it’s just a very disappointing thing. So it’s a very hard question. But it is something that I think it’s important to think and talk about, in particular, in a world where, when you talk to people who do software development recruitment, they’ll all say, almost all of them will say, “A Computer Science degree is not a requirement anymore, it was in the past.”

Simon: Yeah. I mean, I’ve worked with developers who have had degrees, and have been useless. I’ve worked with developers who have not had degrees, and they’ve been awesome. So just the, “Does this person have a degree?” tick box, is not a sufficiently deep way to judge someone’s skill.

It’s interesting that you asked me this question today, because I’ve literally just come back from the UK on Sunday. I was dropping my 18-year-old off at university. So he’s starting at university. It’s not Computer Science, it’s commercial photography. A bunch of people have asked us the same thing, “What’s he expecting to get out of this course? Why can’t he just go be an apprentice and go learn commercial photography?”

For me, there’s lot of intangible stuff there about meeting people, and then, you’ve got the whole thing around university life, etc. Going to bars, etc.

A lot of it’s also about contact, isn’t it? It’s the friendships you make, and the contacts you make. So, maybe that’s more applicable for what he’s doing in commercial photography? Because they seem to have some links there.

But, again, if the course has some strong links to industry, that can help you in the future, maybe fast-track you? So, yeah, interesting. Lots of things to consider, really.

Len: I couldn’t agree more about that. It’s not even just the networking within your org, connections that you make within your area. It’s the mystique around a doctor or a lawyer is demystified when you were 18 years old at university, with friends who became doctors and lawyers later, that actually can be a very important thing to learn, and set of friends to have throughout your life to call upon - when there’s a mole on your back, or you get a jury summons or - but it’s actually interesting you bring that up.

So, well, congratulations to your son for starting something new. One thing I wanted to ask you, was, this is a bit random, but moving to London as a young person to start a career, is actually something we’ve talked about on the podcast before, because I did that myself at one point. And actually I wanted, you also mentioned “going to the UK.” A lot of people might not know that Jersey is actually not in the UK. Everyone can look at [the Wikipedia page](https://en.wikipedia.org/wiki/Jersey for the complex explanation. But you’re slightly off the coast of France. It’s a protectorate, I believe, is maybe the technical term for it? Or something that. But what was it for you, when you moved to London? What were your first job or jobs there?

Simon: So, it was something I fell into. I went to Reading University and studied there for three years. Of course, as most people do, you meet a partner. Then, I was faced with a choice. Do I bring her back to Jersey, or do we stay around Reading, or do we go to where her parents live?

In the end, we decided, for our first year after university, to stay in Reading. So in terms of going from being a student and graduating to getting a job, I did the whole “go to the careers fairs” things at different universities, and talk to the companies who are trying to get you to come on board and work for them and stuff.

I had a bunch of interviews with those large consulting companies. Didn’t really enjoy them. Not really for me. I had an interview with a small consulting company in London. I just really gelled with them. I thought, “Yeah, this is awesome, this is exactly what I want to do.”

So I ended up getting a job with a small consulting company in London. My now wife got a job with a small consulting company in Swindon. Reading was halfway between the two. So we would go our separate ways every morning. We did that for about a year.

Then, I think she came to our Christmas party as a guest of mine, and she basically got poached by the managing director of the company I worked for. So that killed the end of the Swindon thing.

Then we were both working in London for the same company, but different projects and stuff. Then after that time period, we ended up moving more towards London, and more towards the Kent area. Because that’s where my wife’s parents were based. So that’s how I got into the whole London thing really.

And, yeah, I stayed and worked in London for about 12 years. Obviously moved house a bunch of times. Of course, with London, the further out you move, the cheaper and the bigger the houses become, but the longer the commute becomes. So it’s all interesting trade-offs.

By the end of our time in London, we were living right out in the Kent countryside, with a nice big house. But the train journey was an hour on the fast train into London. And, yeah, it was fun. Really enjoyed it. Again, not something I’d planned to do. I would certainly do the same thing again.

What’s interesting is, when I moved back to Jersey, I worked with and met a bunch of people who have never left Jersey. You can tell there’s a different mindset. Something I always recommend to people, especially if they are from a small community, Jersey, of course, is to go out to the UK, visit some places, go work somewhere, get some experience in a big environment, and then come back if you want to. So, yeah, for me, it worked really, really well.

Len: Tanks very much for sharing that. I particularly love the detail of “part of London life is moving around.” Living in lots of different places. I had the experience of living in Angel, near Angel Station, a 15 minute walk from my workplace in the City, to being all the way out in Beckenham Hill.

Simon: We used to live at Beckenham Junction, actually.

Len: Really?

Len: Right, okay. So there was that commuting life. Something that you get familiar with. But also, it can be from many different directions.

Just getting into the detail, I think, of what, the work you did in your career, and maybe trying to draw a connection to where you went after that - so you were working early on with UML, or Unified Modeling Language -

Simon: Yes.

Len: I was wondering if you could just explain a little bit about what -? For maybe people who’ve never heard of it, maybe aren’t even into software programming at all, what is UML, and what work were you doing with it early on?

Simon: So UML, or the Unified Modeling Language, is basically, what’s the easiest way to describe this, particularly for non-technical people? It’s basically a way to draw diagrams that allow you to map out the design and architecture of the software that you’re building. So much, you might get a set of blueprints for a house or a building.

UML is the equivalent thing for the software world. So, yes, I started my professional career in 96 at that small consulting company in London. Pretty soon after I joined, first couple of years, I imagine, I went on a quite extensive five day UML course. That set the scene for lots of the stuff I did afterward.

Let me backtrack. The work I did was, I’m working for a small consulting company, but I’m actually building software either for or with our customers. Many of our customers were the big banks in London. So they would either give us a thing that we would build in our offices. Or more commonly, I would be shipped out to their offices, and get a seat and a desk in their offices, and work next to their developers building something on their premises, on their equipment, etc.

So when we’re doing that, there’s often a need to produce documentation. So, of course, I don’t want to work for the bank forever. I want to go and do different projects for different companies, and see different things, and get some variety in my career.

So one of my goals very early on was, “I want to make it so that I am replaceable.” Which is a weird thing to say. But one of the ways to do that, of course, is to make sure that everything I’m doing is nicely documented, so I can hand this documentation and the source code over to my customers. Then I can leave, and they can pick it up, and they can maintain it, enhance it, add features to it, etc.

Of course, UML plays a big part in that. When you are describing software systems, people want a bunch of diagrams illustrating, what’s the architecture of their software system, what technology’s being used, what processes need to be run on which service etc.? I used to use UML quite extensively for diagramming and documenting my software systems. That was the case, until, I think around 2004, 2005, something like that.

Then UML usage declined quite quickly, predominantly because of the Agile Manifesto for software development. Many people saw this Agile movement as an excuse to not write documentation. Unfortunately, UML became coupled with all of that stuff, and thrown away when people started doing their, quote, unquote, “Agile transformations.” So, yeah, UML was quite an integral part of the way I worked and documented software systems, up into mid-2000’s.

Len: This is a really interesting thing, that I know you’ve written and spoken about quite a bit. But, so, one way of thinking about this moment in history, and where things began to change, is that, a cartoonish view of it is, prior to the Agile Manifesto, this thing that came out, that we’ll link to in the transcript for this podcast. You can think of, again, and it’s a cartoonish representation of it, but people would write, let’s say a 100 page document, “Here are all the things that you’re going to write in your code.” Then they would hand that off to the programmers, and the programmers would follow those instructions.

Simon: Yeah, totally.

Len: Diagrams would be a high-level way of visualizing and explaining things. Then you would go into various levels of detail deeper than that, each box in a diagram might have then, a bunch of programming happening, associated with it. But then then this thing came out, called the Agile Manifesto.

What people were saying was basically, “We need to be able to not be so rigid, if we want to really produce great software, we need to be able to operate outside the constraints of just following a set of instructions.”

Part of the cultural shift was, “We don’t want to be handed off a bunch of documents that then we have to follow.” But what they didn’t say, was, “Don’t document anything, and don’t diagram anything,” right?

Simon: Right, yeah.

Len: That’s why the word “balance” is there in the title of your book. But then, so this shift happened, and UML, or Unified Modeling Language, wasn’t so popular anymore. There was maybe even a movement against it? I think that this played into the creation of your first book, and how it came about. I was wondering if you could talk a little bit about that story?

Simon: Yeah, so, what’s interesting about my thoughts on this whole subject now, is they’ve basically not changed for about 20 years. When the Agile Manifesto was created, and started becoming more popular, and more mainstream, I looked at it, and thought, “Well, that’s really the approach I try to take anyway.” Because prior to this coming out, I had worked on projects that worked exactly how you described.

Somebody would come to me, say, “Right, we need this feature built. In order for you to start coding, I want you to write a one page document detailing how you’re going to do this. It needs to include some diagrams that describe exactly what your code’s going to look. I want you to outline all the test cases you’re going to use to test your code.” I’m like, “Oh really?” This whole thing, to me, is, “This is just a complete waste of time. Because it’s just quicker to go write the code, and prove it works with test.” That’s why my thoughts on this whole thing, this whole topic, has not really changed in the past 20 years.

Coming onto the question. I go to my career, I’m working in London. I’m swapping between small consulting companies. If you work for a consulting company, if you want to grow the consulting company, you need more developers to form more teams. If you have more teams, you need more people to go and lead those teams. As I progressed through my career in London, I eventually move up to become a team leader/tech lead/software architect type role. I did that for a little while.

Then I was part of the group of people in one of the organizations that I worked for, who would go and train other software developers to move into those tech lead/architecture roles. The last company I worked for, we actually had a really good career progression matrix. We had a bunch of different roles or tiers defined in the organization. In order to move from one level, one ranking, if you want to call it that? One level to the next. There was a bunch of skills that you had to demonstrate on a team, on a project you were working on. It was a really nice way to make sure people had the right skills, in order to be promoted into the next level of their work. I was part of the team who were teaching developers to think architecturally, draw diagrams, etc.

In terms of the books. That training I was doing internally, I took that out externally. I started doing some training courses and some workshops for a local training provider in London, and also some of the conferences. Then I thought to myself, “Well hang on a second, what I’m teaching people is basically a lean and lightweight approach to what I consider to be modern software architecture.” Having gone through this whole movement from being a software developer myself, into a software architecture role, there’s a bunch of stuff that I felt I had to learn. I couldn’t find a single book that I could point to, that would basically lead me on that journey.

Now, of course, there are lots of software architecture books out there, and always have been. There are some fabulous software architecture books from the SEI, The Software Engineering Institute. But from a day-to-day, lightweight, pragmatic point of view, they weren’t answering the questions I wanted to get answered. “What things should I be doing and thinking about, if I’m leading a team of developers?” That’s really how I framed all this. That’s how I approached teaching this topic, and talking about it.

So, back in, I think it was 2008? I had this idea for a book. Which was a lightweight introduction to software architecture. Because I’d written some books for some publishing companies in the past, I pitched my idea for an architecture book to a bunch of publishing companies. Every single one of them said, “No, it’s a horrendous idea. You won’t sell any copies.” That was quite disheartening at the time. Around that time, Garr Reynolds wrote his Presentation Zen book. Have you come across Presentation Zen? It’s an awesome book.

Len: No, I haven’t, no.

Simon: Oh, it’s a fabulous book. If you ever need to do presentations, there’s tons of amazing advice in there. So, yeah, I was big into the Presentation Zen book. We were doing lots of presentations for clients and proposals. I think Apple had just released a way to write ebooks? I actually started writing a PDF ebook on my Mac. It was just very time-consuming, and I just gave up the whole thing.

So, yeah, that’s how I got into thinking about writing a book. Basically because I had this idea, and all the publishers turned me down.

Len: You were also doing something, which I think inspires a lot of people to write books this. Which is, “It’s the book I wish I had when I faced these challenges. Here’s what I learned.” But with the intention of, not looking back, but for someone who’s looking forward to doing all of these things.

There’s a couple of interesting things in there. One of which is, “what’s software architecture?” But also career progression, right? You go from being a programmer, let’s say, who’s getting handed these instructions or told what to do, “Now go back to your computer and do it.” To the person who has to think about how this is going to be, creating.

Simon: Right. Organize people’s work, and lead them in the right direction. Do team alignment, and all that stuff, yeah.

Len: Exactly. Designing software architecture isn’t just a diagram.

Simon: No, no.

Len: There’s much more to it than that. I shouldn’t say “Just making a diagram,” because that’s a very important thing that we’re going to talk about.

Simon: Yeah, totally.

Len: I was wondering, just for a moment, if you could talk about, what you do talk about in the book. Which is, what “software architecture” means?

Simon: For me, very simply, software architecture is about technical leadership. It’s exactly what we just briefly outlined. It’s having a goal in mind, putting a starting point in place. It’s making sure that everybody on your team is aligned. You’re all going in the same direction. We have the same, consistent approaches to solving common problems. We have a way to structure our codes, to do our testing. We’re trying to make sure that the software we’re building ultimately meets the requirements. Both the features that users want, and also things security and data confidentiality and performance and scaling, and lots of stuff that people don’t generally think about initially when they’re designing software. Yeah, that’s really my, in a nutshell, definition of software architecture. It’s about technical leadership.

Len: It’s interesting you mentioned, you had this concept early on, of making yourself replaceable. But part of that leadership is being able to handle, “If someone from the team drops off, what would we do?” Having a system in place. One version of that is a word that’s come up a couple of times already, which is “documentation,” which is, can someone learn about the project, without having, read every line of code, or something that?

Simon: Right, yeah.

Len: How would they first go into that? One of the really important ways of doing that, is having these visualizations. Those require operating at different levels of abstraction. So, one thing you developed, was something called the C4 model. To try and give a collective understanding, a shared language that people can have, about, what are the levels of abstraction, what are these things showing? I was wondering if we could just go into a little bit of detail about what the C4 model is?

Simon: Yeah, sure. Let me give you the backstory about how the C4 model came into existence.

So, again, end of the, 2005, 2010 period, I’m running training courses. I’ve started to take these training courses outside. Now, these are public training courses, and I’m getting people from different organizations coming along. Part of the training course was a design exercise. It’s, “Here’s a set of requirements. Break yourself up into groups of two, three, four people, and go away for about an hour and a half, and design a piece of software that will meet those requirements.”

The output from this exercise was, draw one or more diagrams to somehow describe and document your design, your solution. We did this. During the workshops I had this round robin exercise, where we would get every group to stand up and present their diagrams, and present their architecture, and we could challenge them and ask them questions about the solutions, to make sure they were going to work.

Very quickly, I realized that I couldn’t understand the diagrams. Here’s me trying to teach software architecture, and I can’t understand the diagrams people are producing in my workshop. I thought this might have been a small problem.

I could’ve taught people UML, of course. But as we already discussed, UML, kind of, is already on the decline in 2006, 2007, 2008. So, there’s not much appetite for teaching people UML as a part of my training course.

I’m thinking about, “Well, how would I do this?” That’s really where the C4 model comes from. The C4 model is essentially, it’s me formalizing and teaching people how I’ve always thought about drawing software architecture diagrams in that post UML era. The diagrams I used to draw was kind of, “Here’s a high level picture of the thing we’re building.” Then we progressively zoom into more and more detail, like you would with something Google Maps.

That’s essentially the C4 model. It’s a set of hierarchal abstractions, so different levels of detail. It’s a set of hierarchal diagrams, and map onto those, different levels of detail.

1. cutfromhere

Len: Yeah, and before, just to go -

Simon: 33:33 Let me just go and turn the phone off for a second. Sorry about that.

Len: Oh sure thing, no problem.

Simon: Sorry about that.

Len: Oh no, that -

Simon: Literally never have anybody calling the house, and then someone calls the house today. It’s probably a spam caller.

Len: Oh, almost certainly, at least in my experience. Yeah, so, Let me just pause for a second here. 34:06 Right. The,

2. cuttohere

Len: Just to go into detail, the four levels of the C4 model are, system context, containers, components, and code. I was wondering if you could just talk a little bit about that? What’s the system context?

Simon: The system context, imagine you are building a system to publish books. You have your system to publish books. Your context diagram basically says, “Right, I’m going to draw a box in the center representing the system that’s going to be publishing books.” Then, in order to draw the diagram, we have to answer a bunch of questions. First of all, who are the different types of people that might be using this book publishing system? You’ve got authors. You’ve got people who might be reading books, and purchasing books.

There’s a bunch of different user types. Different actors, roles, personas that you can instantly think of. They craft a diagram showing all of these different user types, and their interactions with the book publishing system. Then of course, your book publishing system might be integrating with other systems in the real world. Maybe if you’re selling books, you’re integrating with a payment provider? Maybe you have a box on your diagram saying, “This is the payment provider we’re using, and we’re using it to process payments.”

Or maybe you’re publishing your books to Amazon automatically? You might have a box representing Amazon, with a an arrow from your publishing system, to Amazon. That’s really the system context diagram. It’s basically saying, “Let’s draw a diagram with the system that we are focused on in the middle. Then we want to show the different types of people, users, roles, actors, personas who are interacting with our system. Then we want to show the other systems in the environment that we are interacting with, or perhaps they’re interacting with us.” So, yeah, that’s the system context diagram.

Len: It’s really interesting. At this level, one can think of it as, you’re not necessarily talking about a tech, even something straighforwardly understood as a technology. You’re talking about the high level, I don’t know? The people who are going to be interacting with it. The things you’re trying to achieve, is the -

Simon: Right. It’s super high level, very few technologies. It’s a diagram that anybody can understand. Developers on the team, architects on the team, testers on the team, through to non-technical business analysts, domain experts, project managers, etc.

Len: I was going to say that a really important feature of all of this is communication - there’s something called Domain-Driven Design that listeners might be familiar with, where people try and conceptualize, “Like how can we come up with both a, spoken or written language, and also a visual language for communicating about project in a way that people from all directions and all dimensions of it can understand it,” right?

The person who’s on, as it were, the business side of things, who’s being told, “Get the numbers up this quarter, Johnson.” That person’s interests are going to be, or understanding of the system, needs to be robust, but they don’t need to understand how the code works, or something that, right?

But the person who’s writing the code can often get way off in technical engineering land, and lose a sense that there’s this other side of things, where we actually have to make money, and that actually should drive some of your behavior and decisions that you make. That’s the system context level.

Then the next level down is “containers,” as you named it, before Docker became a user of that term, andthere it is. But that’s fine. What are containers in the C4 model?

Simon: By container, I basically mean an application or a data store. An application being something like a single page application running in your web browser. It could be an app running on your mobile device. It could be a traditional GUI desktop app. Or it could be a come online process or a batch process. But, yeah, basically it’s an application. It’s a bunch of code that you’re writing to do something. That code, you’re going to have to, run on a server, run on a client device. You have to deploy it somewhere. It’s that thing. Or it could be a data store. Most systems have data. That data is being stored in a relational database schema. Or maybe an Amazon S3 bucket, or the same on Azure. Or maybe just a bunch of files on a folder on a network share.

That’s really what a container is. It’s an applicational data store. And, yeah, the container diagram, the corresponding container diagram, basically, all it does is it takes your book publishing system, in this case. Zooms into the boundary of that system, and shows you the various applications and data tools that live inside that thing.

Now we’re getting much more into technology details. We’re talking about JavaScript, perhaps running in a web browser, communicating across the internet to your Spring Boot app, running on a server which is storing information in a mySQL database. So it’s getting more technical. But it’s still quite a high level diagram.

Len: To pick one book creation system that I’m familiar with. So, for example, if we were doing it at container level for Leanpub, we might have a container for our in-browser editor, for example, where you write your book in your browser. You might have a container for github writing mode? You might have a different container for our upload mode, for example? But at the system level, it would be book production, right?

Simon: Right, yeah.

Len: You might have a box for book production. Then in there, you’d have these different containers for the different ways of making those books. Sso the next level down, below system context, and below containers, is “components.” what are components?

Simon: A component is a heavily overloaded term in the industry, unfortunately. By “component,” I basically mean a grouping of code, a grouping of functionality, with a nice well-defined, nice clean interface running inside a container.

Basically, when I talk about components, I’m referring to the things that exist inside the applications that we build. If people are building a server-side application, which they consider to be a bunch of components organized in layers, your component diagram shows you those components organized into layers. Really, it’s starting to reflect the high-level structural concepts, the high-level structural building blocks that exist in your code base.

It’s starting to talk about the code and the code structure, but it’s not talking directly about the intricacies of the code, and how it’s put together. That’s what we save for level 4.

That level 4, if we go back to that story earlier, where you have the manager, comes along, and says, “Right, we’d you to build a feature. Please draw me a bunch UML class diagrams illustrating how you’re going to design that feature.” That’s really what level 4 is all about. It’s describing how things really exist in the code base.

Len: Level 4, the “C” for level four is “Code.” It’s really interesting, actually. One thing I know that you talk about in your talks and things, is, “You shouldn’t be manually diagramming the 4th level, or the code level.”

One of the reasons is that a lot of the tools that people use to write code, can actually produce diagrams, at the click of a button, that show you - there’s various categories, classes, for example, and things that, where you can actually just output really useful diagrams, without needing to manually devise them.

Simon: Yeah. It’s just too much information for most people to deal with, to be honest. If you’ve got an application, and it’s a million lines of Java code, for example. That million lines of Java code might be 50,000 Java classes. There’s no way that a class diagram showing 50,000 boxes are useful to anybody, apart from to tell you, “It’s a big system.” So, yeah, people really shouldn’t be manually creating these diagrams themselves, unless they specifically want to describe a small subset. Or maybe they want to describe a small subset that hasn’t been built yet.

But, yeah, for most cases, I encourage people to do automatic generation wherever possible. Assuming that they have some needs and will get benefit from having those low-level diagrams. Which, to be fair, most people don’t.

Len: One really interesting thing about this is that, it’s very easy to talk about diagrams, and how those diagrams correspond to some underlying technology. But when the technology changes, how do you change the diagram? All of a sudden, in a real application, you run into very straightforward issues. It’s very interesting, you’ve got a talk about diagrams as code, and things that. One thing that you’ve done, that you’ve gone ahead and, yourself, having this, developed this theoretical understanding and the practical application in terms of actually coming up with a shared model for how to do this, you’ve built your own diagramming software, Structurizr. I was wondering if you could talk a little bit about that, and what, why was it that the typical diagramming tools that people used weren’t really adequate to the process that you think people should ideally adopt if they can?

Simon: Yeah. When I was running my training courses for companies, again, we’re in a 2010 onwards era now. Most of my design exercises, the things I was describing earlier, they’re all done on flipchart paper, or whiteboards. It’s just pen and whiteboard, pen and paper. It’s a great way to do design, and it’s a great way to teach the C4 model, and it’s a great way to help people learn the C4 model. But always, the question that comes afterwards is, “Well, what tooling do you recommend? We find this approach useful, and we think it will work for diagramming our software systems, but we don’t want to use a piece of paper or a whiteboard, so what tooling do you recommend?”

When I started to do my workshops, my recommendation was really just, “Well, the diagrams are nothing special, they’re just boxes and arrows. And, okay, there’s some recommendations here and some guidelines. But essentially it’s just boxes with text inside, and arrows with the label on. Because it’s just boxes and arrows, you can use pretty much any tool that you’re already using. If you’re already using PowerPoint or Visio to draw diagrams, just use PowerPoint or Visio to draw C4 diagrams. That’s fun, and it works, but it grated on me. Me going into organizations saying, “Well just use Visio, it’s fine.”

Visio and other diagramming tools, they’re fabulous diagramming tools. They’re super sophisticated, and you can do a ton of stuff with these diagramming tools. But there’s a huge problem with them. Well, two problems.

First of all, you’ll spend a ton of time just making sure stuff looks nice. You’re trying to get all the boxes the same size, and the text the same size. You’ll try to align all the text in the same way. You’re trying to nudge the boxes so they’re nicely vertically aligned and centrally aligned and horizontally aligned. Then you might add one more word into a box, and it makes the box bigger, and it throws your alignment out. You’ve spent far too long just messing around with making diagrams look pretty, when it really doesn’t matter that much. That’s problem number one.

Problem number two is, the nature of the C4 model, is that it’s hierarchical. You have that system context diagram. In order to draw that system context diagram, as I’ve already alluded to, you’re drawing a bunch of boxes representing people, so your users and other software systems. When you zoom into the system that you are describing, to get down to level two containers, your container diagram is going to show the same people and the same software systems you are interacting with.

Of course, with a tool like Visio, what do you do? You’ve got your context diagram in one tab. What you do now, is you open a new tab in Visio. You copy/paste all of the people and the software systems onto tab number two, and then you fill in the blanks in the middle. But what happens when somebody reviews your diagram, and, well the name of that box, the name of that person is wrong? Okay, I can fix it. But now you’ve got to fix it on two tabs, and nobody does that. Of course, your diagrams become out of sync very, very quickly.

I figured this out, and I thought, “Right, what type of tool do I want to build?” Coming from my UML background, and using lots of UML modeling tools, the UML modeling tools did a lot of the stuff for you automatically, just because it’s a modeling tool. Visio is what I call a diagramming tool. All you’re doing is you’re crafting up a diagram with boxes and arrows.

A modeling tool is something a little bit more specific. With a modeling tool, what you’re doing is you’re creating a single definition of a person or a software system.

A modeling tool is something a little bit more specific. With a modeling tool, what you’re doing is you’re creating a single definition of a person or a software system. You might give that person or software system some characteristics, some properties, some attributes. Then what you do, is you start a blank diagram. You essentially say, “I want to use that person I’ve defined on my new diagram.” Then you might open a second diagram, and you might say, “I want to use that same person I already defined on the second diagram as well.”

Then when you go and change that central definition, and you want to rename that person, it’s automatically renamed across both diagrams. Both diagrams are essentially sharing the data from that shared model. That’s what a modeling tool is.

Unfortunately, when I say “modeling tool,” even in my current office talks today, people shut down and say, “No, we don’t want to do that.” Because they’ve got so many bad experiences from using big, bloated, expensive modeling tools from the late 90s, early 2000s.

With all this in mind, I was thinking, “Right, what’s the tool I want to use for myself?” The answer is, “I want to make a modeling tool. I want to solve the problem of inconsistent diagrams showing different versions of the same element. I want to make a tool that allows me to craft these models up quickly. I don’t want to worry too much about the look and feel. I do want the diagrams to look nice, and I want people to be able to change the fonts and change the colors and change the shapes, and all that good stuff. But I want the diagram rendering engine, the diagramming tool, to do a lot of that hard work for me.”

That’s essentially what my Structurizr tooling is. It’s been through a whole bunch of different iterations and variations over the past seven or eight years. But, essentially, it’s now a diagrams as code tool. You create a model using either a textual-based DSL, or you can use an actual programming language. There’s a bunch of libraries out there for Java and C# and Python PHP. You craft up a model of your software system using the textual DSL or some code. Then you pump that model into my Structurizr rendering engine, and it draws the diagrams for you. It has a very constrained look and feel.

So, again, it gives you the ability to change some things. Stuff like, “How is my text inside my box laid out and rendered?” is all taken care of for you. That was really the tooling I wanted to create. I want to focus on moving boxes around. I don’t really want to care too much about what the boxes look inside. I just want them all to be the same shape and size and color, and I just want to move things around easily. That’s really the driving factors about my tooling, and I created it.

Len: Thanks very much for sharing all that. There’s a [/DSL](https://structurizr.com/dsl page that people can go to as well, where they can -

Simon: Yes.

Len: See this actually happening in real time, as it were, and you can make changes and click a “render” button, and see how it changes and stuff that.

The more subtle point that you’re making, that actually having someone make decision decisions for you, can free you up to be using a tool in the sort way you really should be, for what you really should be focusing on.

Simon: Right. Yeah.

Len: Which is a challenge that, in our own world we have with Leanpub, right? It’s always a hard balancing act, right? Because people do care about how things look. How things look do matter. But if you’re really spending all this time on the formatting, you’re probably, well, spending too much time on formatting.

Simon: Yeah, yeah.

Len: Having things be a bit regularized, can really free people up to do the thinking. Then it can also, of course, very much help people when they’re, the people that you’re trying to communicate with, right? They don’t have to learn a new convention every time they turn the page or look at a new diagram. That goes back to the point you made before. Where you can look at a teams’ diagram, and they might’ve known exactly what they were doing at the time, but you have no understanding of what they meant by even an arrow, what, well, what is your, why is it that color? Why is it dotted? Why is it not dotted? Things like that. So, having these standardized things is a really important thing about communication.

Just moving on to the last part of the interview, where we talk about your experience writing books. You said you’d written books for publishers. But eventually you had this book idea rejected, and so you decided to self-publish it. Your books, I didn’t mention it, but you’re a bestselling author. You’ve sold a lot of books on Leanpub. I just wanted to ask you, what was that experience like? And, again, this is the part where we go into the weeds, for people who are interested in maybe becoming authors themselves, things like that. Did you do a lot of marketing for the book when you first published it, your first book?

Simon: Did I do a lot of marketing? Initially, no. I need to look back in history, and figure out when I first published my book. When was Leanpub first out there in the wild for people to use?

Len: Leanpub was first launched in 2010.

Simon: Right.

Len: I looked up your first book, and it, I believe it was created in 2012.

Simon: Right. Yeah, one of the early adopters.

Len: Yeah.

Simon: Yeah, back in 2012, I guess my Twitter following was probably only half of what it is maybe now? I didn’t really have a huge Twitter following. I didn’t really do much marketing.

Actually the first version of the book I published, was, I think it was five pages. I definitely embraced your “Publish Ezarly, Publish Fften” mantra. I think the first version of the book was $4.99, or something? I figured, you can put this out there, an introduction section, maybe some, “These are the sections I’m planning on writing. Here’s a $5 price tag. Is it worth me progressing with this further?” That’s really how I approach the whole writing thing. Did I do much marketing? Not really, other than just pushing some on Twitter.

That’s, I mean, obviously, that’s the canonical example of a successful Leanpub book, right? Is one that maybe publishers wouldn’t have published it, because they didn’t think it was going to work. You get it out there really, really early. But then it starts getting some traction, because you realize, actually there are, you’ve proven five pages in, that there’s actually interest out there in it.

Len: Thanks very much for sharing that. That’s, I mean, obviously, that’s the canonical example of a successful Leanpub book, right? Is one that maybe publishers wouldn’t have published it, because they didn’t think it was going to work. You get it out there really, really early. But then it starts getting some traction, because you realize, actually there are, you’ve proven five pages in, that there’s actually interest out there in it. Also, having a lower price at the beginning, that you raise as you go along. Things like that. But I imagine you must have probably promoted the book at conferences, and things like that?

Simon: Yes, yeah. I certainly have. It’s funny, I was putting together a new talk recently for a conference I’m speaking at in a couple of months. It’s actually, it’s a new talk, based upon a talk I did, I think in 2014? It’s actually got screenshots of my Leanpub book in there. So, yeah, I definitely did include a screenshot of the book cover in my early presentations, back in the, 2012, 2013 type years, yeah.

Len: That’s really interesting. Actually that reminds me. I skipped over a part of your career progression, that I was interested in asking you about. At a certain point, you went independent, you became a consultant. The reason I bring that up in this context, is that, often for consultants, having a book out there of your own, is a really important, it’s the best calling card, or business card you could have. To actually have a book to point people to, or to give to them, and things that. Did actually publishing books play a role in your ability to go independent?

Simon: It’s hard to say definitively, “yes.” But I imagine there’s definitely some correlation with that, yeah. I’ve definitely had customers come to me in the past, and they’ve said, “We’ve seen your conference talks on YouYube,” or “We’ve read your book, we’d to get you in to discuss the same stuff with the team.”

So, yeah, the way I approached the book, was, it was two things in one. First of all, “If I’m a software developer, what’s the book I want to read, to push me and nudge me in the right direction to move into a software architecture role?”

But also because I’m doing the training courses and the workshops, I also wanted to write a book that would form the reference notes for the workshop. The workshop covers almost exactly the same as the book, and vice versa. It’s a nice thing that people can read the book, and say, “Right, we’d like to get you in for a workshop.” That obviously helps with going independent. Also, I can gift people the book after the workshop, and say, “Here’s the slides. But of course, the slides are just lots of words on slides, so here’s the book with more detail.” So, yeah, it works both ways.

Len: I think, if I’m getting this right, you did something really interesting with your book that’s now called The C4 model for visualizing software architecture](https://leanpub.com/visualising-software-architecture). But it was originally, I think, called Visualizing Software Architecture. When I say, “originally”, for years and years, the book had this title and it’s different cover. Then you changed it. Is that right?

Simon: Yeah, that’s a really recent thing. This is complicated, and it all happened by accident.

The initial book was called Software Architecture for Developers. Once I’d been writing it for a few years, it was, I don’t know? Two, three hundred pages, maybe? It included everything. It included all my thoughts on what software architecture is, what the software architecture role entails. Things like quality attributes, and things that drive architecture. How to make architecture decisions. It included all my visualization, diagramming and documentation stuff. It included all of my thoughts on how to do just enough upfront design, and that whole balance with agility thing.

That was fine, it was great. But then I realized that many of the people who wanted the book were only interested in half of that story. Some were interested in the Agile half of the story, and they really couldn’t care less about the C4 model. Other people wanted only the C4 stuff, and they couldn’t care less about the whole Agile thing. Sometime in, again, I’m not sure exactly when this was, but maybe 2016, 2017 or something? I chopped the book in half. I kept the initial Leanpub book, and I moved all of the theoretical content around architecture to that book. That became Software Architecture for Developers, Volume One. I moved all of the diagramming and documentation stuff to what was called, (Software Architecture For Developers, Volume Two*.

You’re exactly right. The subtitle for that was, “Visualizing, documenting and exploring your architecture.” Only I realized, “Well hang on a second. I’m the author of the C4 thing, which has just taken off, and I don’t have a book that says C4 on the cover page.” I figured out I should fix that.

Actually quite recently I rebranded the cover page, and changed the title of the book so that the Leanpub slug URL are still the same. I think it’s “Visualizing Software Architecture.” But yeah, I changed the cover page and title of the book. I moved the documentation stuff from that second volume two into the software guidebook.

Now I’ve got three books. You’ve got the initial book which has all the theoretical stuff. The second book which is the C4 model, and just the C4 model. The third book, which is essentially the documentation stuff from the second book originally. It’s all very complicated. I think that works better now. I hope so.

Len: It’s complicated, but I’ve got to say, for anyone listening who’s familiar with the publishing industry, it’s incredibly radical, what you did.

Simon: Yeah, I know.

Len: You had a bestselling book that you changed the title and cover of. I mean, and that would’ve been in people’s - no, no, it’s great. I mean this is, we love seeing this experimentation happen.

And, so for example, what would happen is, you would’ve bought Simon’s book, maybe in part of a bundle? It would be in your library, and then you’d go back, it’d be a different, it would be different.

I’m really curious, did you get any push back, or any people mad at you about that?

Simon: No. The only push, Well, the only push back I really got, was when I initially split the first book into two books. Because then people were like, “Well, I paid for your first book, and now you’ve removed half the content.” I’m like, “It’s fine, don’t worry because I sent to you -“ You have that feature where you can email all the readers, if people are opted into it.

When I sent the book, I sent all of the readers who opted in, “I’ve split the book, here’s a code to get the second book, which is the same content you already have, but here’s the code for the second book that you can use for free. That now you’ve got both books in the library.”

But of course, a bunch of people never opted into those emails. So, yeah, once every other week, I’d get some snarky email saying, “Hey, where’s all my content gone? I just got a new version of your book, and half the book’s missing.” They’re like, “What’s going on here?” It’s like, “No worries, here’s the code.”

That happened for two years. But, yeah, with the recent split, that’s all been fine as well.

Len: I’ve got to say, having been around Leanpub for so long, it’s so interesting to see, because we had a post that we did a long time ago, and we had a whole feature for ebook “mitosis.” Because you weren’t the only person to have this experience, where, “Oh this is actually two books.” So, we had to actually come up with, yeah, a system for, “What do you do if you want to split a book in two? Oh well, you’ve got to make a free coupon for the second book. Try to communicate that to your readers as well as you can. Have a way for them to get in touch with you if they didn’t get the message, and they’re wondering what’s going on.”

But the, the really fascinating thing to me about this, is that 10 years ago, doing this stuff, people probably would’ve been, “Woah.” A lot of people would’ve been, “What happened, what’s going on here? This is crazy.”

But even four or five years after that, by 2016, 2017, we started noticing that people were actually getting quite comfortable with experimentation, and a really important thing was trust. That they wouldn’t be like, “Oh, you’re trying to scam me,” or “You’re trying to make me buy a second book now.” They’d be like, “Oh yeah, what’s going on here? I’m sure there must be something that -“ If they missed, if they didn’t get the message, they’ll be like, “Oh, I’m sure there must be something that I’m missing.”

For people in the very staid world of books, to become comfortable with that level of experimentation, is actually a real change in the publishing world, that’s just been fascinating to see.

It was just so interesting from our perspective, to see this evolve as we helped create this platform for authors to do all this experimentation with. For people in the very staid world of books, to become comfortable with that level of experimentation, is actually a real change in the publishing world, that’s just been fascinating to see. So, for example, you published a five page book, and I paid five bucks for it - in the very early days, there’d be people who were, “What’s going on?” But that didn’t really take that long. I mean, of course, messaging, and stuff like that mattered.

Making sure that you displayed, “This is an incomplete book,” and stuff like that. But there was a real appetite out there. There’s a real appetite out there for people, I think particularly to - it gives them a sense of connection.

This is my, I don’t know? Emotional take on it. But it gives people a sense of connection to the author and their project, to see things changing, and to be allowing the author to have this latitude.

Anyway I don’t know, I don’t have much more in detail to say about that. But it’s just been so interesting watching this experimentation happen, and seeing people learn how to consume the experimentation part.

Simon: Yeah. I think some of the biggest backlash I’ve had, is over the progress counter. You’ve got the, “How much percentage is this book complete?” My books, for a long time, both of them were 80% or 90%. Because from my perspective, I am an independent consultant. I’m going and doing workshops and training courses and conferences on a regular basis. I’m building my tooling. I’m having different ideas and different approaches. I want to get the books. My books were never finished. My software is never finished, it’s continuously evolving, as you say. I left the progress counters to 80 or 90%.

I got so much hate mail. “I paid for this book, when are you going to finish it?” I’m like, “Chill. It’s a work in progress. I’m learning new stuff. You’ve paid one price, and you’re getting all of my new understandings and opinions on this topic. Don’t worry about the progress counter.” That didn’t go well. “Yeah, but when are you going to finish it?” I constantly got this barrage of, “When are you going to finish it?” type questions, from people who were quite angry at me for not finishing my book. Even though, that, at that point in time, there was nothing new to add.

The way I got around this, was I just set the progress counter to 100%. All went away. I’m still making updates to the books, but I’m just saying they are finished. So that’s one part of the process that I don’t think people get yet.

Len: Thanks very much for sharing that detail. That’s really interesting. For anybody who is a Leanpub author who’s thinking of doing it, this is the, I mean, we just had the very happy talk about experimentation and people loving it. But there are challenges when you experiment that as well.

Sometimes you’re going to have to do some - well, we do as much explaining as we can, and we listen to the challenges that authors have, and try and change the way we display things, and stuff like that, and explain them. But, yes, in particular the progress counter, as it were, that says, “This book is 80% complete.”

Just so people who are listening - in addition to that, to really get into the Leanpub weeds. We also have a “last updated” thing. There’s a little date that can be shown as well. I’ve experienced that before a few times, where, for example, there’s this one really good book, that I forget the title of right now. But that’s marked as 50% complete, or something like that. It’s an amazing book, and it’s 400 pages, right? But it’s been 50% complete since 2016, or something that, right? I think the author did it as a joke. That she realized, “This is going to be an 800 page book if I finish it. But we’ll sell this as part of our newsletter sales and stuff like that.” Occasionally people would be, “Why would you put a book that’s only 50% complete, that hasn’t been worked on in six years in your sale?” “Because it’s an amazing 400 page book.”

And, again, we show these things on the book landing page. It’s actually, you can say, “Oh, 50% complete. But it’s 400 pages.” Scroll down a little bit. We do show, “You can get a refund if you don’t it,” and things like that.

But, yes, the progress thing. People are often very curious about, “When is the author going to finish it?” That’s something that we handle a lot of the messaging around that as well, right?

Because, writing a book is hard. All kinds of things can happen in people’s lives, right? They might start a book, and they sometimes don’t finish the project, ever. It’s actually, it’s your responsibility as the author to do what you can to manage that.

But it’s our responsibility too, to have the messaging there and saying, “Yeah, Leanpub is a unique place to buy ebooks from. You might buy a book early on in a project that doesn’t get finished. That’s why we have the refund policy that you can get within 60 days of any purchase.” Things like that.

It’s why we’re so transparent. If you’re buying a 10% complete book, there really is no guarantee, but there are lot of people, who, yes, who don’t have much of a sense of humor, or maybe, an artist’s appreciation for projects.

There’s this idea of, the book isn’t 100% complete. I was saying this in a funny way, but there is a certain mindset. Where it’s like, “Well, I paid 100% of the price, I want 100% of the book.” And, yeah, just, if you’re publishing a book in progress, or you have what we’ve called for years, a “living book,” right? One that’s always going to be changing. Then managing that is just part of the challenge.

Simon: Yeah. The irony of this, from my perspective, is that my books are almost solely targeted at software developers. Software developers, in most cases, these days are building software in an Agile iterative fashion, and they’re getting features out to their customers and their users, and then they’re adding more features. Of course, if they’re building a subscription service, they’re charging people $20 a month, and they’re putting out a bunch of features. Then a month later, they’re adding more features, but the $20 a month isn’t changing.

Imagine you go to your favorite website, or your app Spotify, and it’s got a progress counter. How complete is Spotify the app? Is it 100%? No, because they’re adding new features every single day.

The irony for me, my book’s targeted at software developers. They’re building software that’s never complete, but they’re having a go at me for writing a book that’s not complete either, because it’s an iterative and incremental process. I thought that was quite funny.

Len: It is funny, I know, I agree. But it’s also, when we’re presenting things as books, there is a notion of completeness and finality to that.

Simon: Yeah, yeah. It’s a thing, isn’t it? A think that you’d buy.

Len: Yeah.

Simon: It never changes.

Len: Yeah, exactly. That’s the thing that we think makes Leanpub fun. But it is something that also makes it unconventional and confusing sometimes.

Simon: Yeah. Just a mind shift, isn’t it?

Len: Exactly. But I think, I would say confidently, once people, as long as they have the trust, they’ll eventually come to understand what’s really going on here. It is incumbent upon us as Leanpub and our authors who are publishing, to be communicative, and stuff like that, and develop that trust.

The last question I always ask on the podcast, if the guest is a Leanpub author, is, if there was one magical feature we could build for you, or if there’s one thing, I mean, in your case, over the years, that had you always shaking your fist and shouting at the screen when you were working on a Leanpub book that we could fix for you, can you think of anything that you would ask us to do?

Simon: I jumped on Leanpub fairly early. I think I’m pretty much still using your original version of the Markdown syntax. It’s the same thing we discussed already. I’m writing a book. I just want to get words on a page. I want it to look nice, but I don’t want to have to control all of that stuff.

For me, it does a perfect job. I get that’s not great for everybody. Now, if you’re into layouts, and you wanted to build something very graphical, then it’s not the platform for you. But for me, it’s been fabulous. Because I can just have a bunch of text files, in Dropbox in the past, and write text, and magic happens, and it’s fabulous. So, yeah, from my perspective, it’s done everything I’ve needed and more.

Len: Oh, well, thanks very much for that. If you ever do think of anything, or if you ever do find yourself shouting at the screen, just please reach out and let me know.

Simon: Not at all, no, it’s been fantastic.

Len: Okay, well, Simon, thank you very much for finally being on the Frontmatter Podcast after all these years.

Simon: Yeah, great to chat.

Len: Thank you so much for being a Leanpub author.

Simon: You’re welcome, thank you.

Len: Thanks.

And as always, thanks to all of you for listening to this episode of the Frontmatter podcast. If you what you heard, please rate and review it wherever you found it, and if you’d to be a Leanpub author, please visit our website at leanpub.com.