Cesare Pautasso, Author of Beautiful APIs

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Cesare Pautasso.

Based in Lugano, Switzerland, Cesare is a professor at the Software Institute at USI, Lugano, whose research focuses on the architecture, design and engineering of next-generation Web information systems.

You can follow him on Twitter @pautasso and check out his website at pautasso.info.

Cesare is the author of a number of books, including Software Architecture: Visual Lecture Notes, Just Send an Email: Anti-Patterns for Email-Centric Organizations, and most recently, Beautiful APIs.

In this interview, we’re going to talk about Cesare's background and career, professional interests, his books, and at the end we'll talk about his experience using Leanpub to self-publish his book.

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

Cesare: Thanks to you Len, it's a pleasure.

Len: I always like to start these interviews by asking people for 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 computers and technology?

Cesare: I was born in Como, in the northern part of Italy. I think you might have heard about the place,because there is a beautiful lake - and there is Bellagio, which I think everybody has heard about.

My first computer was actually a Commodore Vic 20. So by this reference, I think you can figure out how old I am. At that time, the software would come printed in magazines, and we would actually spend hours and hours typing it in the computer - just to see what would happen.

And at 16, I had the opportunity to spend one year as an exchange student in the US. That's the time when long distance calls were super expensive. There was no WhatsApp, there was no Zoom, right? It's amazing what they're doing now - high-quality video conferences over eight time zones, for free.

But at that time, we would just use to write long letters to keep in touch. And in the US, I got to learn about bulletin board systems. It was also a new experience for me, related to technology.

When I came back, there was no doubt that I was going to study Computer Science at the university. The big question was whether I would go to the Politecnico, the technical university - or the university, which I had a shorter four-year program. When I started the Computer Science engineering degree, I spent the first year studying math, physics, chemistry, electronics - and also one lecture on fundamentals of informatics.

At that time, I was really wondering whether I got into the right track. But I think it was great to do theory, and to do that kind of broad theory. Because you do not just understand what Computer Science is about, but you also get a chance to look a few layers underneath - to see, to understand what is really going on inside the machine. I think we managed to touch our first computer after a couple of years when we convinced an assistant to let us into a lab, where we could actually go and try out some of the programs that we would write on paper.

So at that time, the university education was very theoretical. But I think it's also an advantage, because we didn't spend time learning things that would become obsolete anyway. So that was good, to get a foundation of things that are actually true, still today. Then we were able to pick up everything else on our own.

I remember, at the end of the summer - one junior professor, one day, at the end of his course - he said, "By the way, there is this thing called the web," and he gave a brief introduction about how links were implemented. And then he said, "You can go to a conference we are hosting here by the lake, and you can try it." They had a few computers running one of the first versions of Netscape. And I got immediately - how do you say -? Really - It was truly amazing, how you could just navigate around the world, talk to computers all over the place, just by clicking on some links.

That was sort of getting to the end of my university studies. And I was lucky to find a thesis project. I started on the Erasmus exchange. So I left Italy to go north of the Alps in Zurich, in Switzerland at the ETH in the Information and Communications Systems Group. And there, they actually had lots and lots of computers. They had computers everywhere. I think they were running something called "Sun Solaris." It was also an incredible discovery.

They were trying to basically use them to recycle unused computer cycles - like at night, over weekends - to run some complicated computation made out of lots of data. I think later, this was something that they called "scientific workflows," or just "big data processing." We managed to run that over the transition between 1999 and 2000. That was supposed to be when the clocks would switch and everything would crash. But actually our system could just keep running and get to the result. So the project was successful.

But as with every research that you do, you sort of climb the hill and then you can see the big mountains ahead. So I was really lucky to get an offer to stay in the group as a future student. And that basically means that I am still figuring out how to extend my Erasmus, my research exchange, because I never came back home, basically after that. I moved to Zurich, I spent many years there. And then I also was in the IBM research lab, on the lake of Zurich - and then afterwards, I became a professor in 2007.

So that's a long time ago in Lugano here, the new university that had a brand new faculty of informatics, and I've been here ever since.

Len: That's really interesting. I didn't know about your year in the United States, or that you'd been a part of the Erasmus program. Were you part of a particular program when you went to the United States, or was that something specific to your school that had an exchange program, or something like that?

Cesare: Oh, that was the AFS exchange program.

Len: AFS.

Cesare: American Field Service, yes.

Len: Okay. Actually, if you wouldn't mind taking a couple of minutes to talk about the Erasmus program, that's actually something - I've interviewed a couple of Leanpub authors who participated, and I think both of them met their spouses, and both of them permanently stayed away from their home country, after participating in this program, and never looked back. Can you talk a little bit about that really amazing program for just a moment?

Cesare: For sure, it's a really important program to build future generations of European citizens. Because in the age where they're starting to become independent, they are studying in the university - they get a chance to spend one semester, one year in different universities. And it's not a random choice. It's typically - Universities form exchange networks. So, for example - in Lugano, we have connections with Spain, with Eastern Europe, with - we used to also have them with the UK. But advised by their professors, they can find the relevant studies to basically do in the other place.

From a - how do you say? From a logistical point of view, there is a little bit of support. I think it's really great to not just continue this and have the opportunity to see a different university, but also to see a different culture, different country, different language. And, like you said, make friends all across Europe, and maybe also fall in love and meet somebody that is not from their native countries. This is really important to mix together the European population, I think.

Len: I think one of the interesting sort of challenges that people face when they participate in programs like that, is different university systems. I'm curious about the way it works in Switzerland. Is it - I mean, most of the people listening to this podcast are probably from North America, or at least familiar with the North American education system, where you go through kindergarten to grade 12. And then if you do a university degree, it's typically a four-year degree - where each year, there are two terms. And in each term, you take say five courses, or something like that. How does an undergraduate degreecurrently work in Switzerland?

Cesare: Well, education before university is actually managed by each canton of Switzerland, so like each state. So they have a different system. But once they get to the university, then this is actually standardized at the European level. So this means that you first do a three-year Bachelor's, and then you do a two-year Master's program. And between the two levels, you can actually switch universities. So you don't - typically students will go three years in one place, and then they go somewhere else for the other two. And after that, you can also do a doctorate or a PhD.

Len: And is it really expensive, or is it cheap - or is it in between?

Cesare: Well, I suppose it depends relative to -

I mean, people might hear it costs $60,000 a year to attend, say, an Ivy League university in the United States. Is it a similar kind of absolute burden on people?

Cesare: No, no, no. Compared to that, the tuition fees here are much lower.

Len: Okay.

Cesare: I think actually in Lugano, we are the most expensive university in Switzerland. And the students will pay 2000 francs. So, well - approximately $2,000 if they are Swiss. And otherwise, $4,000 if they come from elsewhere. But that will be for one semester. But I guess that gives you a reference point. Other universities in Switzerland are even cheaper than--

Len: And is it two semesters per year, and then like four months off, or something like that?

Cesare: Yes, actually we just got started this week. So that's a spring semester, and then there is a summer break. And then we start again in September, and continue until before Christmas, basically.

Len: Okay.

Cesare: So those are the two semesters, yeah.

Len: Okay. That actually leads me onto something I introduced - it's been almost a year now, I've been saying, "Since March." I've tried introducing a segment into the podcast, where we ask the guest about their experience of the pandemic, and how it's affected the life in the particular place where they live, which is interesting, because we get to interview people from all around the world on the podcast.

But also, how things have affected them professionally. And you're a professor. So I was wondering if you could talk a little bit about how things have affected your work? Just a little bit of like an anecdote or two about how things have affected life in Lugano. And then how things have changed for you professionally during this time. So for example - did people start wearing masks early on? Have they ever started wearing masks outside? What's it been like?

Cesare: Okay, so - well, approximately - yes, it's already been one year. There was a time when they started to have the first cases south of the - basically, here, we are very close to Milan, that's the region of Italy where the first cases were detected. And so they had this situation in which they were starting to lockdown and having problems. And then the rest of Europe would actually just watch and wonder what is going on down here, in Italy especially. In Switzerland, we were kind of privileged not to have a strict lockdown like on the other side of the border.

And, but - yes, there is a border. And you wouldn't feel it before, but now it's serious. If you want to cross it, you have to have a pass - a check, right? A test. And that - basically before one year ago, we would just go to Italy just every other day - and now this is no longer possible. So that, definitely, it's a different world that we are living in now.

And as a scientist, we are part of a global community of researchers - of scientists that meet each other, visit each other, exchange ideas and travel the world, present at conferences. And all of these type of meetings where you have a big crowd gathering together, I think they will not come back for a long time.

But, as opposed to - for example, people like musicians or actors in the theater, or these kind of things, that have been severely affected - we are sort of privileged, because we can still keep teaching through remote, virtual classes - and also, we can keep doing the research and publishing papers. And we just don't get to travel around the world to present our work and discuss with others, we do it over Zoom - so we definitely are suffering from Zoom fatigue.

Len: So you've been teaching over Zoom to your students?

Cesare: Yes, basically now it's - we started the last year, spring semester - we actually started in-person. Because it was the time where things were totally uncertain. And so we started in-person, because we didn't know.

And at some point, there was actually a big decision from the top to close the university, and switch to remote teaching. But we didn't lose even one day of school. Everybody was ready, ready for that time. And I'm proud to say that in the Master's program that I direct, that was a transition that we could manage. And now, we did also the full semester and the spring semester starting online. And everybody's hoping that by the time we get to the summer, we can do the exams in person. But it's difficult to predict.

Len: And just anecdotally, how have you found students to be adapting to it? Has it been kind of - they're - it's a bit of a sort of funny term - but are they digital natives, and so it's no problem for them to just switch from being in person to being on Zoom?

Cesare: Well, for example in my group, I have two new students that arrived just before the lockdown. So they were really lucky to make it here on time. Otherwise it would've been difficult to move to Switzerland. And that's how we were able to get started in the way that it's supposed to be. And then now - of course, we are just collaborating remotely. And - yeah, occasionally, we'll still run into each other - because we are all nearby.

And for the students that come to lectures and so forth - yeah, we see that they still manage to learn and pass exams. So then, of course it's tough for them. Because you are not just isolated at home, participating in all these lectures - and you have to keep awake and keep participating through the computer.

But I think the social aspect is also a big problem. Because - yes, they can have all their virtual chat forums and so on, but it's not the same as hanging out in the campus, and -

Len: Oh, definitely. And particularly at the level where you're doing research. I mean, it's a bit ineffable, but the kinds of things that happen - and you were mentioning conferences and get-togethers and things like that - the kinds of things that happen when you're just around other people who are thinking about things on the boundaries of knowledge - it's very hard to replicate that in kind of scheduled encounters.

Cesare: Yes, there was a virtual conference that I spent last weekend in. And they had - during the breaks, they had - they switched from Zoom to something called gather.town. And then, basically - that's where you can see your avatar and you can walk it around and they build - you are supposed to be in this castle in Germany, right? Our place or people do kind of like retreats. And so you have a recreation of the castle, and people could walk around.

And when you bump into somebody else, because you happen to be in the same room for example - then you can actually - again, chat over the video. And that would sort of replicate the serendipity of the coffee break. Of course, although you leave Zoom and you go into the other tool - you're still sitting at a desk in front of the computer, when you just really physically would like to walk around and stretch a little bit. So that's very difficult to keep doing this for - yeah, it's difficult to see what the future will be like. But, to be able to do - yeah, to keep together, the connections alive in the scientific community over long periods of time like this - that will be very challenging.

Len: That leads me to ask a version of a question that I ask on almost every interview when the guest is a Leanpub author, and they're someone who's sort of in the technology world.

The version I'll ask you, because you're actually a professor, is - if someone wanted a career being a software developer and they were skeptical about the value of a four-year university degree or a three-year university degree, when there are so many resources available for learning online - what would you say to them, to convince them that they ought to or - or what would you ask them to try and find out if actually studying at university, a Computer Science degree - was a good idea for them?

Cesare: Well, they can still try to get into this, Google's program - and they learn everything they need to learn in six months. So why should they invest four years of their life to get the formal education at the university? And what I could - used to tell you last year, it was that, "Well, you are going to be physically together with a group of like-minded students and a professor that care about your education." That will give you something that you don't get by just watching videos at night from some random YouTube channel. That is more difficult to sell now, because of course - we are all virtual.

And that basically - when they virtualized the religious masses in Italy, people could watch - go to service on TV, yeah? But then, everybody wanted to watch the Pope. So the local churches had a little bit of a competition problem.

So, if you translate the same in university education - of course, the more that we are virtualized, then this opens up between competition at a very different level.

What is still important, however - is the fact that you, as a student - are participating in a curriculum that is thought out as a whole. You are not just going to learn from random collection of tutorial videos. But you get deeper, and you try to learn things that will remain with you for your full career. And they will make it possible for you to learn how to learn and keep up to date with technology.

And that's - I think, is the value of a university education. That is deeper, and it goes to the foundation. And in a certain discipline, is not going to change so quickly as the latest buzzwords, right? Because in Computer Science, in the industry - every six months or every year, there is a new trend that then you have to keep running to stay in the same place.

Len: Yeah, to put my cards on the table - I'm firmly in the camp of I think - for the most part, when one is young - to spend a few years in study. And regardless of what your plans are, what you think your plans are for your life, and the things that you can learn at a very deep level - when you're actually taking like years to learn about them from people who've gone through it and know, are profound.

That's really interesting what you say about, all of a sudden the local priest has to compete with the Pope when things go online. I hadn't thought about that. But if people are attending virtual concerts, it's going to be - it might not be the local person with a guitar. It's going to be Bruce Springsteen instead. And that would be difficult to compete with.

Just before we go on to talk about your books in the next part of the interview, I just wanted to ask you if you wouldn't mind - for a couple of minutes, talking about the kind of research that you're doing currently? Maybe if there's a particular project that you're working on or something like that?

Cesare: I work in the boundary between software architecture, web engineering and business process management. At the moment, our current project is on API analytics. We try to study how people design APIs, and how can they do it better. And that's also - one of the results of the project was also the book on Beautiful APIs that just came out.

And then I also have another project, which combines together concepts from business process management and the blockchain. This is a new collaboration with the HPI Institute. At the moment, we are looking for students to help on this particular project. So, that's why I mention it explicitly. If you know how to program the blockchain and you would like to run processes over it, come to me.

Len: That's really interesting. Hopefully I'll be able to ask a couple of related questions to that when we talk about the APIs book. But that's really fascinating. I think I might be able to see a connection between that and micro-services and stuff like that, and how you manage backing up systems and stuff like that. Which is something - I watched a talk that you gave that was on YouTube about that, and I'm suspecting there might be a connection between those things and blockchain.

But before we do that, like I mentioned before we started recording, I'm really looking forward to talking to you about your book from quite some time ago, Just Send an Email: Anti-Patterns for Email-Centric Organizations. I know it's been some time since you wrote it, but I was wondering if you could talk a little bit about what the book is about, and what your inspiration was for writing that one?

Cesare: Okay. So that book is about the collection of anti-patterns - basically, things that people do, because it's easier to do than this way, but they have a negative influence.

In the case of email, it's easier - for example - for the sender, to act in a certain way. And then the recipient has to pay the price. This is actually quite a large collection. It's all based on my personal real-world experience, and also of other people that I work with.

It happens when you - what's the first thing that you install when you digitalize your company? Imagine that you're a company where people don't have computers. Then you actually install computers, and the first thing that you have is an email, right?

Everybody can send messages to each other. So congratulations. You are now a digital company, and you can make all of the mistakes that I list in the book. And you shouldn't do that, you should try to learn how to use email appropriately.

And those patterns, or those anti-patterns, they all come with a solution, with a proposal - how to do it better. For example, when you try to send an email - think about it. And maybe you don't have to send.

It's also part of the experience of - I think this is a problem that is shared when your working life requires to handle hundreds of emails every day, and then you start to detect some things that could actually be done a little bit more efficiently.

Len: Mine does. And yeah, definitely it's - I've never formalized things the way you have in your book. But one of my - there's an old Mark Twain joke, which is - he was writing someone a letter and he said, "I'm sorry I wrote you such a long letter, I didn't have time to write a shorter one." And there's an email version of that for me. Which is, there's a certain kind of person who thinks they're saving time by writing a short email, when if you just took a little bit longer to actually give all the details that you need. So it's kind of like, "I'm sorry I'm writing you -" Like, how would you formulate it? "I'm sorry I'm writing you such a short email, I have a lot of time on my hands." So I can get away with writing you a short email. Because that means there's going to be a lot more back and forth.

Cesare: Okay. Oh yes. Then it becomes a chatty email. And then maybe you should install some kind of a Slack chat channel that also has it's own set of problems, right?

Len: Yeah.

Cesare: Yes. If the email is so fast that you receive it before you actually sent the original one - if you received the answer, than I call it a "lightning reply." And sometimes you get the reply that just says, "Yes." But in the email that you sent, you actually had three questions. And so you don't know if the "yes's" are them, or maybe you just write the first - and you just answer the first very quickly, and then you ignore the rest.

Len: That captures it better what I was trying to say. It's like - if you think you're saving time by just writing "yes" in response to an email, you might be actually wasting a lot of the other person's time - and your own time as well.

People who use the subject line for the content of the email, for example - are, I think - typically fooling themselves into thinking that they're being a real like hard-nosed go-getter. But actually they're really just signaling that they're unprofessional and they don't even value their own time.

One of the examples of the anti-patterns that you talk about is the room booking email. This is a specific example of a higher-level category of like, "Can you please do something for me, that I could've done in the time it took me to write this email?"

Cesare: Yes of course, email is also down to who is delegating things to other people, and who has the power to do things that are written in the email. And sometimes it's actually not so simple to direct the message to the person that is actually supposed to do things.

But of course, if you just have an email infrastructure and you use it to run everything in your organization, then you miss out on things like - for example - tablets are on the door of the meeting room, and then you can just swipe them to reserve them before you enter the room, right? Those are perks of organizations that have graduated beyond just using email for everything. And, yes - the reserving rooms by email is unfortunately something that is still happening in many places around the world.

Len: You also have a great - I mean, I should say - the book is basically sort of a really great, sort of fun list of these anti-patterns. One of which is, "Dear Typo." I'm just looking at it now. "Dear Typo, I could not care less how to spell your name right." It's a great one. That's one thing I've always found so - I mean, we all make mistakes, right? But there's a certain kind of mistake that betrays the fact that someone hasn't tried.

Cesare: Well, this is also part of my personal history, why people have a hard time to spell out my name sometimes. And then I can tell whether they made an effort - for example, just to copy/paste my name and put it in the reply. But that's also a suggestion for people that write email tools. Maybe the tools should be smart enough to help you with that trying to - be able to spot these kind of stupid mistakes. And of course, academics - the name is pretty much the only thing that we have. So that's our personal brand, if you will. And so if you make a mistake in a typo, it gets really personal, pretty soon.

Len: Yeah, that reminds me. This is sort of like, very much a detail - but one of the, like - one of the most important professional tricks I ever learned was, "never type what you can cut and paste." Like, never type what you can cut and paste. And that really helps, particularly with respect to names.

And there's - I mean, because the name, particularly in a communication like an email, comes first. It's the first thing people see. And so if you do something wrong with someone's name - already their confidence is shot, that you're a worthwhile interlocutor.

I'm just sort of looking at - if someone's listening to this and they're going, "Yeah, okay - what would your like sort of high-level 60-second advice be to somebody who feels buried by email all the time?" What would you suggest that they do to change that situation for themselves?

Cesare: Well okay, so I take it that you are from the recipient perspective?

Len: Yeah.

Cesare: Another incoming flood of emails?

Len: Yeah, yeah.

Cesare: So I actually have five points of advice that I give in the book.

The first one is that you can use "delete." When in doubt, just delete it. If it's important, it will come back anyway. The second one, it's - the button next to "delete" is called "forward" or "delegate." So you can actually bounce the email somewhere else. The third one is "deny." You can always say, "no." And the fourth one is not so nice, because you can - if you delay it, if you just wait to answer the email - emails have a tendency to pile up, and there is a risk that you will never go back to that one and the sender will be unhappy, because it doesn't get a reply. And of course, when everything else runs out - then you still have to do it, right? So that's the final thing. When you run out of options, then somebody has to take care of the email.

Now, related to the delay case, there is one other button that I actually - I'm very proud of the way that I name it. That is called, "Re:gret". Which is the email you put off responding, since you want to give it your full attention. And you invest a lot of time in the answer, but you never have the time and you never answer, giving the sender the impression that you don't care. But this is the most important thing that is sitting in the inbox. You just haven't had a chance to do it. And that's the "regret" email button.

Len: I guess my last question would be, can you talk a little bit about, "The email from God"? Which, I really love that name, myself.

Cesare: Oh, okay. So that one is the email that comes from the very top of the organization, and it comes at unexpected times. It has very big announcements that impact the whole organization. And it can really, literally - when you get that email, you can hear the noise of thousands of people stopping in their tracks, then maybe switching their priorities and doing something that are supposed to be doing.

It's very powerful to have such broadcasts. But it can also - if abused, people start doing no work, and you have internal consequences. When you send an email from that position, you have a very big responsibility. So you need to be careful what you're ask the people to do.

Len: That's really great. I have to share an anecdote. I remember once getting an email from God, which was the announcement that the CEO of the global investment bank that I worked for had changed. And it came with the instruction that we all needed to start wearing - all the men needed to start wearing ties. And our organization had been kind of known for the fact that we only wore ties to meetings - like business ties, business suit ties. But otherwise, we didn't wear them. And the new CEO was taking the opportunity to announce that now he was going to whip us all into shape, or whatever he thought he was communicating by doing that.

But it very much was like, everything stopped when everybody got this email. And you could hear a thousand minds worrying, like, "What does this mean? Why make this change? You don't understand." And in particular, on the part of some people's cases, like, "You don't understand - this was a way of being aggressive, not a way of being lazy." Anyway, "The email from God", I think we've all gotten those, and we all know what that's like. And so, to all of you "God emailers" out there, please be sparing, and keep in mind what happens when you send those.

You've got a couple of other books. One of them is the Software Architecture: Visual Lecture Notes book. I was wondering if you could talk a little bit about what that book is about, and where it came from?

Cesare: Okay, so the Software Architecture: Visual Lecture Notes book is the one that basically was born thanks to the lockdown. Because I wanted to write a book about - I teach software architecture - since now, for more than a decade - and it's probably about time that I wrote down everything that I tell my students. And I had an opportunity to do it, because I recorded all my lectures last year. And then over the summer, I spent time transcribing and editing the text.

So basically, it's literally visual lecture notes. Because you will see all of the slides that I use in the lecture. And also, underneath - basically what I'm saying when I present those slides. And it turns out that people - it's almost 700 pages. So you have a whole university lecture on the topic, so it's very big. It should be taken in small doses, right? We cover the content usually in 14 weeks. And basically now I'm using it this year as a textbook with my students, and I also heard that it's been adopted at the University of Delft, and also the new institute that they have in Schaffhausen in Switzerland - also they have new lectures on architecture that will be based on this book.

Len: Oh, and on the ebook?

Cesare: Yes.

Len: Okay, that's really interesting. It's a really great book. I didn't know, actually that - that's fascinating that it's origin is from recorded lectures, as a result of the pandemic.

Cesare: Well, I wish I could say that - when I give my lecture, I say such coherent sentences. But of course - the editing cycle, and probably can also be further edited. But that's the beauty of Leanpub, right? I wasn't sure whether people would be interested to read such a book. And then I got a very good confirmation that this is indeed a valuable topic. So it's really great that I cannot just share this with my students, but now I can share with students of software architecture all over the world.

Len: I was wondering if you could take a moment just to talk a little bit about what software architecture is, to those who might be new to software and programming, and might not be aware of what architecture is in the software space?

Cesare: So, software architecture is a relatively new discipline within software engineering. And you can already see in these names, that both engineering and architecture are terms that - in Computer Science, we borrow from other disciplines, and we bring in and apply it to software.

What do software architects do? There are two different interpretations. There is the ivory tower model, in which - in a large organization, you have a dedicated group of architects that dictate and standardize and promote and try to steer what the rest of the developers are doing. They make the so-called, "big design" upfront. And then the rest are supposed to implement it somehow.

There is - of course, how do you say? This doesn't get a really good reputation in terms of the software architecture. You might hear things like, "Architects are developers who no longer know how to write code." But in reality, every developer is an architect. Because everybody that writes code is actually making decisions. And these decisions are going to affect the quality of the resulting system. So this is something that even if you just limit yourself to writing code - every line that you write behind it has assumptions, has decisions, and most important, has a reason why you decide to write the code in that way.

Unfortunately, when you write the code, you don't have actually a place to document the reason. And other people that read the code might not be so smart to understand what you were thinking when you wrote that code. And so, over time - the code stays there, the developers come and go - and the knowledge, and the architectural knowledge behind that code is lost. So the idea of promoting this type of practice helps people to reason about what they're doing.

We also say that, "One hour or architecting can save you a couple of months of coding." Because you make decisions beforehand. And then when you're sure about what you want to do, you actually go and implement.

Len: I was wondering if we could maybe talk about software architecture in the context of microservices. Because it seems to me like that's a really - I mean, I mentioned before we started recording - I'm Leanpub's resident non-technical person, even though I deal with code all the time. So I often come at these things from the naive point of view. But I've had the experience myself of sort of leading a project where there were lots of microservices being used. And they got out of sync. And all of a sudden, something stops working. And this is a consequence, not only of not doing - getting the architecture right, but getting the processes right. Because the decisions that you make about how to handle all the little - I mean, I say "little" - all the services that you're using as part of your product or service - if you don't put them together in the right way, you can't handle them in the right way. And I think you talk about - is it BCA?

Cesare: In the book, or -?

Len: Oh, no, no. You have a talk on microservices about this, that I'm trying to tie in to talking about software architecture. I think I might be getting it -

Cesare: Ah. Okay, so basically - let me answer in two parts, so--

Len: Okay.

Cesare: Microservices is sort of one of the latest trends in software architecture. I think it's important that students are exposed to this, although it's still something very new.

So, there are many interpretations floating around on what you should and shouldn't do when you adopt this type of architectural style. And if you look at the book, I actually present a lot of ideas that are commonly associated with microservices, from a historical point of view.

We actually go over the development of microservices, starting from software components and component-based software engineering. That's actually a very old concept, the idea of building a modular architecture when you can break down into many different subcomponents, well, that's not something that has been invented a couple of years ago. This has been already part of Computer Science since a long time.

In the development that we make in the lecture to get to microservices, we associate the abstractions that have to do with architecture. For example, components. But also connectors, interfaces or services - and microservices. We also state these abstractions with the most relevant quality that they deliver, right? So, for example, if you adopt a component-based approach, you get modularity. Because you have different parts, and then you can decide which parts are you going to reuse?

But if you want to reuse them, you need interfaces. And interfaces give you an abstraction that separates the implementation of the component, with the way that you actually work with it. And that makes it easier to reuse it. But interfaces existed before microservices. Then we have interfaces, we need to connect them together. And there used to be something called the "shared database connector", where you basically have all the software divided up in nice different components. But then all the components end up communicated indirectly through the database.

The advantage is that you can have higher - an expert database administrator, is going to handle all the data storage problems. And the software that you write, will just use that. This is sort of a big no-no in microservice architecture,because the moment that all the software in your architecture depends on the single database, then the moment that you touch this database, then everybody is affected. So with microservices, it's important you split the database and, every microservice has their own local storage for the state.

Now when you do that, in our research we show that there are some important impacts on the reliability of your data. Because it's simple to back up a single database. You just stop everything, make a copy, make a safe backup, and then you can continue working. But if you partition your database - and every microservice has their own database - well, it's much more difficult to tell all the microservices, "Please stop whatever you're doing - we have to take a copy of the database. And we have to all do it at the same time." So that we can take something that is called a "consistent snapshot" of the data that you have spread out through your system.

What we have shown with this backup autonomy and consistency theorem, is that when you adopt microservice architecture, you can only have two. You can only back up and have autonomy, but then you lose consistency, because you will recover from the back up in an inconsistent state. Or if you try to take a consistent snapshot, you lose autonomy, which is the defining property of microservices, right? Every microservice is supposed to have an independent life cycle, and be able - for example - to make its own decision on when to back up it's own state. So that's something that - yeah, maybe I should add it to the book now?

Len: Yeah, no - I'll make sure to add a link to the YouTube talk, where you talk about it. And so, BAC is Backup Autonomy and Consistency. And you talk very clearly about how you can get two of three. It's one of those kinds of situations. I just found it really interesting. The issue of timing, right? So when you're doing your backup, for example. I mean, I'm just sort of interpreting a little bit about what you said. But like, if you're going to do your back up of your - you've got all these microservices all working together at a particular point in time. When you do the backup, you have to tell - if you want to achieve - I think it's, if you want to achieve consistency, you have to tell all the microservices, "Stop updating yourselves, I'm backing you up now."

Cesare: Yes.

Len: But then you lose the autonomy of the microservice just working on its own. Because now you're giving it an instruction.

Cesare: Yes. You're giving instruction to all of them together. So they sort of stop for -during the backup, they stop being actually these multiple independent entities, and they become a single thing that's no longer a microservice architecture during that time.

Len: Conceptually, it's just so fascinating. And you talk also about eventual inconsistency.?

Cesare: That is what basically happens, right? Before disaster strikes, everything is fine. Because even though the backup is not consistent, you still haven't lost the data. But a lot of people discover these things only after they recover, right? They say, "Well, we have backups." So they just restart everything from the backups. And then, that's when there are some gaps, right? Things at the time - you were taking the backup, they were still in flight and they didn't make it into the snapshot, and then you lost them.

Len: I was wondering also if you could talk a little bit about hypermedia, and what that is?

Cesare: Well, hypermedia is one of the designing principles - fundamental principles of the web. Or in general, hypertextual type of system, right? This is something which allows you to build decentralized architecture. Because you don't have to - knowing the trends, everything that there is - all the elements that you have. But you can just start from one side and follow links and traverse the system, and incrementally grow the knowledge that you have about the system. So this helps you to scale an architecture, make it really, really big.

Because thanks to hypermedia, you don't need a central place in which to store the list of everything that is part of the system. You just have to be able to make sure that there are enough links, so that you can find various pieces. It's also used when you have - what we call "conversations." Or multi-message exchanges. A little bit like when you do an email conversation. In this case, hypermedia helps you. Because it's a very nice way to split the responsibility of who is responsible for deciding where the conversation should go.

So to be more concrete - you asked me a question, I gave you an answer that contains a certain number of links - and I tell you, "These are the options. This is where you can go." And then, when you receive this answer, it's your decision which link will you want to follow. So as a service, I can influence your decision by telling you, "These are links that I think will be interesting for you." But then it's the ultimate responsibility of who receives the links, to decide whether they want to follow one or more - or maybe even stop when they don't have to go on any longer.

Len: And the latest book that you've published on Leanpub is Beautiful APIs, which is some visualizations of APIs. I was wondering if you could talk a little bit about that book, what the origin was of that idea?

Cesare: Well, the origin was a part of this research project that we have, in collaboration with University of Vienna, and also Eastern Switzerland University of Applied Sciences. So, we have a project that we have been working on APIs for many years. I mean, well, it was supposed to be a book - but it will be a book at some point. It's called Microservice API Patterns". And as part of this pattern research, we actually looked at many examples of APIs.

And finally, I was presenting some of these. It actually was in Vienna at Christmas time. I came up with the idea of taking out of the whole specification of an API - which is a huge amount of information, lots of details. I was trying to look for something essential. And in case of web-based APIs, there's a book about http based APIs. There used to be a point in time in which people actually took advantage of the expressiveness of the http protocol, and they would describe APIs as being a set of resources, a set of links, right? That you can use with hypermedia by the way.

And then you can ask, say to each of these links - what kind of methods, what kind of operations you can perform on that? For example, you can use that, and then you can read something out of the API, or you can just put and you can write something and put it - you can delete and you can make part of the API. You can clean it up. You can make things disappear. So the visualization is basically on the concept of a tree. But it's a tree that is like a Christmas tree. So it has a little hanging circle of - how do you say, it's - ball?

Len: A bulb?

Cesare: Yeah, these bulbs.

Len: Maybe a bulb, yeah.

Cesare: And these bulbs represent the methods that are also sitting with the resources, and you find the resources traversing a path on the tree. So it's kind of - of course, an abstract visualization - APIs are much more complicated. But this is already enough to spot lots of interesting patterns, and things that people do quite commonly when they design such APIs.

We have collected almost 100 different examples. And there's more where they come from. Because they're actually a real-world API. They're APIs that we find on open source repositories. And people leave the descriptions there, so we can extract the visualization from the API description. And we show - you can imagine, it's a little bit like going to an artistic exhibition. You enter the first room, you see a very simple tree. And then the tree gets more and more complicated. And then we also have the final part, which is a bit darker. Because we also show things that should be, maybe better left unseen. But sometimes, you also want to see designs that are a bit unusual. Let's put it that way.

Len: It's really interesting, just to flick through seeing these structures of all these different APIs. And so they were generated using an app of some kind?

Cesare: That goes back to our research. We are building visualization tools. We have tools to visualize APIs in 2D, in 3D. We literally take the notion of API landscape, when you have actually lots of APIs that you have to manage. And then since the APIs are visualized as trees, we talk about the API forest as a visualization, where you can move around and you can spot similar APIs or outliers, APIs that stand out - because they're designing it in a particular way. So, we try to make it easy for people to spot them and compare them with other ones.

So yes, the book - you can sort of say, "Maybe I have to share some of the royalties with the algorithm that I wrote?" But since I wrote it myself, it's okay. But it's a visual book, so don't expect to - the Software Architecture book is full of text. This one is just illustrated. But it's also complementary. Because in the Software Architecture book, there is one chapter on interface and API design. And this other book shows you lots of examples that go with it.

Len: And just before we move onto the last part of the interview, where you talk about your experience writing Leanpub books, I was wondering if you could talk a little bit about the connection between your work and blockchain, that you mentioned earlier?

Cesare: Well, blockchain - you can see it as a special kind of software connector that you could use in your architecture. For example, when you run out of a place to put a database that everybody can access, then you can partition and replicate the database everywhere. And so you'll have this trust emerging of the copies that everybody's keeping and everybody's continuously validating. Also, wasting a lot of energy in the process. And, yes - part of the research project, we're trying to see how they use this to program business processes.

One problem with all business processes is that if they run inside your company, then you should have a place where you can keep track of them. But when the processes involve multiple organizations, and these organizations don't trust each other, then the blockchain could be a solution, to have a place to keep track of the process that is, at the same time, in the middle. So it's in a common place, but it's also spread out, so that everybody keeps track of their own copy.

Len: Oh that's really interesting. Just moving onto the last part of the interview. So, you showed up on Leanpub a little while ago. I was wondering if you could talk a little bit about how you - if you remember, how you found out about us, and what convinced you to give Leanpub a try?

Cesare: It's been a very long time. I think I was sort of waiting for Leanpub to happen. And because we, we actually - it was not directly, no - but there was a project, a European project we researched on something called - not Leanpub, but it was called, at the time, "Liquidpub." It was managed by a good friend - at that time, used to be at the University of Trento, ‪Fabio Casati‬. ‬

The idea was to study the impact of the web on scientific publishing. And there was this idea of saying, "Well, we have liquid scientific paper, we have a liquid book." And the idea is that, of course - you can print it, but you can keep updating it. And of course, you can also make it available before it's finished, right? And that's also what we do when we have scientific publications. We write the first draft - we submit it, we get reviews, we iterate. And then eventually it gets frozen and handed off to the publisher.

So what if this process would never stop, right? What if you could start with a small paper and keep working on it forever. During the full dissertation, you can keep track of all the stages that you go through. And you have a chance to make explicit the feedback that you get, and people can see the history. At the moment this is sort of a hidden process, and it's also a frozen process. We call those "classical books" or "solid books." Because once you print them, then you cannot easily change them.

And that was sort of what I really liked about Leanpub. The fact that if there is a mistake - you can fix it instantly, basically. There is no delay between the time that you're writing the book and when you click publish. It's there and you can keep evolving it. And the people that buy it, they get updates for free. So it's a beautiful design solution to make it possible for people - not just to take the book as a snapshot in one point in time, but to keep iterating over it.

Some people are a bit skeptical of buying books that are not complete. So, and I said - I asked myself, "Do I really want to do it?" But also in the past, many successful writers would actually publish books in instalments. You don't publish them as a book, you publish them as part of magazines. And every month you have to write the next chapter. Some would actually split the book and publish it like this, after the book was finished. But others would actually start writing the first chapter - getting the reaction from the audience, and then seeing whether it's worth continuing to write the story, and develop the characters for a couple more chapters. And maybe when the time, they started writing - they didn't have a clear idea where they wanted to go and how the story would end. So this model is also what makes Leanpub special.

The other one - the other nice feature is the fact that you don't have DRMs, right? I'm very skeptical about this type of technology. It also aligns with what I believe in. And so, based on the experience that I had with other publisher - basically it's super fast, right? You have some other books that are classical books in print, and it took a very long time between the moment that we said as author, "The book is done." And when the book will actually, published. So Leanpub is really fast.

Len: Thank you very much for sharing all that, I hadn't heard of "Liquidpub" before. But I'm looking at the liquidpub.org website - from, I assume, quite some time ago now, and it's really interesting. I mean, the subject of scientific publication could be the subject of an entire podcast. Not just one episode, but an entire podcast - and I'm sure is out there. But it's a particularly fraught space, partly because of the cost of some of the big-name publications, has become a bit of a controversy in the last few years.

But also because, often people who are doing scientific publications are academics, and are looking for tenure and promotion and accolades - and things like that. And so, how you publish can be really important, and then - it's only kind of people who are - at least for part of their work, operating on bit of the fringes - who will do experimentation. But often until you get to the point in your career where you're secure, you have to be as sort of like - as conventional as everybody else is, in order to get ahead. And so the experimenting isn't something that - from what I understand - isn't something that you necessarily do, for most of what you do at the beginning of your career.

Cesare: Yes, no - that's correct. Yes. That's exactly the way it is. Yes.

Len: Anyway, we could - but we'll leave that for another time. Thank you for sharing all that, and - yeah, I guess - and I'll try include links to all the things we've talked about in the episode in the transcription. For anyone listening, you can find it on our website.

The last question I always like to ask everyone who's a guest of the podcast, who's also a Leanpub author, is - and you've been around for a while - so, if there's one thing we could fix for you on Leanpub, that really bugs you - or one thing we could build for you that you would really wish we had, is there anything you can think of that you would ask us to do?

Cesare: Well, it's hard to say, because I have been following all your iterations - and every time it gets better. And you can see that it's built by people that care about what they do. Because they are really careful about the author experience, especially if you compare it to other publishers - the way the website works, it's spectacular.

Len: Oh, thank you.

Cesare: Maybe one tiny little thing. It's great. What is great about Leanpub, that I didn't mention - is also the fact that you can set a limit on the price, but then people can also increase - there is sort of a range. So it's interesting, because it's -one of the most difficult decisions is, of course, how to set the price of the book.

But the second, I think, important decision is also how to design the cover of the book. And there are, of course, professional graphics designers that can do that. But since on Leanpub you just have to put some kind of an image that represents the virtual cover, it could be interesting to support some kind of A/B testing, where you could, for example, put various versions of the cover. And then, for example, see which one seems to attract the people attention. At the moment you have to sort of do it yourself, right? You start, try out - and then maybe you have to change.

Len: Yeah.

Cesare: Maybe the platform could actually make it a bit more easy.

Len: Yeah. Thanks very much for that suggestion, that's really interesting. That's something that actually, it's - we thought about that a long time ago. Currently, anyone who's familiar with Leanpub will know that, if you sort of don't do anything, then we do a sort of black and white cover page, which is the title, the subtitle and your name. Which isn't really much of an cover at all, and there's definitely more we could do on that.

When it comes to A/B testing book covers, one of the interesting challenges is that, since, as you say, the "virtual cover" or image - is tied to a particular product, iterating on the image - ff you have multiple images associated with the same product people can get confused.

They're like, "Oh I thought I bought this one, but then I bought that one." And so that's actually - of course, people in this kind of space are like, "Let's A/B test. Let's A/B test. Let’s A/B test." But if you're A/B testing cover images for an actual product that's available, people might buy it and then go, "Hey, I thought I bought this, but I meant to buy that - because I'm seeing a different cover.'' And so for example, if someone - if you're iterating on covers and someone buys the one cover, in their Leanpub library, do they see that cover forever? Or can you change it?

Now currently - if you update your cover, you update your cover, and it's updated in their library. But, do we then - if an author has been iterating with like 50 different book covers, are somehow doing some kind of temporal management of 50 different covers?

Cesare: I realized that's probably why you're not doing it already,there might be a good reason for that, yeah.

Len: We could think it through and come up with a solution. But that is an inherent difficulty, if we ever do offer something like that. But definitely - whether or not there's A/B testing or something like that, the idea of us actually offering authors options other than the black and white default cover - maybe something that just looks nicer, or does some kind of algorithmic thing with some design, or something like that - to give someone a unique pattern in the background or something like that, is definitely something we could really help with. Because people do judge a book by its cover.

Cesare: Yes, that is a fact. And I agree with you that the cover has a strong identity factor. So once you get used to that cover, seeing it change is - it makes you wonder about what happened to the rest of the book.

Len: Yeah, and this is very - this is why we leave this part of the interview for the end, because it's very much in the weeds. But Leanpub is a platform for self-publishing in-progress books, right? And so, even if you're a university professor - people might be like, "Wait a minute." Like, I mean - I've got to have a lot of confidence in you to pay some money for a book that's unfinished, that you're publishing yourself. And so, in that context, having a really good cover really goes a long way to communicating to people that you're serious about what you're doing. You're good at it, and you've thought it though - and yeah, you're committed to it.

So it's particularly important in our case, for Leanpub authors to try and put in the work to have a good cover. And it's definitely something we could do a lot more to help with.

Well, thank you very much for taking the time out of what I'm sure is a beautiful evening in the mountains in Switzerland, to talk to us here today on the podcast. And thank you very much for being a Leanpub author.

Cesare: Thank you very much, Len. It was great to meet you, and I looking forward to more books published with you.

And as always, thanks to 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 be a Leanpub author, please visit our website at leanpub.com.