A Leanpub Frontmatter Podcast Interview with Viktor Farcic, Author of the DevOps Toolkit Series

Viktor Farcic is the author of the DevOps Toolkit series. In this interview, Leanpub co-founder Len Epp talks with Viktor about his background, the nature and importance of failure in software development, self-healing and self-adapting systems, the future of automation, his books, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on December 18, 2017.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.

A Note About the Leanpub Frontmatter Podcast

Frontmatter is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk. Please subscribe in iTunes and follow us on Twitter to keep up with the latest episodes.

** Len:** Hi, I’m Len Epp from Leanpub, and in this Leanpub Frontmatter podcast I’ll be interviewing Viktor Farcic.

Based in Barcelona, Viktor is a writer and popular conference speaker, and senior consultant at CloudBees, which provides companies with enterprise solutions for automating software development and delivery.

Viktor is the author of four Leanpub books in his DevOps Toolkit series, including his first, The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices, and his latest, The DevOps 2.3 Toolkit: Kubernetes.

You can follow Viktor on Twitter @vfarcic and you can read his blog at technologyconversations.com.

In this interview, we’re going to talk about Viktor’s background and career, professional interests, his books, and at the end we’ll talk a little bit about his interesting experience with self-publishing.

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

Viktor: You’re welcome.

** 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 software?

Viktor: I grew up in Belgrade, in Serbia. My interest in software was out of desperation, I think, because my mom, when I was maybe eight or something like that, bought me a brand new Amstrad computer. Actually, most people don’t know what it is. It came without games, without anything. Just a computer, and a book in German, which I did not speak. So the only thing I could do is just, you know, open the book, type the same commands without understanding what they do, and then try to figure out what that all means. So a lack of games made me a programmer, I think.

** Len:** And when you were growing up, Serbia wasn’t Serbia was it?

Viktor: Oh no, it was Yugoslavia. Yes, it was a bigger country.

** Len:** So that was a turbulent time politically growing up.

Viktor: Oh yeah, I mean no — politically not that much growing up. But then I’m an old guy, so at that time no, but then when the nineties came, then all hell broke loose and things went downward from there, I guess.

** Len:** And that was around the time you were attending university at the University of Belgrade, which I found from LinkedIn.

Viktor: Yeah. I was studying back then, computers at first, then I switched to archaeology as a way to run away from computers. And then they pulled me back in. They figured out they need software for archaeology as well.

** Len:** And what was it that drew you away from computers? I guess having started so early, was that something that other kids that you knew, like on your block, were also playing around with?

Viktor: So as I said, I started at the beginning — because that was the only thing I could do on my brand new shiny computer, just kind of copy and paste. Not copy and paste, read and write the same thing from a book. And then, a lot of time passed, so I can speak about those things. Then I kind of started cracking software, and piracy.

Len: Oh really, in the early days?

Viktor: Yes, so at the end of the eightiess, I was kind of trying to figure out buying games, cracking them, trying to figure out how to put them on tapes without protection and stuff like that. It was really interesting. And then after that, I started doing some gigs for different companies. And by the time university came I was already, I don’t know? Like over 10 years in doing stuff with computers, and I was a bit sick of it.

And archaeology sounds like as far as you can get from computers. And it’s kind of cool. Sexy, Indiana Jones, kind of. Who doesn’t like Indiana Jones, right?

** Len:** So it was sort of ancient Middle Eastern archaeology that you were drawn to, or?

Viktor: No, I was mostly prehistoric. Palaeolithic, Neolithic. Like, I don’t know, 4,000 years ago give or take. Something like that.

** Len:** That’s curious. That’s the kind of archaeology my dad was into in his archaeology days, the Great Plains of North America in that time span, so a lot of trying to figure out what the buffalo were up to in connection with the humans and things like that.

Viktor: Exactly, something like that. In my case, it was mostly in caves, spending my summer there.

** Len:** It’s interesting, in the 80s, if you were trying to crack game codes and things like that — perhaps younger listeners might not know that in those days you couldn’t really just go online and grab tools from all over the place. You had to be resourceful in a different way.

Viktor: Oh yeah.

** Len:** Was there a community that you were a part of? Or was it very independent?

Viktor: No, not really because, not only that that’s before internet, that’s before BSDs, so before modem connections to somebody and stuff like that. It was a nightmare.

I don’t remember exactly what I was doing at that time, but I remember that it was a lot of assembler kind of things. Before C came into being. Like, look at the binary and try to find something that looks like the thing you might want to change. People would laugh if I would suggest something like that — go through binary code to assembler and try to figure out what’s going on. I think that they would put me in a loony bin.

** Len:** So you tried out archaeology and you ended up back in computer science. There’s a question that I like to ask people on this podcast, which is: If you were starting over now, if you were university age, or if you were giving advice to someone like you who’s about starting university age, would you do a computer science degree formally at a university in 2017?

Viktor: I’m not really sure whether I would do a university degree. Let’s put it this way. It definitely makes much more sense to do a university degree today than it was back then. I think that back then it was usually mathematicians that spent a week of training in some computer science, and they would teach you.

Really, it was almost a joke back then. But now it’s much better. Now how good it is, I’m not really sure still. I do believe that what you do need to learn — I mean, learning is an ongoing process throughout your whole career, right? I still think that until you start working on real projects in a real company for a real customer, you have no idea. No matter how much time you spend in university. I might be radical in that opinion, I guess?

** Len:** I’ve actually heard that in a number of areas from the other side, actually. Where, for example, there will be people who think that the most practical thing they can study at university is business, and then they get out and the businesses that hire them realize they don’t understand anything about their role. And then the business has to sort of untrain what they’ve been poorly trained in, and then train them from the ground up in what they really do need to know.

It brings up a very interesting question of what university is for. Should universities be considered to be job training centers, or should they be something else? And even if they are to be job training centers, should that mean that they would be following the instructions of companies now, for people who are going to be graduating in half a decade?

Viktor: Yeah, I’m not sure. I cannot do a negative opinion about universities. I mean, I guess it all depends on also what one is studying. Because there are certain things that you study and they don’t really drastically change from one week to another.

So archaeology, of course. I think that everybody who wants to be an archaeologist, you should go to university. No doubt about that. But software, to be honest, I wouldn’t trust in the ability of a professor to teach me software if he’s a full-time professor. Because things are changing so fast, you cannot catch up without really working in a real environment — and not only in any company, but some company that is cutting-edge.

If this makes sense, I think that universities should have professors that work only one day a week, and the rest of their career, they spend solving real problems, so they can actually transmit those solutions and the advancements in technology to others. I mean, it’s so difficult to be a software engineer these days, that I think that whatever you knew last year is not valid anymore. That’s how fast it changes.

** Len:** So things like the information science, and what a Turing machine is, are things that maybe a full time professor could teach, but when it comes to what you’re actually going to be doing and adapting to, what you’ll actually be coding, that’s something else.

Viktor: Exactly. Of course there is a base that you need to know — algorithms, Turing machine, all those things, without a doubt. And then the rest is ever-changing.

** Len:** I’ll have some questions about that a little bit later on. Before we go on to talk about your books and devops, I wanted to ask you — one of the pleasures of doing this podcast is I get to talk to people from all around the world — some on the west coast of North America where I am, but some in Europe where you are, in Spain; I’ve interviewed people there before, and I wanted to ask you, one of the questions I get to ask people is — what’s the start-up scene like where you are?

Viktor: It’s improving greatly. I think that, at least in Barcelona, only maybe like the last five years we are starting to get something that resembles a good start-up scene. But I think there’s a big problem between most of Europe — not all, but most of Europe — and the US is that the moving around start-ups is quite different. The way how people invest in the US, investors are more used to the fact that there is a huge risk, that you need to invest in ten start-ups for one of them to actually be any successful.

In Europe I think that we still have that cultural, “I want to invest in something that is most likely going to work.” And you cannot really know with start-ups. I mean, most of them fail, and then some of them succeed. And if you’re lucky, you’re going to be investing in a successful one. But you need to invest in many, not in one.

** Len:** I was just going to say, we’re actually based in Canada, so I’m familiar with the situation of watching all the investment news coming from the United States and being in a place where people are more cautious and don’t have pockets quite as deep. It’s a very broad generalization, but generally speaking if you had a kind of archetypal Canadian investor it would be someone who invests in commodities. And those are people who are — they might be ambitious but they’re not risk-takers, let’s just put it that way. So yeah, I’m familiar with watching it be different somewhere else, and a little bit slower and more constrained where you are.

Viktor: Exactly. I think that Europe is very similar to what you described just now, yes.

** Len:** And what’s it like Serbia?

Viktor: I don’t know. I don’t go there much. I kind of completely switched from both a family perspective and a living perspective, I switched completely to Barcelona. I think I consider myself being Catalan more than Serbian now.

** Len:** And did you move right after university, or did you spend a few years…?

Viktor: No, actually, it’s more complicated. I moved there before I finished university, while I was still studying archaeology. I went to Barcelona to give some lectures at their university, about computers in archaeology and stuff like that. And I just loved the town so much that I went back home, because my suitcase was too small — I packed a bigger one, and moved without any plan, without anything — I just thought, “I need to live in this city.” And I’m still there.

** Len:** And in the mid 90s, could you just move and work? Or did you have to get special work visas and become a citizen, things like that?

Viktor: Yes, I had to get the visa and things like that. But one thing that living in Serbia makes you, compared to most other countries, is very resourceful — to look out of the box, because of everything that happened, everybody including me was used to kind of, “Okay. The normal way doesn’t work, then let’s go this way or that way. And then we’ll figure out stuff.”

** Len:** So you’re living in an interesting part of the world right now.

Viktor: Yes. I really don’t know what will happen where I am a week from now, but we’ll see.

** Len:** For those who might not be aware, there’s an independence movement in Spain, and there’s been a lot of news around that.

From an outsider’s perspective, another big issue in Spain has been unemployment in the last 10 years or so. I wanted to ask you — I know this isn’t about your books or anything like that, but has that sort of — at least in North American news, [in the past] the news about Spain was big marches in the streets. And similar to the past news about Greece, all of a sudden you don’t hear about it anymore, in the headlines in the North American news. I was wondering if you could talk a little bit about that. Have things been improving?

Viktor: There was a big crisis everywhere. Starting from US — what was it, like 15 years ago something like that? Anyway, the Spanish economy collapsed. And that’s mostly because it was based on tourism and real estate, the big portion of the economy. And those are the two things that are gone first, the first to disappear when there is a global crisis.

So when Spain really went down drastically — not as far as Greece and Portugal, but probably close to that, and I think it’s still kind of like — I’m not really following much, but I think it’s still around over 20% unemployment. It’s definitely better than during the crisis, but it’s still not great. At least not at the level as it was before the crisis.

And I think that that’s part of the reason why for all this, for the independence desire. The moral of the situation is, the more nationalism rises, and more people kind of stop questioning things, and they’re wanting to change things one way or another. But if the people live great, then they don’t care about things. They start caring about things mostly when things are not so great anymore.

** Len:** And in particular, youth unemployment is high, I understand?

Viktor: Yes.

** Len:** And so you’ve got a lot of young people thinking with their whole lives ahead of them, and a lot of energy, and maybe a desire for change that older people who are more settled into their lives might not have.

Viktor: I mean, it’s impossible. At least Spain is close to impossible for a young person to buy apartment. I mean, it’s really hard even to rent. Many young people live with their parents. And quite a few Spaniards went to the UK, maybe Ireland, or something like that. Especially in IT. It’s not a bad situation. It all depends what you compare it with. I lived in Serbia, so this is not even near to what was going on there. But it’s different — not a strong economy in Europe right now.

** Len:** And so you moved to Spain, and you graduated-?

Viktor: No. I just moved to Spain and dropped everything. I literally was like, “I’m moving to Spain.” I think I took a couple of exams to finish for the university. I just dropped it all altogether, just for Spain.

** Len:** And then what did you do?

Viktor: I started programming almost immediately. I mean, I continued programming. I got employment in one company, then another, and stuff like that. I maybe, at that time, was doubting whether to finish university or not, and stuff like that. But then I realized that after you have years of experience, then university’s becoming irrelevant.

Nobody asks you about your degree, I think, when you’re experienced. A degree is important when you say, “I know nothing.” But then one person who knows nothing with a degree and the other one knows nothing without a degree — and then of course you’re going to pick the one with the degree. But I really, since I started coding very, very young I had years of experience working with companies, projects — stuff like that. So I thought to drop it altogether and do my job.

** Len:** And one of the themes that you write about in your books is failure.

Viktor: Yes.

** Len:** And this is woven into — there are a number of other themes that I’ve noticed in your writing, including adapting to change, which is related to failure. Can you maybe tell the story of what was your first big experience with a failure? Whether it was your responsibility or not.

Viktor: I think that most of the projects — I mean, dependsit . When I worked for smaller projects, like a freelancer, that was usually fine. Me only, or a couple of a guys. So that’s usually not the problem. But I think that almost every bigger project that I worked with for a bigger company, I don’t think that there was hardly a case where the project was not a failure. With all the ways of doing things, and Waterfall and stuff like that, we invented so many ways to mask failure as a success. It’s delayed for half a year, but that’s a success, because of this and that.

Most Waterfall projects I did were a failure. Almost every project, I think, that lasted for more than months, that’s a failure by definition. Because you assume that you know what’s going to happen in the future. And that’s just the wrong assumption. You assume that you know everything in advance, and then you plan the project, and then it’s a success or a failure.

But since you’re planning based on unknowns, you’re guessing, you’re inventing things. So either you put the huge margin on what you’re doing saying, “Okay, realistically this should probably take three months. But we’re going to say that it’s going to take eight months, and then it’s going to be a success.” But then nobody would accept a project like that, so you never plan it with such a big margin. It’s always a failure.

So the answer to your question is, every bigger project I’ve worked on is a failure. That’s how it is.

** Len:** Is that how it is, or is that how it was?

Viktor: It’s how it was, I think. Because in the meantime since then, Agile was adopted. We learned that short iterations are — that we should plan a week in advance, maybe weeks in advance. That we should deliver in small iterations, learn from the mistakes, and things like this. And I think the software industry is still full of failures. But those failures are based on very small steps. So if I make a step, another, and make another step, and I stumble, and then I continue — so it’s not really a failure anymore on a grand, big scheme of things. It’s just small hiccups. And when the steps are very small, then you never really hurt yourself when you fail.

** Len:** One of the interesting things about reading the introductions, particularly, to your books, is you do talk about how things have changed over time, in more detail than we can in a conversation like this. But seeing that personal perspective on going from projects based on a Waterfall model, ultimately to continuous deployment methods, is just a really interesting story to see.

Actually, on the subject of things that are very small, I found a quote from you on Twitter — I think relatively recently — from a talk you gave at DevOpsCon, where you say, “We can think of the whole computer system like a human body that consists of cells of various types.” I like that metaphor, and I was wondering if you could talk a little bit about what you mean by that?

Viktor: It’s kind of looking at humans’ bodies as inspiration for how to build systems. Now, traditionally we were taught to build big monolithic systems. And if you would compare that with life, that would be — imagine that you are now, for example, you’re a single cell organism. What happens when you damaged? You cease to exist. You’re dead. You’re no more. You have a single point of failure.

And the reason why we are so successful as organisms is because there is no — I mean, it’s not that there is no single point of failure — give me a gun, I can do that. But in most cases, we are composed of so many small elements, cells, that the extraction of one of them or even a huge number of them is still not affecting significantly how we work.

And on top of that, if things are small — it doesn’t matter if it’s cells, or services — they can be easily built, recreated, multiplied, and all those things that are happening in ourselves.

I think that the way how life is organized — I think that that’s the direction where we are going with microservices, immutable deployments, containers. I’m not sure whether I’m inventing an analogy or finding an analogy there, but to me the systems we are building are more and more resembling how life operates.

** Len:** I’ve got a couple of questions about that and probably a couple of things to clarify for the audience about microservices and devops, and things like that. But before we do that, a couple of things you said reminded me about a distinction you make — I think it’s in the preface to DevOps 2.0 Toolkit book — about the difference between being a programmer and being a software craftsman. What is that? What is that distinction?

Viktor: Many of us are working at companies where we are software programmers, where we are told how to do one certain thing — and probably do it very well. And then that knowledge, those skills are exploited to infinity. And when I say exploited, I don’t mean [?] … but more in a way — you become so good at something that you’re utilized to do exactly that thing and nothing else over, and over, and over again.

And then the problem with that — becoming really expert in one thing and doing that thing over and over again — is that you can very quickly lose your value in the market. You’re an expert, I don’t know, a Java 7 developer or whatever? And then the technology changes so fast, that if you stop learning, you could just continue exploiting that [expertise], and then you have no value outside of your company. And that means that you are going to become one of those traditionalists that they’re trying to convince everybody to stick with whatever you know and stuff like that.

I like the software craftsman movement because the name, it resembles kind of craftsmanship when we are continuously learning from elders, or from other people, not necessarily better than us, but continuously trying to learn and improve. And at the same time, I think that we are becoming less and less specialized.

So of course, everybody will have different specialty and all those things. But I think that we as an industry are getting hungry for people who can understand the system as a whole. So even though you’re a programmer, you still need to know just enough about databases. You need to know how your software is deployed. You need to know how it’s tested. You need to know all those things.

Because if you don’t, then whatever is your specialty, whatever you’re doing, is going to be done badly. Because it’s not going to take in account all those other aspects of software development life cycle.

** Len:** This is I think a good moment for me to ask you to give maybe a couple minutes explanation of what devops is, to people listening who might not know, or who might think they do, and don’t.

Viktor: I need to start with an explanation of, what is Agile? I need to assume that probably they might not know that either.

So, if Agile was about breaking the silence and creating themes that are capable of developing software with full autonomy, and with very small iterations and so on an so forth — basically it’s removing lead time. It’s removing administrative hurdles, going from one department to another and stuff like that.

So with Agile, we got apart from sort iterations and a few other things, we got small themes that are capable to develop software autonomously. And now what happened is that when Agile was invented, it was a different world. The skill set that is required to be autonomous changed drastically.

So traditionally, with Agile that would be a tester — testers, developers, business owners — more or less that’s everything you need. And then once you’ve finished developing, you send it to sysadmins, operators, other teams who are going to maintain it.

I think that devops is about putting all those people who were coming after those themes into those same themes and extending the scope of what those themes can do. And the scope is, “We are a single team. We are six to eight people, and we can do everything from beginning to the end, including deployment of production monitoring, responding to PagerDuty, and all those things.”

I think it’s the evolution of Agile. But the difference is that, I think that every once in a while — at least in software industry, whenever something good comes along, in time that something gets polluted and then perverted. And then we need to change the name. Instead of saying, “This is the evolution of this thing.” Then we change the name and say, “This is now devops,” right? I truly think it’s just evolution of what Agile started.

** Len:** From a very high level, it used to be that you’d have some programmers developing software, and then they would hand it off to other people whose job was to put it on the servers, and actually give it to people to use.

Viktor: Exactly.

** Len:** And then what happened over time was the idea developed that these two activities shouldn’t necessarily be treated as discreet, but rather as strongly related to each other, and integrated with each other. And in particular, as I understand it — one of the pressures in that direction was that deployment started happening more quickly, and in smaller steps — as you were talking about before.

And so, if you can change something in your code, and then have it live in a few minutes, that connection between how it’s written and how it’s deployed, and then how it’s going to be served up to people, needs to be much more tightly connected.

Viktor: Exactly. If you go back in time when, how we were developing software before, a typical project would be like half a year, a year. And then we have different things that need to be done, like developing, testing, deployment and things like that. And each of those activates would last for weeks or months. And in between those activities, we would hand over — what do you call it? — throwing over the wall, and say, “Okay, now it’s your turn to spend two months on this.”

And if I’m waiting for your feedback for a while, it does not really matter in the big scheme of things, because the whole project is a whole year. So if I’m going to wait for something for a month, it’s not really the end of the world. But now, the speed of deployment is such that I’m expected to deliver a new feature within a day. We just agree, “Oh, we want to do this. Excellent. It’s going to be in production today.” Or tomorrow, maybe, or a week from a now.

So there is no time to lose. Even to lose a single day in waiting for somebody else to do something else because whatever you’re requesting that person to do, he has some other queued items and all those things. So instead of having small horizontal themes where each theme is [assigned] a certain activity, like this team is a test -

** Len:** This might be a good moment for me to ask you to also talk a little bit about what microservices are.

Viktor: Sure. So microservices — imagine that you have a system that does many things. Let’s say the Amazon website. Then microservices would be, instead of having one big monolithic system, you would split it into smaller pieces and have a completely separate service that serves as a shopping cart. One would be a product catalog, and the third one would be log in and registration.

And then once that is split into small pieces, then you take care of smaller themes, working on each of them. So instead of having 200 people working on a single product, you have 20 teams of 10 people each, working on their own software or service.

** Len:** I imagine that makes some things much more efficient and easier to do, but it also means that all these things need to be connected to each other and work together.

Viktor: It makes it easier in the sense of autonomy. You don’t need to wait for somebody else to do something. You can just move at your own speed and deliver all of this to shopping carts as fast as you can, without thinking about what’s happening with the rest of the system. And then communication between those services, that is a challenge that we are solving now with containers, schedulers, and service discovery and things like that. I’m pretty sure that now I’m talking about things that don’t mean much.

** Len:** I think you know what you mean.

One very concrete thing that you write about is test driven development. How does this world where you’ve got things split up into these multiple teams or multiple services, how does testing change when you’re operating in an environment like that?

Viktor: So traditionally, what would happen is that we develop something, and then once that something is developed, we would run some tests to validate whether that something is correct. And in most cases, those [?] tests would be very long-term and manually executed, and when whenever you introduce a new change then you would need to run all those menu tests again.

And then we moved into having automated tests, because that speeds up the whole process. Because if something is repetitive, if it has the same feature over and over again, then automation really brings a lot of value. But the problem is that if you write automation after you wrote the code, two things will happen.

First, the automation is going to mimic the code because you’re already subjected. You already saw what the code does, and then most likely are going to create a test code automation that will mimic that — instead of having a clear mind kind of thing, ignoring what you know that’s already done.

And another problem with that, is that automation or testing done after the program is usually too late. Because, it would be the same thing as if we would create an assembly line for cars — and we would produce the cars and test whether they work or not. And if they don’t, then we’re going to start over. With testing and development, the process is somehow reversed.

Many of us, we write first tests that serve two purposes. One is obvious, to validate something that we are about to do. And another purpose is to define what should be done. So, by writing tests first, you’re defining what will be done next. It serves as a kind of requirement of what you’re going to develop.

And on top of all that now — coming to test-driven development. Test-driven development, apart from proposing, the tests are written before the code itself. Tests are written before the functionalities develop, trying to do that with very short iterations. So between writing, I would spend maybe a minute writing a test, and then a minute writing a code that makes those tests pass. Or, eventually creates a functionality. And then I would repeat the process over, and over, and over again.

So while 15 years ago, development lasted for months, and testing lasted for months after development, and then we would go back and forth to correct the problems, now the iterations [?] last minutes, instead of months. So everything’s just shorter.

** Len:** If you’ve got, say, a company with a culture that doesn’t already have a test-driven development procedure in place, is it difficult to convince people that you should do things that way?

Viktor: Very. Because, especially in cases of testing and development, it’s about change in the culture for the company. And the culture of a company is much, much harder to change, to update, to modify, than technology. Technology comes easy. And in case of test-driven development, it’s all about having a different approach, different processes, than changing a certain technology.

And people, especially old timers, if somebody’s used to doing in a certain way for 10 years, then telling that somebody that that’s not the right way to do things is very, very hard to accomplish. And on top of that, if somebody was atop test-driven development, that would mean that somebody will start questioning the value of, say, a testing department.

Because if I’m going to write my tests and then I’m going to write code behind those tests, or features, then why do we need the testing department? Which is also not true — we do need them, but probably not in that quantity as we needed them before. So it’s most about changing the culture and disrupting certain established departments, and maybe people’s security in their work, and a few other things.

** Len:** One thing you write about as well is self-healing systems. I was wondering if you could talk a little bit about that? Because I believe that it’s connected to the idea of automating things and doing things as quickly as you can, and then also having microservices — all these separate things working together at once, and testing.

Viktor: So actually there are two concepts — self-healing and self-adaptation. I think that they go back to my analogy with the human body.

In our own bodies, we are continuously being attacked by viruses, and things happen to us. Most of those things we don’t notice because our organisms self-heal. You get hurt, those cells will die and new cells will be created. And all those things are happening without us going to the doctor.

And then there is self-adaptation, meaning that if I’m running then the number of things happening in our body, and things created, and the state of my body need to change to accommodate that external influence and those external influences, or changing conditions.

I think that the same thing we’re trying to apply to software systems, so that, instead of [?] creating [?] when this thing happens, do that, we are trying to automate [?] — [?] humans can say[?] trying to create things. Like each one of us should go in the morning to an office, if you work in an office, and do something you didn’t do yesterday. And all those repetitive things like what happens when a server goes down. When a server goes down, then you follow this process. What happens when the service is unavailable? Then you pull that process. All those repetitive things can be easily given to machines to deal with it themselves.

And I think that that’s self-healing, trying to recuperate from failure in a fully automated way. And self-adaptation would be to increase or decrease the number of replicates of a service, or the number of servers running, depending on traffic. In the morning, for example, we might have relatively few users to our website, and we need relatively few servers to serve those users. And then in the afternoon, the number of users might jump up, and we need more servers. And all those things should be fully automated.

First of all, because automation is more reliable because it is repetitive in exactly the same way, it’s much faster, and generally does a better job than us. And that, at the same time, allows us to do more interesting things. Because who really wants to go to work every day and do exactly the same what you did yesterday? And do it in a way with the result that is much worse than if you let machines do that? I think that the next step in the evolution of what we do as programmers would probably go beyond that, and towards some kind of machine learning, and creating more intelligent systems capable of doing things without us.

** Len:** That’s interesting. You’re I imagine deliberately touching on the very controversial topic of automation. Generally, I’m sure they’re probably not listening to this podcast so much, but I’m sure there are a lot of people out there who would love to go to work every day and do the same thing again, and could care less if a machine would be better or worse than them at it.

Just to go sideways a little a bit, what’s your take on this idea that the machines are going to take all the work away from people?

Viktor: I don’t think that that will ever happen, from people in general. Because at least not in any foreseeable future, we are still more intelligent than machines. We have the capacity to be creative, to come up with new stuff. Machines are mostly very good at doing repetitive things. Today — I don’t know really what will happen 100 years from now, 50 years, but in any foreseeable future, machines are not going to replace people. What will happen is that machines are replacing people who have difficulty to change what they do. Like, for example, what will happen with taxi drivers when autonomous cars become a norm? It will be a huge problem, unless they can change the way how they operate their business. So if they just do exactly the same thing that they’re doing today, then they might be in real danger of being totally replaced.

I don’t think that we’re going to be replaced by machines, but what we do will, and is constantly changing. So as long as each one of us individually can adopt those changes, then we should be fine.

** Len:** You have a great line, a sort of bracing line in your latest book, where you write, “There is no alternative to a constant struggle to be competitive.” It’s interesting in this context. When people load up into their minds concerns about automation taking away jobs from people,they often treat the current status quo as something that was always the case. Whereas, of course, we all know there was a time when there was guys driving horses and buggies around.

And then that got replaced by the people driving the cars around. And everything has always been a constant struggle. But people often want to treat some position they’ve attained as the stable and natural state of affairs. And I do find it really interesting thatamongst the themes in your writing, there is this idea of constant change and constant adaptation. Is something that we always need to keep in mind in our careers and in the systems that we build.

Viktor: Exactly. What you said, I fully agree. Those changes were happening always throughout history. Like look at the industrial revolution. Everybody thought that they’re going to lose jobs, and nobody did.

But what is different, is that those changes in the past were happening from one generation to another. And now their frequency has increased so much, it’s happening within a single generation; you hear multiple drastic changes happening to us in how we work. So we cannot just rely on the — I can reach my pension as I am, but my children will need to adapt. Now, you need to adapt. I think that’s a difference maybe with the past.

** Len:** Another difference with the past too, you write in that book as well, the Kubernetes book, “Every company is a software company.” And I wonder if, in your work with clients over the years, has that been something that people in the executive suite have embraced or even understood?

Viktor: I don’t think they did yet. At least, it depends how you define “understood.” Because people very often throw away catch phrases. So I often hear people saying, “Yeah, we are now a software company.” But I don’t feel that they truly understand what that means. Because if they do, then they would become aware that they need to make drastic changes. Because if you are, let’s say a bank, your business is drastically different than it was 10 years ago. You don’t need offices anymore, you don’t need vaults and all those things.

And if your business drastically changed, that means that whole way how you organize your company, and then where you put focus, needs to change as well. Many companies are still saying those things without realizing how much change they need to introduce to comply with those phrases. And it’s very, very hard. A company — I don’t know exact statistics, I don’t remember it anymore, but something like only a few Fortune 500 companies that existed like 15 years ago, something like that, still exists today. I don’t think people are aware of how fast things are changing and how much, if you don’t adapt — then adaptation today means being a fully software company. Otherwise they’ll just disappear.

** Len:** Some of the stories I hear is people saying that, when it gets to the high enough level where decisions are made about where money’s going to go, people often can have the attitude that, “Oh, the computers are just this cost center.” And just this annoyance that, “I have to throw money at every once in a while.”

And when security, for example, comes up, they’ll just say, “Oh, what are the chances that data might be stolen?” And they’ll go, “Oh well that’s not worth spending any money on.” Or, “That’s only worth spending this much money on.”

Do you think those are attitudes that, given what you just said about churn in the Fortune 500 — is this something that’s just going to naturally change with corporate evolution?

Viktor: That will definitely change. It’s just that in most cases, that the change plays [out by the company disappearing]. And in other cases that will happen by corporations changing drastically. Otherwise — like who would have said for example five years ago, that television is a software business, nothing else. And look at the metrics today. And then look at what happened to most television channels. They’re in real trouble, at least in Europe.

Viktor: I like to say, when people ask me questions like, “Oh, but I really like what you’re talking about.” And I would be like, “But my companies, they’re so traditional. They would never allow me.” And I usually give them my line — like, “[Change your company?], or change the company.” And, “Try to change how your company operates — go somewhere else, because that company will not exist for long.”

** Len:** I see, change your company or change companies.

Viktor: Exactly, exactly.

** Len:** You deliberately chose self-publishing as a path for your DevOps Toolkit series. I don’t know if it began as the idea for a series, but it definitely turned into that. I was wondering if you could talk a little bit about that decision? Why was self-publishing so important for these books?

Viktor: The way I work is very chaotic. I understand writing a book — like, I can have a plan, then I’m going to do index, and then I’m going to think about, creating a summary or creating a chapter and so on and so forth. And I’d spend a month, thinking about it and planning — I’m going to start writing. My approach is very chaotic. I just start writing about things that I’m interested in at that moment.

And then at one moment, that starts getting shape and form and becomes a full-blown book. And that really does not work well with how traditional publishing companies work.

Those were my reasons behind the first book. But then I realized that actually it’s much more.

I think that the true reason for me self-publishing is the ability to publish something that is just started. Like I publish maybe when I reach 15% of the book. I think that the latest is around 20% right now. It’s something like, “Okay guys, whoever wants this book, take it. I just started it, I don’t know where it’s going. I don’t know what’s going to be the end result of the book.”

** Len:** It’s really interesting to see. I think it’s in your third book, The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters, where you’re explicit at the beginning about how you began without a plan, and you just wanted to see howit would turn out.

And on the journey, you’re not alone. You’ve got your readers going along with you. I was wondering if you could talk a little bit about that, because you get a lot of feedback from people while you write.

Viktor: After my first book with Leanpub, I opened a Slack channel, where every reader can join, and we can have those constant communications, and thinking in real time. Some of them are shy and semi-private messages. Some of them are public. So they’re just — get a notification, you track result. A day later, they start sending me feedback. Like, “This is horrible, this doesn’t work. I don’t like this. This is great, but how about putting this in the next chapter,” right? And I kind of like it, because I’m giving people what they want, not what they think they want.

** Len:** That’s really interesting. And you write too about having books in maintenance mode.

Viktor: That’s my [?]. Especially behind printed copies — of course, if it’s a novel, let’s say Harry Potter, I think that it’s great, and there is not much reason to change there. But for something, like technology, things are changing so fast that buying a book that somebody wrote two years ago and hasn’t updated — should be kind of illegal almost. Because things change so, so fast.

And then, so at least in the case of my books, I think those who buy them, they can maybe think of them more as a better-structured blog, when I’m going to continue adding stuff and then updating stuff as technology changes or my experience changes. So of course, maybe years later, that does not happen anymore. But at least for the first couple of years it’s [?] still not done, so getting continuously updated.

** Len:** And you do have print copies of versions of your book available on Amazon. I was wondering, just for those listening who are already, or who are considering self-publishing — how did you manage that process?

Viktor: Once I get from Leanpub the files for for print and ebooks and stuff like that — in the case of Amazon, that would be KDP and CreateSpace — KDP’s for ebooks on Amazon and CreateSpace is for printed copies — just registering there, filling in a couple of fields, and uploading the file given by Leanpub, and it’s probably like a 15 minute process altogether.

** Len:** That’s great to hear. Our Print-Ready PDF export is what I like to call a battle hardened feature. We can all thank the hard work that many Leanpub authors put in to giving us feedback into that process as well, for the fact that you can normally get away with just uploading it and being ready to go.

Viktor: One thing that I noticed, if you look at the sales, how much comes from Leanpub and Amazon, for example. I actually noticed a huge change. At the beginning, years ago when I published the first one, after it was 100% published, most of my sales were coming from Amazon. I think that the user base behind Leanpub and advantages are growing so much that now Amazon is a much smaller user base — in case of my books than Leanpub itself. Kind of like, everyone doubting whether it makes sense to go to Amazon for my fifth book whenever that comes.

** Len:** That’s really interesting feedback.

Viktor: It’s maybe not good doubting, since it’s such a simple process, it takes me 15 minutes — we’ve always put it on Amazon. But compared to three years ago, four years ago, the percentage from Leanpub is increasing compared to [Amazon]. That might be for a niche kind of readers interested in technology, I’m not sure, or in general — but that is increasing the odds.

** Len:** There’s a couple of things I can speculate about that go towards explaining that. One is just that Leanpub is older, and people are more familiar with buying in-progress books, that concept — and the idea that in particular maybe technology books are something that you should be buying in a format that can be updated.

But also in particular with your books, the importance of community, I think is something that people have grown more familiar with over time. And building that community through Leanpub is probably easier than through Amazon, in particular, because we make it so easy to do in-progress publishing and send updates to people. Like, send emails to people if you have a major update and things like that.

My last selfish question is, if there was one thing we could build for you, or one thing we could fix for you, what would that be?

Viktor: I’m not sure. I cannot recall something that I really disliked and don’t have. Maybe — I’m not sure whether I got so used to it that I now like everything, and I had problems in the past, and I forgot about them. But nothing really comes to my mind.

** Len:** Well, if something does come to mind afterwards, please shoot me an email and let me know. Because feedback from, well, battle-heartened authors is really important to us, and really helps everybody else who uses Leanpub in the future.

Viktor: Sure.

** Len:** Thanks very much for your time in the evening there, Viktor, to do this interview, and for being a Leanpub author.

Viktor: Thank you. Thank you for Leanpub.

** Len:** Thanks.

Originally published at https://leanpub.com/podcasts/frontmatter/viktor-farcic-08-03-18.