Gojko Adzic, Author of Running Serverless: Introduction to AWS Lambda and the Serverless Application Model

Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Frontmatter podcast, I'll be interviewing Gojko Adzic.

Based in London, Gojko is a partner at Neuri Consulting, a strategic software delivery consulting company that helps organisations big and small improve their product and project management practices, in order to develop and deliver their products better and faster.

A popular and busy conference keynote speaker, he has won many awards in his career, including the 2016 European Software Testing Outstanding Achievement Award and the Jolt award for the best book of 2012, for his book Specification by Example.

You can follow him on Twitter @gojkoadzic, and you can read his blog and learn more about him and his work on his website gojko.net.

He is the author or co-author of a number of Leanpub books, including the charmingly titled Humans vs Computers, and his latest book, Running Serverless: Introduction to AWS Lambda and the Serverless Application Model.

In this interview, we're going to talk about his background and career, professional interests, his books, and at the end we'll talk a little bit about his experience as an author. So, thank you for being on the Frontmatter Podcast.

Gojko: Thank you very much for inviting me.

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 u,p and how you first became interested in computers and software?

Gojko: I grew up in Serbia, and my father bought a Commodore 64 when I was a kid. I think my mother would have divorced him if he bought it for himself. So he officially bought it for me. But I was the only kid in the neighborhood that had a computer where I couldn't really play any games, because he bought it for himself to program - he was a geek. He didn't buy a tape recorder, and I couldn't load up any games.

And what I did, is I had this thing that is supposed to be mine - and had a big manual in German. I didn't speak a word of German, but there lots of things that I could type and make the computer go, "Vroom," or move some colors on the screen and things like that. So I started software development by typing over assembly lines that I had no understanding of, from a book I couldn't really read, on a Commodore 64, when I was six or seven years old.

Len: That's a great story. It's so interesting, it's often a parent introducing a computer into the scene. And sometimes it's for the kid, and sometimes it's for the parent.

Gojko: Yeah, my dad was an electrical engineer. He was putting electricity into factories and dealing with, I don't even know what the proper English phrase for that is, but like high voltage electricity transport. But he was a geek, he was interested in computers. I guess I grew up pretty much never wanting to do anything else apart from programming.

Len: That actually leads me to my next question. So you've studied a combination, I believe of maths and computer science at university. And one question I like to ask guests on this podcast is - if you were starting out now with the intention of pursuing a career like yours, would you do a full computer science degree at university, starting in 2019?

Gojko: I guess there is an aspect to having a proper computer science degree that gives - or at least gave me a background on some things that are incredibly useful in terms of modelling things and understanding stuff. I took a mix, as you said, of maths and computer science. We did lots of stuff from algebra and lots of stuff from calculus and graph theory and things like that. Almost none of it was ever commercially important for me. But I think it gave me a background in modelling and understanding how to understand machines, and how to deal with that.

I think, for me personally, high school was a lot more valuable for programming than university. Because I went to a specialist high school where we studied Pascal in the first year. In the second year, I had assembly and C++ and Prolog. Or in my third year and in my fourthth year, I think I had assembly again.

The fantastic benefit of going through this high school where it was really - very, very tightly specialised for science and kind of technology science in particular. I went to a section where we were doing programming quite a lot. So when I arrived at the university, my first two years of my university, pretty much I learned in high school.

And so I think that that school was a much, much bigger impact on what I did in the university. I mostly enrolled at the university because Serbia still had mandatory conscription back then. And when I was growing up, going to military service wasn't really the safest option for this part of the world. So I went to the university, but I'm not entirely sure if I would do that again. That's quite a good question. I think there are benefits in terms of getting this kind of scientific background of the whole thing. And I think it makes it easier to deal with some more complex things. But have I ever used it professionally? Probably not.

Len: That's actually a really interesting issue that you raise. It reminds me one time I was in an airport, and I heard these strangers to each other - just having a nice conversation. And this one woman was saying, "Now I work in construction, but I got a degree in--" I don't know? Education or something like that. And she said, "I've never used it, I've never used my degree," and I thought, I've heard this before., I remember hearing a professor talk about how he didn't think that people should have to learn other languages to get PhDs anymore - this was in the English Literature context - because he'd learned Latin, but he'd never used it. And I thought, how do you know what you're going to need in advance? And how do you know what you've used or not? If you know what I mean? Because even things you sort of like - you kind of know not to use them, if you know what I mean? Once you know them.

Gojko: Yeah. Look - I learned calculus. So when I was started to get interested into functional programming, I already knew what it's all about, and what the benefits are, and things like that. And I enjoyed learning a lot of that other stuff from a theoretical perspective, like non-linear geometry, where parallel lines are not lines, they're circles and things - that was amazingly interesting. But it wasn't entirely applicable to my career. I had one case of maybe - 17 or 18 years ago, when I actually used stuff I learned from the university - and actually used my textbooks from the university to solve a problem.

I was working on an energy trading system, where we were trying to help these traders optimize reporting for transit. Electrical energy kind of flows wherever the laws of physics tell it to flow. But for trading purposes, a trader in one country can sell electricity to a trader in another country. And if you sell some from, I don't know? Canada to Mexico, it has to flow through the US. But in Europe, there's a lot more choice where it flows. So this abstraction where you can say, "Look, I'm selling electricity from Britain and I'm selling to Holland, and it's going through this country as a transit." That is nothing to with where the physics is going to tell it to go, so what they can do is they can report any reasonable route, as where it goes. And different countries charge different things for that.

So selling and buying lots of this stuff, the traders were manually reporting where the sales are going and paying different networks fees. They wanted to have this software that does it for them, and I finally had the chance to do some of that.

So there was a lot of graph theory. We did a lot of it. We spent two months working on this optimisation thing. And as a way of testing it, whether it makes sense - I remember spending about one hour just kind of plotting individually so we can test it. Does it actually make sense? And then about 10 minutes before we were going to demo this, I realized, "Okay, this kind of visual plot looks good, so why don't I put this on a map of Europe? Instead of just a generic kind of matrix."

I put this on a map of Europe and I remember showing it to them and explaining this algorithm and everything, and then when I clicked the button, this thing ran. And all the screen - on the bottom, was a spreadsheet that was optimized, and on the top was this graph of Europe. And everybody jumped and says, "Oh this is amazing." I thought they were talking about the algorithm. They said, "No, no, no - the map." And we could have just not done the algorithm at all, we could have plotted their own stuff on the map. So I think it is incredibly exciting to use complex maths and complex models. But that's not what most of the industry does. Especially not what my experience is.

Len: Thanks for that great story. You're reminding me, there's just a bit of a coincidence there, but when it comes to the practicality of what you learn, like largely - especially when you're very young, those decisions are often made for you. And the only context you have is the context around you. So where I grew up, I was - we were talking a bit before we started recording this conversation - I grew up in southern Saskatchewan, and when I declared that I was going to major in English, everyone around me was like, "What an impractical decision, what are you ever going to do with that?" And the answer was, "Well, I'm going to go to the University of Oxford and get a doctorate in English Literature, and then I'm going to become an investment banker in London, then I'm going to do mergers and acquisitions in European utilities - including big electric companies." Because the knowledge that you acquire being able to structure things spontaneously and communicate persuasively, actually has a generalised applicability across all sectors.

But, like your story and my story - they're long ways around of saying that narrowly construed judgements about what's practical can often be ways of keeping yourself back.

Gojko: Absolutely.

Len: And closing off opportunities from yourself. It's a bit of a paradox, because you only have limited time, and you only have limited attention, and you only have one life to live. So you do have to make decisions based on limited information. But you have to leave an openness with respect to your own ignorance at the same time.

Gojko: Well, you're opening up options. It's really, really important. You never really know when one of these options is going to pay off.

You were talking about publishing and things. My route into publishing was quite a serendipitous one, where I was at the university and getting some extra cash - I started writing articles for local computer magazines. It was a nice and easy way to earn some extra money. They were taking programming articles. I started with programming articles, and then realized, because there were only two or three computer magazines in Serbia when I was a kid, and they had to be written in generalistic - it's only one or two pages they can publish in programming - but they can publish lots more stuff about other things as well.

So then I started writing about other things as well. And that led me to actually then - the company that was publishing the magazine was also publishing book translations, and they needed technical editors that would fix up other people's translations. Because you get somebody to translate the language, but they don't know the language system internals. So they don't know if they translated it well or not. And I had lots and lots of interest, so I started getting books to edit on anything from the old FrontPage Microsoft HTML editor, to Linux system administration, to cracking, to programming - all sorts of different languages. And that got me to read a ton of books that were just coming out.

I read Extreme Programming Explained - probably the first person in Serbia to ever read that. I got really interested then in unit testing - and then all of it somehow leaves breadcrumbs and some knowledge in the back of your head that comes back to stuff. In retrospect it all has a thread, but would I know that that's the thread that would build? Probably not.

Len: You've got a really interesting story. I wanted to touch on something. You mentioned where you grew up wasn't necessarily the safest place. And you also mentioned the map of Europe. So, one of the pleasures of this podcast is that we get to interview authors from all around the world and ask them about things they may have firsthand knowledge or experience of, that the rest of us only know from books and the news. And so I couldn't help but notice when I was researching for this interview, and checking out your profile on LinkedIn - that you were studying at the University of Belgrade during the 1999 NATO bombings.

I wanted to ask you about that. I mean, I know this could be hours and hours and hours. Were you there during the bombings?

Gojko: Yeah, yeah.

Len: If you're willing to talk about it, what was your experience of that like?

Gojko: When I look at it now - when I try to remember it now, it's like I was watching a movie. Like it wasn't happening to me, I guess? Partially I couldn't believe what was happening. And partially, I probably didn't really care what's going to happen. Because there wasn't much I could really do about that. I remember feeling that, "There's nothing I can really do about that." So if it's going to end up badly, it's going to end up badly. It was more kind of - I guess I was worried more about practical stuff. Because we had quite a big inflation just around that time as well, and I wasn't able to earn any money, because everything was closed for - in effect, what - three, four months. Nothing really worked.

And yeah, it was a weird period. The whole country ground to a halt for four months or so. But at the same time, we were relatively close to places where it was much, much, much worse. Like, civil war never really reached Belgrade. Where just two hours driving from there, people were killing each other with tanks and shooting snipers at each other. So as we were being bombed, it was fairly - I'm not going to say "safe," but it wasn't as bad as 200 kilometres away. I guess that there was a comparison there, that it's not horribly bad. It's bad, but you're probably going to survive.

Len: Just to generalize, did the people blame Milošević for what was going on? Or the West?

Gojko: Yeah, I don't know a lot. There's - probably realizing that's a horribly divisive political question, I guess? And people who are voting Milošević in for years and years and years. So there's part of a country that's trusted him, part of the country didn't. I, personally I blamed him for a lot of bad stuff. But yeah. It was probably his fault mostly. There was quite a popular theory back then, and I think still there is some truth to it as well, that Bill Clinton did the whole thing to take some news away from the Monica Lewinsky scandal, and things like that. That was the story that was at least sold here in the media about that.

Len: Oh that's really interesting. Because the Clinton-related narrative that I am familiar with around that is that it was because of the US failure to act on Rwanda.

Gojko: Yeah, okay - yeah. I don't really know? History's really interesting. I was reading this book called The Balkans by a guy called Misha Glenny, who's a British journalist. And he wrote the Balkan history, but from a British perspective, and from British historic resources. That was like a maybe 200 year period from the Ottoman Empire starting to fall apart until the late 90s. And a lot of the stuff that he writes about, we didn't learn in the book. So we learned in the books completely differently. I guess there is a very big territorial question where you learn history from, and whether it's a failure of Rwanda or failure to stop local civil wars, or whether it's somebody's sex life - there always is not necessarily a cause in relationship, I guess. Even when we look at software organisations today, and people claim, "Oh dude, this is going to be really great," and things like that. Even on a system or a couple of hundred people cause in a relationship is very, very difficult to establish, because the relationship in history is almost impossible.

Len: We'll be talking a bit about your work as a consultant shortly. I just wanted - it's funny, the coincidence - when you talk about the perspective in history, and particularly with respect to the Balkans - I just finished watching a Great Courses Plus course on the Barbarians of the Steppes. From the British perspective, and like even from the sort of European perspective - the Huns came out of nowhere. But of course, they didn't come out of nowhere. And this great lecture series sometimes visualises basically Europe and Asia from the north, looking to the south. Because this is the way that the Huns looked at it. And when you start seeing things from this completely different civilizational perspective, a lot of things that are inexplicable, start to make a little bit more sense. But as you say, telling causal stories about these grand historical things is really -

Gojko: There's a lovely book that called The Hinge Factor I don't know if you came across that?

Len: No.

Gojko: I don't even know if the author wanted to portray it as a serious history book. But it covers lots and lots of examples of history where there was a tiny influential factor that caused massive, massive historical change. So, trying to establish cause in a relationship in something like that, becomes really difficult. One of the stories they have in the book is how there was a charge of the French Napoleonic army against the British army at Waterloo or something like that, where they overran the cannons, but the British killed all the cavalrymen that were carrying the nails to nail down into the cannons - to disable the cannons.

Because what they would do apparently, I don't know if this is true or not, is a cavalryman would charge the cannon battery, and then some of those cavalrymen would carry nails. They would nail the part to the cannon where you light the fuse, and they will disable the cannon. And as this charge completed, these nail-carrying cavalrymen were killed. So they couldn't disable the cannons. And then as a result, the British won. And just trying to establish cause in a relationship in something like this - is just completely ridiculous.

Len: Yeah it is.

Gojko: There's probably not just a single factor that led to the bombing or the - all civil wars. It's very, very difficult to establish that. And that's why trying to untangle places where there's a lot of history, is really difficult.

Len: Well, we can try and untangle your history a little bit.

Gojko: Yeah, okay.

Len: Maybe we can have more detail on that? So you said you were writing articles. I believe that was for PC World?

Gojko: There were a couple of magazines here. There was an edition of like the Global PC for Serbia, actually. I ended up being Editor in Chief there for two years at the end. I was also contributing articles to a bunch of other magazines. I contributed articles to popular culture magazines, not just software magazines. Because it was easy money, and I figured somehow I could write. I think my Serbian language teacher, and literary teachers would probably commit suicide if they knew I was making money on writing. Because I never had really good grades in anything that wasn't science-related.

Part of going to a high school that was specialised in science was, you could literally ignore all the other subjects. Because the school prided itself on having a very high grade average. Which meant that if you had any awards on any competitions at all, you could not get less than a C grade - essentially for any other things. So subjects like psychology, language - I pretty much did a denial of service there. But I still got a passing grade. Because I knew they couldn't fail me.

Len: That's really interesting. Thanks for sharing that. Because it's just surprising to me to hear that - your books are so well written - to hear that you were getting bad grades in related subjects like that - is sort of interesting to learn.

I'm not exactly sure, but you ended up either living in London or working in London?

Gojko: Yeah, I moved to London in 2005 from Belgrade. It was much easier to make a living in London than to earn money in Serbia, around that time. I wanted to go where good software is produced. Serbia was then, and still is very much a outsourcing software country. There's a few local products, but most of the software done ther is - a means of making it cheaper, not better. And I'm quite passionate about high quality stuff, not cheap crap.

Len: So as someone who moved to London myself at one point - how did you adapt to life there? Did you just fit in?

Gojko: Yeah, I fit in. I loved it. I think the working culture there is amazing, and I think the lifestyle there is very, very busy. I remembered my shock of seeing a river of people coming out of the Central :ine - the first time I saw that. It is a country on its own, effectively.

**Len:** Just to ask a very specific question. So where did you live when you first moved there?

Gojko: I made the mistake of thinking about London as a central European city. So I thought, "Go and live in the center, because that's where things are." So I used to live near Marylebone. A slightly northern part of Westminister, but still Zone One where - the nice thing about that was, I was able to walk to work. Which I wasn't able to do later. But the bad thing about that is literally Friday after 5 pm, nothing is there. But yeah, so I used to live there. Then we moved slightly more west, we lived in Putney. Just across Putney Bridge and Fulham. Then we moved to Barnes. So - more or less, the western area of London, later.

Len: And you ended up working for the company that you work for now, Neuri - how did you end up with them?

Gojko: No, that's my company - I started that.

Len: Oh you started it. I didn't know that. Okay.

Gojko: Yeah, I started that. That's my company. I started it when I was in Serbia, I was doing outsourcing gigs as well. And then when I moved to London, I took some of those gigs with me, but then also started working for another company there, full time. And then I did outsourcing stuff part time. Then I quit the full time job, because I realised I've never really been a good full time employee. That's just not me. And I wanted to do more shorter term gigs, and then more consulting. I spent about two years, I think - trying to be an employee, and then decided they're just not for me, and basically just, yeah - continue drawing the company. The company's now a partnership. Three other people joined the company at various different points. So now there's four of us - effectively, as partners in the company.

Len: think one of the things that a lot of people who are thinking of breaking out on their own - I think a lot of people actually feel the same way about being a full time employee. When you started out, how did you go about getting clients?

Gojko: Conferences. I think conferences are - again, we're talking about different threads. So one of the really interesting threads there is that, as I was writing these articles for magazines and things, when I became an editor, I started actually getting a lot of gigs for programming from that. Because I got to know people, people got to know me. Then I realised when I moved to the UK, well - in Serbia, I had a reputation, I had a name. It's a small market, everybody knows everybody. Or at least it was a small market back then. But when I moved to England, I literally didn't know anybody professionally. So I realized I have to find connections.

So I started going to lots of meetups. I started going to lots of conferences. Started speaking at meetups and conferences. And I think that's probably the best way of getting contacts and getting clients that I can recommend early on - books helped, because a book - a book for me is like, you made a 250 page business card. Books help, but a book is a much, much bigger investment, and a book requires a relatively narrow topic. Going to user groups, going to meetups - it's a low risk, low budget way of getting to know lots of people. Speaking at meetups is a very low risk thing. You don't have to prepare your fantastic keynote. You just have to have a topic you want to talk about.

I think that's an amazingly good benefit of London, where there was something happening almost every night. Around that time in London, there was an amazing group of people evolving Agile, and evolving what later became the London School of TDD, like Steve Freeman and Nat Price - evolving a lot of these behavior driven ideas like Don North and Chris Matz and Liz Keogh. A lot of people working around testing, around that time. And like Anthony McConnor.

So for me, especially being fresh off the boat, it was amazing to be able to mingle with those people and to be able to learn from them and synthesize my own ideas from their ideas.

An amazing benefit of being in a big hub is being able to experience that, and participate in that experience. I think I really caught a very interesting period of software development history or software development industry, around that time. Because the whole agile thing was exploding on the scene, and it helped me a lot as well.

Len: That's really interesting, actually. Thank you for sharing that. One of my questions was going to be, "How did you get into the whole agile -?" And of you said TDD - so Test-driven Development, for those who might not know - and it's so interesting to hear that it was from community. People so often think of programming and software as being this inherently isolated thing, where people are forced together in offices and stuff like that. But what you're describing is, that there was this thriving community of people talking with each other.

Gojko: Absolutely, yeah. All those things - you hear a lot of these ideas. You hear complementary ideas, you hear people's experiences and things that. The whole Agile thing for me happened, I guess, when I was still in Belgrade, in the early 2000's, and I was working on outsourcing - I got to the point where I was on the entry point of the money. What I mean by that is, the way outsourcing was done back then is, through about, I don't know? Five to ten intermediaries. Where there's somebody in the west that wants some software done. They know somebody who knows somebody who knows somebody who knows somebody who knows a couple of programmers somewhere. We were not doing the industrial outsourcing that you get from hiring 300 people somewhere. Most teams here were two, five, ten people teams. So the teams were smaller - but I found out at a point where we were getting paid something like $5 an hour, if I remember correctly, the first guy was paying the second guy almost $150 in that chain.

Len: So just to be clear, so you're talking about how there's basically companies, say, located in London, that are outsourcing programming to places like Belgrade?

Gojko: Yeah, and there's like five or ten intermediaries between, and the first link of that chain is paying something like $100 an hour, or $150 an hour - and we are getting $5. It was just completely ridiculous. And I realized, "I have to skip at least a couple of these levels to make some decent money." So I managed to get myself into the point where I was actually talking to the people who were on the other side of the border. And at that point, I was responsible for converting some fixed amount of money into something that was a variable amount of time and money. I was responsible for getting the things out, so it doesn't come back....

I had to get it out, and if it's broken, I have to fix it - and I have to pay people to fix it. So, the whole idea of high quality software that has to meet customers' demands. And not just what they wanted, but what they actually need - is really, really important. So automated testing - not just automated, but learning how to test manually and automating the style, it can be automated - that was really, really important. Because we couldn't afford to waste our time doing that. And that's how I got interested in the whole unit testing thing - from test automation. I read Kent Beck's book very early on, and Ron Jeffries' book on unit testing on. And Jarrad Meseryth's books. So technically, I knew how to do that stuff before I came to London.

But what I learned from the community was the whole human aspect of that, and how to drive it through teams, and how there's a lot more to just technically designing a good test. There's figuring out what you want to test.

I got into the whole Agile thing from the testing side of things. But then, as I was part of a very small, probably insignificant part of that community, they were discovering lots of interesting things around 2005, 2006. People were still figuring out, how do they integrate testers and developers together? And then product management came along, and how to do business analysis in Agile, and things like that. People were still figuring out those things in the mid-2000s.

Len: It's really interesting, the way that the issues that you deal with in your career and in your writing and your books are sort of like - there's this interesting connection between the high and the low, I guess? So it's really hard to focus in. But I'll give it a try, by quoting you back at yourself and maybe moving onto the next part of the interview, where we talk about your books and your projects.

So you've written - it's a little bit of a long quote, but I'll quote it here. Because it sets the stage very nicely. You wrote:

"Commercial organisations across the European Union lost 142 billion EUR on failed IT projects in 2004 alone, mostly because of poor alignment with business objectives or business strategies becoming obsolete during delivery. This is roughly the cost of the International Space Station programme, including all flights, or almost twice the cost of the entire Apollo programme, which achieved six manned landings on the Moon."

I loved it when I came across that. Because so much of the time, people hear about things like testing or Agile, and they think, "This is the boring stuff." This has come up on this podcast before, but I just find it endlessly fascinating - the amount of waste that people are willing to tolerate when it comes to things having to do with software in computing, that they would probably not tolerate in other areas. I don't know how to capture it, but there's something about executive - and this is changing, of course - but there's something about a certain type of executive culture that just can't handle the software side of things. And there's also a problem going the other way. Where there's people on the software side of things sometimes don't naturally have an understanding of the business side of things.

It's so interesting reading your books and listening to your talks. Because you seem to be sort of not in the middle of it, but understanding how these things are actually all connected. One of the really important things is managing communication by trying to talk the same language. And this is where things like Domain-driven Design and stuff like that come into it, as I understand it. In the course of your career, have you seen attitudes around the relationship that say the C-suite has to software, changed?

Gojko: I guess, that's more related to a particular company than the whole industry. I think as a whole industry, there's still a lot more demand than there is supply. In terms of software, I think - when that's going to stop is a really interesting question. Because I didn't really follow the part of the industry before the 90s. I've read about it, but it's very difficult to talk about it, because I'm not participating in that. But my understanding is that somewhere in the 80s and 70s, people were automating existing business processes. You would automate well known accountancy processes by building an accounting package. That was to deal with - speeding up the human side of things, and the human cost.

Actually find a quote, found a quote by John Forlinman - he worked with some students, and they tried to build a compiler very early on. So to avoid having to manually do the assembling part, like the digits part of the machine code. And he was really angry, because they were spending valuable time on a scientific instrument, on paperwork. So the humans were cheaper than computers back then. And then we got into the situation where computers were significantly more powerful than humans. They could do things that humans couldn't do.

But then somewhere in the 80s, we got to the point where computers were cheaper than humans. And you had this - almost anybody wanting to, companies wanting to have - even word processing and things like that. Those were still relatively well known domains. We were automating things that were well known.

And somewhere in the 90s, the whole PC revolution really took off, and then people were building lots and lots of interesting things to make this PC machine useful. But what we're doing now, is mostly, not really automating existing stuff - people are looking for new business opportunities, even traditional businesses like banks are experimenting with new stuff, new technology.

And there's a lot of it that is wasteful. Because the software is wasteful. A lot of it is just because those things are bad ideas, and people are experimenting with different business ideas, just using technology. And there is an element of that as well - I think one part of it is really to figure out, how do we not waste too much time building software that doesn't make sense?

But has the attitude of the C-suite changed? I think different companies, different levels and different things. I worked with a couple of big companies where the attitude was actually worse. Because a different CEO came in or a different CIO came in. And then they went all the way back to proper project management, and proper plans and things like that. It's probably going to take five years for them to go back again to trying to understand what's going on.

Mark Schwartz had a really interesting piece of statistics in his book The Art of Business Value I think? Where he talks about how the average lifespan for a Chief Information Officer at a large company, is something like 18 months. Where - 18 months is easily tangible into a software project that doesn't deliver or something. So we get through these cycles where you replace the head of IT at a company every 18 months. There's very little continuity there. And the new person comes along, and they always have to prove that whatever the old person did was rubbish. So -

Len: That's very surprising to me actually. I did not know that. What is the reason for that? I mean is it because someone moves on, or is it because of just internal competitive practice?

Gojko: Yeah, I don't know. It's probably general short term thinking, driven by the market pressures or technology changing. That is a big question. But with that lack of continuity in large companies, it's very difficult to do anything serious. I mean yes - you can build a lot of software in 18 months of course. But can you properly launch a new product and make it grow and things? Probably not. It still takes a couple of years to properly grow a good new product. Not because software is slow, but because that's how the market takes things. Facebook didn't become Facebook overnight. And they are an example of absolutely stellar growth. But it took them at least 5 years to actually properly be the number one on the scene, and things like - and that is an outlier, where I assume most other products, at least what I see - take a couple of years to grow into something that's. You were talking about Leanpub starting in, what - 2011?

Len: 2010, yeah.

Gojko: 2010. And I remember people not really treating Leanpub as a respectable way-- not respectable, but as a proper way of getting books, it was like, "Oh these are all half-written things, you don't really know what you're buying." It took a couple of years for Leanpub to generate the reputation that it is a place where you actually go and buy books. I sell a decent amount of books on Leanpub, so people trust you. I trust you. I like buying Leanpub books. But, yeah - just getting the technology out there is not enough. It takes a bit of time to establish trust in the market, to establish a name. And restarting strategic stuff every 18 months, really is difficult to follow any continuity there. And that seems to be the statistical norm for the big companies out there.

Len: There's so much we could talk about on this. Particularlym I mean just very briefly, with respect to Leanpub - one of the things that Leanpub had to do was convince people that it's a respectable thing to publish a book before it's finished. And we're not talking about serially published novels like non-fiction software programming books. It's not only the sort of like - is it not respectable to publish that way? Is it risky to buy books that way? And things like that. And yeah, it's taken some time.

But now - I mean, no one even asks us about it anymore really. People just get it. And it took time and persistence to establish that. But now it's like - at least in the tech programming space, it's just an understood thing. Even with other kinds of books as well. But these things take time.

I'm curious - so do you think that maybe one of the reasons that CIO lifespans are so short, is perhaps because it's easy to blame the person who's sitting on top of software when things don't work?

Gojko: Absolutely. That probably is a scapegoat or a lightning rod position, where when something doesn't work, it's much easier for the CEO to fire the CIO, than accept the blame that the whole strategy was wrong. Plus the whole technology landscape is changing so frequently still, that it's very difficult to place good bets. There are of course reasonably good, large companies that benefit quite a lot from technology. But they're probably an exception rather than the rule.

Len: I've quoted that number from your book about the 142 billion -

Gojko: That's the number from the British Computing Society research. That was published in Impact Mapping, I can publish the reference to that.

But yeah, I'm fascinated by how much money people are willing to throw away on software. I don't think that just throwing money away on software, or throwing money away on bad business ideas - inefficiently building software is a great way to throw money away. And that's what, I guess, the whole lean startup counter-culture revolution tried to fight against. Taking these massive, massive, massive bets and even in a sense, the whole Agile movement and Extreme Programming, is also a fight against that. A fight against these big, big, big bets that for years and years we don't make the payoff or not - and at some point they get shut down.

There's a lovely episode that happened at the BBC a few years ago. I now quote that quote often in my impact mapping talks, where there was their personalization project, "My BBC," shut down after they spent 75 million pounds. And because it was a publicly funded project, the UK National Audit Office got involved. And the conclusion was amazing. The conclusion was that they could spend 75 million pounds without delivering any value - and that being shut down because the whole thing was Agile. Extreme programming was a fight against these big bets, and now we are ending these massive projects where people are calling them Agile and throwing away - 75 million pounds is more than 100 million dollars.

Len: One of the curious things about - if you have a business idea and it involves - I don't know? Like making a new car, and you fail, there's sort of physical things to show for it at least, and there's assets to sell off, and things like that.

A big famous example from sort of relatively recent times, of a big software fail, was the Affordable Healthcare Act in the States, or Obamacare. I probably got the name wrong, but they had a famous fail with their website.

In Canada, our federal government, I believe, spent something like $300 million - it's either $300 million or a billion dollars trying to create a gun registry. That failed, and they just had to completely start over. And more recently, the Canadian federal government hired, I think, a very famous company, to build a payroll system for it, that just completely failed. It was like a billion dollars. And at the end of these software projects, there's nothing to show for it. Because all you built was, was code. And so there's something particularly, I don't know, uncanny about a software fail. It's like there's nothing physical even to sell off.

Gojko: Yeah.

Len: When you're done. So, going from very high to sort of the details - how are we going to solve these problems? There's Agile practices and things like that. You brought up impact mapping, and I was wondering if you could talk a little bit about that? So you've got a book on impact mapping on Leanpub - and an idea you developed from something else - called, I think it was "effect mapping?"

Gojko: Yeah, I came across that idea - first of all, it's a visualization technique that helps to show the big picture. It helps to show how the activities that people are doing on a day to day basis - delivering tasks, features - what they plan to do relates to an organizational objective, or relates to the company goals. And I came across that, it was invented by a Swedish interaction design agency called Muse, to help their work with, I think, the Swedish government actually - on large government IT projects. Because they realized \how much waste there is and how by helping people communicate better and visualizing what really needs to be done, and helping people understand their assumptions, how much more effective people could be.

And it really came to me at a very interesting point in my career, I guess. I maybe wasn't ready for that message before, but it came slightly after I needed it. I got a big slap in the face, because I didn't know that. I was a CTO of a startup where we definitely did stuff amazingly. We had continuous delivery before continuous delivery was a buzzword, or even the book came out. The programmers I worked with were some of the best people that technically I ever worked with, some of the best people personally I ever worked with. So an amazing team.

Technically, I think we did everything right, and the company ran out of money. I got to the point where I didn't have money to pay rent next month, because I wasn't taking a salary. I was hoping it was going to explode and become big. And I didn't realize then that all this technical stuff is pointless if we're not building the right thing. And that's inspired me to do a couple of conference talks on, why can't we build the right thing? And after the conference stopped, one of the guys in the audience came and said, "Look, you really need to read this book." And he actually gave me a copy of the book. And that's how I learned about this, the technique called "effect [?]." I hope I pronounced it correctly; I don't know how to pronounce Swedish stuff.

But the book is called Effect Mapping in English, and although they were talking about this from big government project perspective, as it is - how wonderful it can fit into interactive projects, and interactive delivery. And that's how I started talking about, started writing about that. I was really excited about that, and tried it out with a couple of clients. I had to go back to consulting after the start-up failed, so I went back full on to make money for rent. And we were experimenting - we were trying it out and doing some early experiments.

I remember talking to Craig Lyman about this, because we shared a single client, and we went out for dinner. And Craig actually said that effect mapping is not a name that people will instantly get in English, there needs to be something punchier. So he suggested impact mapping as a name. And impact mapping it became. And yeah, that's one of the most important tools in my arsenal now to develop good products, and figure out how not to waste time and focus on the right things.

Len: And the way it works is like a mind map, if I understand it correctly?

Gojko: Yeah.

Len: So you start with a statement in the center, and then you branch off these child statements that can have child statements of their own"

Gojko: Yeah. The idea is that you relate a higher level business goal or something that you want to achieve for the next milestone - three months, six months, a year or something like that. And then relate it to smaller business changes that need to happen in order for that to happen. And then link that to technical changes, or software features, or smaller business activities, deliverables, that you want to achieve. After I started researching this, there's actually quite a lot of similarity with a bunch of other ideas.

There's a lovely book I read last year, where they explained the same thing, but from a slightly different perspective - called Four Disciplines of Execution, where they talk about how everybody can measure at the end, whether the thing succeeded or failed. So it's very easy for the Canadian government - one billion dollas later, to realize that this project failed. But it's very difficult for people to know that after they spent only $1,000, or only $10,000. Because you still don't know. And that's because it's very difficult to measure something on a shorter timescale, that gives you a good indicator of value. It's very easy to measure effort, but it's very difficult to value.

So that's what impact mapping helps with. Impact mapping gives people a way to measure things on a shorter timescale through behavior changes. And again, in Four Disciplines of Execution, they conclude there's two potential things that you can measure on a shorter timescale. One is behavior changes - will people do something better, faster, cheaper, easier? Will people publish books differently than they did before? With Leanpub, they can publish books halfway through production, and they can get feedback. That's a difference. That's a behavior change. Will people buy books that are unfinished? Yeah, that's, again, a behavior change. And you can measure behavior changes there and you can focus on achieving behavior changes.

That's a core idea in Four Disciplines of Execution, but it's also a core idea behind impact mapping, where you map softer deliverables to behavior changes that these deliverables are going to lead to, to longer term business goals - and look at these things. And the genius of that is that behavior changes are observable on a shorter timescale, but behavior changes are also scalable. In order to achieve something, if I'm supposed to get people to click on a button 50% more than they are now, that's a behavior change. If I get them to click 2% more, that's already valuable, it should go live.

That is the core of interactive delivery. How do we know that- -? The essential question that people need to ask themselves when they are delivering a software product is, "Are we moving in the right direction?" Not, "Are we there?" But, "Are we moving in the right direction?" And if we're not moving in the right direction, how do we move in the right direction while we still can? And that's why I use a metaphor of a GPS where the GPS navigator, the fact that you have turn by turn navigation, is what makes the whole difference. People had maps before, and you could find yourself on a map before. People had ways to measure longitude and latitude and things like that. But having turn by turn navigation and trip re-planning is what really brought the revolution there. And having good operational awareness wherever you are at every moment. So it's not a big issue if you miss a turn, the GPS navigator will replot it and tell you where to take the next turn. And the reason why I'm so passionate about impact mapping, is impact mapping helps people create the GPS for their software delivery.

Len: Just a couple of things about that. One is - so, just so people understand - they, if I'm correct? The exercise of impact mapping, when you sort of make this mind map - is not to make a plan necessarily. Not, "Here are some steps, and now we've all got to stick to them." The higher level thing is to have a conversation.

Gojko: Absolutely, yeah.

Len: That is a shared and visual understanding - avisualized understanding. Because you can't have a shared understanding unless you're all looking at the same thing.

Gojko: Yeah. Having it externalised, having it visual so people can make sure that they understand the same thing. Making it tactile, so people can play around with different priorities and options, is what really makes the big difference. And again, not just creating a plan - but actually creating a bunch of compatible plans, where you can start choosing things. Again, when you start researching something, lots of compatible ideas start popping out.

One of the books that really opened my eyes to explaining this slightly differently, and learning about this more is Adapt by Tim Harford. Harford is a British economist, and he wrote a book on why linear plans tend to fail. Not in software, he doesn't understand software. He actually has a case study about software in the book - or not a case study, a story. I think he didn't really understand what was going on there. But there's lots of really wonderful stories from civil engineering, from government planning, from the military - where he talks about how linear plans tend to fail, because re-planning is difficult when unexpected things happen.

He comes up with his three principles for good plans. And one of the principles for good plans is that a good plan has to have ideation. So it has to has to have more than what you will just end up delivering. So if something unexpected happens, there's options for you to choose right there and then. As I said, the magic of a GPS navigator is it made re-planning cheaper. If a mistake happens, there's all these other options that are there for you. So an impact map is a menu of things you can do, but you're trying not to find - it's a road map in a true sensem where there's a map of roads. You don't want to take all the roads, you want to take the shortest, fastest, cheapest road. But defining that all these other roads exist, is beneficial. Because you know there's a plan B, a plan C, a plan D and all of it there as well.

So an impact map is a visualization of this whole landscape, what we could do to cause potential impact in the business - that we might want to do or might not want to do, that could lead to this objective. It allows people then to agree on it as a plan. It leaves people to re-plan cheaper and easier, if re-planning is to happen. And it allows everybody to be really, really focused on this thing we want to achieve and subordinate everything to that. I'm actually now writing another impact mapping book, and that should appear on Leanpub in a few months.

We've done a bunch of interviews with organizations where they've adopted impact mapping, and interviewed them about how they applied it, and what the benefits are. And we spoke to a big government agency. I still can't publish the name, because we're still going through the process of getting permissions, but a huge US government agency where they were starting this process, where for a year and a half they were collecting requirements. Nothing else, just collecting requirements to replace an old system with a new system. And a new CIO took over and basically realized, "This is never going to be finished." So instead of this whole Word document, they got all the stakeholders in the room, spent a few days impact mapping, created a plan - and they realised that what they wanted to do, is they wanted to cause a behavior change, where a human case worker can process more cases per day.

That is the whole thing. They published that number, everything else was subordinate to that number. They were choosing software features that helped them do that. They were measuring very quickly, "Is the number growing or shrinking or staying the same?" And that that allowed them to understand whether the features they were introducing, the way they were building the software, is allowing them to help people move that number in the other direction. The clarity of that was insane, because they achieved what they called "full operational readiness." Which is the wonderful government phrase for "project done," two years before anybody expected.

Len: There's so much to touch on there. One of the really interesting things that you talk about in the book as well, and you sort of glanced at, or mentioned here briefly - is that, if you're sort of coming up with - I'm going to put it in quote unquote "plan" - because often people think that's just like a series of steps that you've all predetermined. But if you're having a discussion about what you're up to, and you've finished that discussion without talking about, "What do we do if we have setbacks? What setbacks might we encounter?" Then you're not done that conversation yet. You can't just have a sort of like optimal, "Nothing's going to change, all the conditions are going to stay the same."

One thing I've been noticing in talking to people who work on similar issues like you, for this podcast - is that there's this curious convergence between special operations military strategy and software strategy. Where if what you want to do is give, especially in an Agile work environment - as long as people have a shared understanding of the goal and the purpose and the culture, then you can give them autonomy on the ground level. And that way you can take into account variation. Because people will - as you said, there'll be a plan B, there'll be a plan C. But once you've gone through the exercise of having a plan B or a plan C - people have a shared understanding of how to adapt to changing situations. So when things inevitably change, then they know how to come up with a plan D or E on the spot.

You mentioned behavior. This is actually quite a complex concept, and I was wondering if we could narrow it down to a story I know you like to tell about the 40 or 41 shades of blue?

Gojko: Oh, yeah.

Len: I was wondering if you could sort of briefly share that story?

Gojko: Absolutely, yes. So, by the way - assuming that these people will listen to this on a device of some sort that's connected to the internet. There's a lot about this story from lots of different sides. And one of the most wonderful things about this story, that you can actually read both sides of the story online - it's usually read from one perspective, but with this because - you can actually find people on both sides of the story online. Then you can make up your own decision.

So at Google a while ago, the head of design wanted to change the colour of the links on the home page. This was, I don't know? Not the first change they were introducing. So the engineers - my understanding is - got a bit pissed off with all the changes. Can I say "pissed off" on the podcast, or do you cut it out?

Len: Oh, it's a podcast. Yeah.

Gojko: Okay. So they wanted to challenge that a bit, and wanted to figure out how do they test that this is right, and what makes this good? And now we have this situation where somebody who obviously is one of the top professionals in their work, who rose through the ranks to be the head of design at Google, coming up with a color - that's their responsibility. And the color was supposed to be a lot more noticeable to a human eye - according to color theory. Now what the Google engineers did at this point is they knew about the trick with behavior changes.

So they were asking about - not how to test this, whether they've done what they were being asked to do. But, how to test whether what they were being asked to do was a good idea. And you can't really test whether a color is more noticeable or not. You can - I mean you can put it in front of people and can ask them, "Do you notice this more or not?" But that's not a behavior change. And what they talk about in Four Disciplines of Execution is - if you can find a behavior change, then it becomes observable, it becomes something you can measure - and you don't end up asking people what they want, you end up observing them.

And on a side note, that's probably one of the most brilliant things I've learned in my career, is not to trust users to know what they want, or to tell you what they want. To observe them, and then figure out what's going on. So, how do you observe users? Well, you observe a behavior and look for a change. So they figured out that if this color is a lot more noticeable, people will be clicking more on ads. And then that night - as the name of the episode probably suggests - Google now has deployed that color, but also 39 other colors of blue. And they proved that in effect, if you kept that color for 100% of users over a year - I don't remember the exact number now, but it's easy to find it online. It's probably something like 250 million dollars would be lost.

Because that color might be more noticeable when you print it on a five million dollar Heidelberg printer that actually prints that color. But when you show it on a cheap LG phone, it's not that color, it's some abstraction or it's - And who knows why? As I said, people are unpredictable, a lot of unexpected things happen.

So the head of design, depending on who's side of the story you read - either was fired or quit, as a result of that. But yeah, that's a big question of how much does a change cost? Does it cost, I don't know? 20 minutes of somebody's time re-configuring CSS files, and maybe an hour of testing? Or does it cost 250 million dollars in lost revenue? Although somebody very, very important says this is the right color to use. Humans are unpredictable, essentially. That's part of a problem. And especially with a multitude of devices, with a multitude of usage buttons and things like that - that's really, really difficult to predict what's going to happen.

Len: That's actually a great opportunity to segue to talking about another book of yours, Humans vs Computers. When you bring up the unpredictability of humans - and it's so interesting, because we have these wonderful machines. And you talk a little bit about how computers have improved over time, and become dramatically more powerful than they were in the past. So they're applied to all kinds of problems that they wouldn't of been applied to necessarily in the past.

The computer itself is supposed to be a sort of predictable machine. But when it starts interacting with unpredictable humans, all kinds of things start to happen. And one of the examples that you have in your book, has to do with license plates.

Gojko: Oh, there's a couple of examples. There's white license plates, new license plates - there's seven x's license plates, there's - people have thought all sorts of curious ways of getting vanity license plates, and that interacted with bad assumptions in software systems quite a lot. One of the loveliest examples of that was a software developer who thought it would be funny to get license plates for "VOID," not knowing that in his county, the software system was developed so badly that if the courts voided a ticket, if they threw it out in court - the only way they could record that in the software system is to record it against a "VOID" license plate. So all of a sudden, this poor guy started receiving parking tickets and fines for everything that was voided last 10 years. Because before that, nothing was matching and all of a sudden -

Len: Yeah, yeah. Just to be clear about that. It's such a great story. So someone got a vanity license plate, that instead of having the usual combination of letters and numbers that's random, it said "VOID." But the computer system had a sort of classification for "VOID" license plates. And so this guy who had the license plate that actually had the text "VOID," started getting mixed up with things that were classified as void. And it's really interesting too how, for example - I think another example might be someone who had a license plate somewhere in the States that was missing - and I might be mixing up examples, but it's the same thing. Where what would happen was, the local parking attendants, if they couldn't get a license plate for some reason, they would type "missing" into the record.

Gojko: Absolutely, yeah. That's because - again, a stupid software system where somebody put that as a mandatory field - that's a famous example. There's another example of somebody having a vanity license plate for "NO PLATES." Which is a wonderful combination of two bad software assumptions. So the first one was, when he was trying to get license plates, I think he just sold a company. So he just became rich and bought a yacht. And he wanted to have "BOATING" or "SAILING" as his licenses. But the software to ask for that required at least three choices. And he couldn't think of a third choice, he wrote down, "NO PLATES." Like, this is a mandatory field - but I don't want anything else, unless you can give me one of these two.

And because everything is automated now, he actually got plates that were "NO PLATES." Somebody interpreted his answer as like, "Don't want this," as "NO PLATES." He thought this was funny, but very similar to the example you gave, in California I think parking attendants were instructed to type in "NO PLATES," into the software for issuing parking violations when they couldn't read the plate or whether the plates were missing. So yeah, I think at some point, this person was receiving something like 2,000 parking tickets a day.

Len: And there's another example, I think one that people might be a little bit more familiar with, where there was a guy who had an unfortunate IP address. A farmer and son were in the middle of nowhere, and then that IP address was associated with criminal activity and things like that. And all of a sudden, he's got police vans at his farm.

Gojko: These people, actually it was an elderly couple. You've put me on the spot now, I don't remember exactly the names. I can find it in the book. But it's all in the Humans vs Computers book. I think James and Therese Arnold, if I remember correctly.

So they rented this farm in Kansas, in the middle of nowhere. He didn't even have a computer, and all of a sudden people started showing up. FBI showed up to search for missing laptops. There were people showing up from all these three letter government agencies almost every week. And the local sheriff had to put up a sign in front of their house, saying that if anybody wants to arrest them, to come and talk to the sheriff first. That's how badly it got.

And actually what happened is, somebody sold to the US government, a system that was translating IP addresses into physical addresses. But everybody who's done stuff with computers, knows that there's no accurate translation for that. There's approximations and approximations and what this software did was actually, it will try to find data from various WiFi networks and like assigned numbers, and then if it couldn't find the exact address, what it would do is it would place it in a geographical middle of the area where it knew it belonged.

So if it knew that the address is in New York, but not exactly where in New York - it would place it into geographic middle of New York. Where James and Therese Arnold had a lucky or unlucky coincidence that they rented a farm that was the closest building to the geographic middle of the US. So if this thing knew that an IP address is in the US, but not exactly where in the US - it effectively was mapping it to their home. And they have 600 million IP addresses assigned to them.

Len: Oh my.

Gojko: And without even having a computer. So you can imagine almost any criminal activity that happened online, they were flagged for that one way or another.

Len: The line in your book where you - I mean, I recommend this book highly to anyone, it's just so entertaining and so interesting to read all these stories. But you have a line in the introduction where you say, "Digitizing a piece of work doesn't mean there will be no mistakes, but instead guarantees that when mistakes happen, they'll run at a massive scale." And this is an interesting feature of contemporary life where these mistakes - because of automation and things like that, can suddenly be very dramatic and widespread.

Gojko: It's a machine gun. And you push a button, and all sorts of bad things happen - unless you know what you're doing.

Len: Which reminds me actually - I just saw an article the other day. I mean, this is not new. But literally automated machine guns are something that we're going to have in our world going forward. And it's very important to keep in mind that - when we have these discussions about software testing and Agile project management and things like that, these are not trivial matters. This is literal life and death. You have an example in your book of people who've been convicted of violent crimes getting out early - and then committing crimes that they otherwise wouldn't have been able to, because of mistakes made by software and different -

Gojko: Yeah, there's the opposite example as well. There was a system in the US, I don't remember which state, I think Michigan? And there was a similar system in Australia, that was automatically issuing fines and penalties for benefits fraud. And the system was quite buggy - the Michigan system was wrong one out of ten times. And they were sending these massive fines to people who are on benefits, so they don't have money to pay. And there were a couple of people committing suicide because of that. They lost faith in community and, figured out there's no way out. And this is really the danger that now software is running everything. That is the danger of - small mistakes, just having this massive, massive ripple effect.

Len: And the way shortcuts as well, that happen in development - can actually have a real impact on people. So for example, you've got a great example about - bad things can happen if your last name is "Null."

When I was reading that, it reminded me of - I'm not a technical person myself - but one of the ways I got hazed when I started working on Leanpub, was like, "Len, go internationalize the website." And when I was trying to set up the Norwiegan language, it just wouldn't work. And it was because - I'm probably going to get this wrong. But the two letter code for the language was "NO."

Gojko: Yeah, no.

Len: There was something I was doing in Rails that thought this was like, "No," not "N-O."

Gojko: Not a language, no, yes.

Len: It took me like forever to figure out what was actually going on. And it's interesting how these details of the way we're sort of like - because software is writing. And there's this inbuilt problem that there's this difference between the sort of text that you write when you're writing normally - like when you're writing out people's names. And the text that you're writing when you're writing the software. And these two things can become conflated. It's just an inherent problem. Because writing is writing and software is software, is writing.

Gojko: Yeah, I mean any writing can be misunderstood by a human or by a machine. And that leads back into what I mentioned earlier. I think in the 70s, 80s, people were automating well known processes. You were automating an accountancy process where there is an accountant that knows how that is supposed to work. So the big challenge is, how do you transfer the knowledge from a person that knows how it's supposed to work, to somebody who knows how to program? Today, my guess is that a lot of the software, maybe more than half is written about - even business people don't really know how it's supposed to work. You're doing this machine learning, artificial intelligence thing that yes, is - benefits fraud. Well, do we even know how to properly detect benefits fraud 100% of the time as humans? Probably not. And automating that makes it really, really problematic.

One of the lovely examples I heard recently that came out too late for the Humans vs Computers book - there was a system in China they developed to automatically find pedestrians when they cross a street outside of a pedestrian crossing. And it was a marvel of technology. They're doing face recognition, they're doing automatic fining. They're sending fines out and when they turned it on, there was a lady that got - I don't know? Tens of thousands of fines the next day from all over China, which is physically impossible. Even if she crosses the same - somebody can cross the street a couple of thousand times in a day and get a couple of thousand violations, but this is from all over China - so you can't really walk there. And turns out she was a model for a advert that was printed on the back of city buses.

Len: Oh my God.

Gojko: And the face recognition software was capturing her face in the middle of a street that wasn't on a pedestrian crossing, and automatically issuing a fine. We can laugh about that, thinking about - well, yes of course that would happen. But did anybody design that system, from the administrators to the police, to law makers, to business people, to software to developers and testers - did anybody think, "Well obviously there's going to be somebody on the back of the bus, we'll recognize that." In retrospect, they should have. But the big question is, how do you know that upfront? And that is one of these unexpected things that happen, and -

Len: Abd of course the data that's fed into systems that then - machine learning systems, for example - can itself have biases. I think a well-known example nowadays is a machine learning system for selecting candidates for job openings. If it's trained on historical data for a company that conventionally didn't hire women, let's - you can say for example, pick a stereotypical company like a construction company. Then what the machine learns is that men are better at this job than women are, and so you should be biased in favor of hiring men if you want to succeed. So just because there are numbers and information, doesn't mean that something's objective or even -

Gojko: Absolutely, and I think I actually have this reference in the Humans vs Computers book. I don't know if I read it before or after the book came out. But there was a serious scientific research comparing face recognition algorithms, concluding that there is a very, very statistically significant difference between the accuracy of the algorithms done in of China, Japan and the Pacific countries on that side, and on the other side, Europe and the US - where algorithms done in Europe and US are much, much better at guessing white people's faces. They don't differentiate Asian people's faces that much. Where algorithms developed in Japan and China, they're much, much better at differentiating Asian people's faces - but they're not as good as differentiating white people's faces. There's two examples - if you are a minority in that situation, like you're black or you are from a native Canadian tribe - then basically, tough luck.

It can be, "You don't have enough programmers to worry about you," and there's just this whole bias for all these models that is insane. And the more we rely on these things, and the more we're using these things - we are going to institutionalize and automate bias. That's what's happening.

Len: Yeah.

Gojko: And whether that is legal or not, is a question for courts, I guess? But it's - I think one of the things that's really going to be problematic. In Europe there is a legal requirement, I'm not entirely sure when it will become law. Probably in a few years, I can dig out the details for the podcast listeners. But about explainability, and justifying the decisions made by machines. So if you are denied a home loan, or if you are arrested because an algorithm said you have to be arrested - you have the right to ask for an explanation. Which, for a lot of these machine learning things, there is no explanation - just pattern matching. Which is institutionalised racism and institutionalised bias. Do people with a flat nose make more parking violations? Well, we don't know.

Len: Yeah, it's a really dangerous world we're going into. Let's hope that the regulation can at least respond, and hopefully even anticipate these kinds of problems. Because notoriously, governments lag way behind handling even - we have something in Canada called the CASL laws, which took years to develop. It's the Canadian Anti Spam Legislation. Something as simple as dealing with email. What should the rules be around who you can email, what should those rules be? It took years and years, and they got it wrong. And then when you talk about things like - there are companies out there right now doing all this machine learning on biased data, and people are getting caught up in this all the time.

You mentioned the courts, and I wanted to just mention something. Just before we started this call, I was going through Humans vs Computers, and you had a great case in there of these two guys who walked into the same sort of shop half an hour apart. And both won the lottery. And it was discovered later that this was because of a bug. And so at the time you wrote the book, the case was not - so then these guys, the lottery retracted the money from the two men. And so they sued. And at the time you wrote the book, this case hadn't been concluded. I just looked it up, and they lost.

Gojko: Okay.

Len: It says, It says, "The anomalous drawings were not legal lotteries, because they did not have the required element of chance."

Gojko: That shows you that a large software multinational corporation that deals with lotteries has probably more money to pay lawyers to it -

Len: Exactly.

Gojko: Than two people thought they won a lottery.

Len: And you wrote about a different case in the book, in British Columbia, where a similar thing happened - but the nice, "We're so sorry" Canadians actually did pay up.

Gojko: Oh, yeah. That is the Canadian thing to do, isn't it?

Len: Yeah, apologize and try to make everybody happy. And so, actually - just moving on - we've been talking for a while now, moving on to the last part of the interview where we talk about your experience as an author.

You started writing early on in your career - not necessarily in such a dedicated way in high school. But after college and during college. And you started writing books at a certain point. I was wondering if you could talk a little bit about how that came about. What was your first book?

Gojko: My first book was called Test-Driven Development with Fitness. I became really enthusiastic about this whole communication aspect of Test-Driven Development. And this was before we knew how to do testing properly in Agile. So we were talking about early to mid-2000s. And there was this wonderful tool that wasn't really well documented. I started documenting it for my colleagues, and the developers I worked with - and then I realized, "There probably is a book in this." And I thought I could give a bit back to the community. It was a tool I could give back to the community by documenting it, and helping other people use it more effectively.

So I started doing that and then I proposed that as a book topic to the Pragmatic Programmers. And they said, "Yes," but then about six months later when the book was finished, they said, "No." Apparently not because the content of the book is bad - I don't even know if that was true or not. But because one of their editors left, and they had to cut down on the amount of the books they were processing. So I don't know if that was a genuine explanation, or whether that was just to tell me that I wrote a really bad book and they don't want to publish it.

But then I was left with this book that was written, but not having a publisher. And there was a significant delay. I was waiting for these things to brew, and I didn't want to do that thing again. I thought I could go find another publisher and wait six months again for them to decide, or I could just publish it. Because I thought - I wasn't even doing this for money, I was doing this to give back to the community. And self-publishing was just exploding on the scene back then. And I realized I could actually self-publish this rather than publish it through a publisher.

So that's where I spent a considerable amount of time building my own Leanpub tool kit, before Leanpub came out, and then built it using XML and Docbook and all these other things. So at the end, I had a single make script that built a PDF and built an EPUB and built a - I'm not sure if I built the Kindle version? I don't think Kindle was out then yet, so - and if it was then I had a Kindle version as well. And I was really impressed with my make file, but it was unmaintainable. So when Leanpub came out I was really impressed. I thought somebody finally figured out how to do this properly.

Len: And what was it in particular about what we were doing at the time, that attracted you? Was it, for example, the ability to write in plain text?

Gojko: Yeah, I think Markdown. Markdown, I never really - it never really occurred to me that I should be writing this in Markdown. I don't know when Markdown appeared on the scene. Writing a book in XML gives you lots of really interesting things, but is not fun. And it's a little difficult to get the copy editor to edit it properly. Where in Markdown now, I write in Markdown and I have a copy editor that edits it directly in Markdown. She doesn't use Git. But I send her Markdown files, she sends me back Markdown files. I put it in Git. It's much easier to work with that as a topic.

Plus, you shortened the whole loop between a book and sales. Where the content between - the first book I self-published, I sold through this online marketplace called Lulu. Which yeah - the turnaround time is interesting if everything works, but if things don't work they were really bad. I once waited a month for them to resolve something, where with you I send an email to hello@leanpub.com and Sunday evening I get the response that says, "Something's happening." I think that was a perfect product for me.

Len: You talk about how you developed your own book publishing process, or book writing process - book file production process yourself. And one of the really interesting things about doing sort of support for a company like ours, is - we're often dealing with people who really know what they're doing. And so often - it's funny, when I talk to authors, they're often like, "Oh, thank you for answering our email on a Friday night or a Sunday Morning," or something like that.

And it's like, "Thank you for providing all these awesome details that help us fix a problem or provide a solution." Because the typical Leanpub author knows - they can see behind what the problem is, if you know what I mean? They can see probably what the cause is behind the problem that they're encountering. And that helps us improve Leanpub for everybody. So when we get these great support requests - it's actually really, really valuable to us.

I noticed that for your latest book, you used our Bring Your Own Book feature. What process are you using now?

Gojko: For this book, I went to a manual thing. So to Pandoc, basically because I wanted to have more control over code highlighting. That was the deal breaker there. I actually wrote it first. The whole book was done in Leanpub, and then I sent it out to reviewers. But when I finished the review version, the code highlighting was not what I needed. And because this book has a lot of YAML examples - and YAML is very finicky and fidgety, and very specific in terms of line breaks. I had to get line breaking in code examples done very reliably on all platforms, because I wanted to be able to refer to a particular line in the text.

So I converted it from Leanpub Markdown to - basically just the code examples got converted to what Pondok understands, and then I could build my own filters. Pandoc - one of the loveliest things about Pandoc is Pandoc allows you to build a script that's part of the build processor. You can replace parts of Pandoc. So I could build my own code highlighting engine for the book, that was where - I assumed getting you to do that specifically for this book was a bit too much to ask. But yeah, even in that case, I used Leanpub as a way of getting the book - a lean part out through the review process. And then the final layout, I wanted to have more control of.

Len: Okay.

Gojko: Which is very similar to how I did - with my other books, I would do a Leanpub version to work on the text and then give it to a graphics designer and work with this brilliant graphics designer called Nikola Koracz who does all the layouts for all my books. And then he would properly do it in InDesign. And we always have a printed version of a book that's professionally laid out. Instead of working with Nikola this time to do the professional layout - I actually used a machine laying out thing. Primarily because I could build my own filters for that. And so, maybe there is some feature for Leanpub authors there later to build their own plug-ins.

Len: Thanks for sharing the details. We really appreciate that. One of the canonical uses of Leanpub is to use our own book writing workflows to write and publish your book in-progress, if you want to publish in-progress. When you're done writing - then if formatting is very important to you, which it is for many books, and authors tend to be sort of particular people sometimes as well - and so a canonical use of Leanpub is actually, when you're done writing your book, to transition to another book production workflow. Like, take your manuscript and use InDesign, or something like that.

Gojko: Yeah, that's how all the 50 Quick Ideas series books were done. That's how Impact Mapping was done, that's how Humans Versus Computers weas done. But for this particular thing, I - because there's so many code examples, I wanted to import them from a source code file rather than - the source code files, so that I can make sure they're right. And that's why, in effect, I was using the Leanpub workflow for that. So as the book was being written, we used Leanpub - but then I converted the source into the final version using something else.

Len: My last question about your books, is one of the things that makes them so delightful is all the wonderful illustrations.

Gojko: Yes.

Len: So who does the illustrations, is that you?

Gojko: There's a guy I work with called Nikola Koracz. He's a Serbian guy here, an absolutely wonderful designer - and he does all the illustrations for all our books. I met him through a friend who runs a branding design agency. When I was a lot younger and I had a lot more free time, I tried to draw a bit as well. And then when I wrote Impact Mapping, I wanted to put some illustrations there and I drew, I don't know? 50, 60 illustrations. And I put it in a PDF and I sent it to this friend of mine, and I said, "Look, I can still draw. I didn't completely forget this." And he replied saying, "Well, maybe you should give this to a professional."

And I said, "Okay, fair enough. So find me a professional." So he put me in touch with Nikola, who did some contract work for him. And Nikola is absolutely amazing. He understands exactly what we need to describe, and has this whole visual language. And I think - luckily, now, he almost became associated with our books. So people can recognize those illustrations. And I think that's wonderful. So yeah, he did illustrations for the Serverless book as well. So there will be some really, really nice illustrations there.

We actually had a quite interesting, I guess, political discussion there, what to do. Because especially for Impact Mapping, and there is some truth to that as well - we occasionally get complaints that there's not enough diversity in the books. Like, we're not showing enough people from diverse backgrounds from them. And obviously we're not doing it the right way, but whatever we try - people still complain.

So my mission for this book is to also do an experiment. Like, how do we avoid this whole thing? And the conclusion was just don't show humans. Which is really problematic because, from my early magazine working days and from my book editing days - I know that humans like to look at humans.

Just having illustrations is problematic. So we decided to personificate this thing, and we created this bee that is in all these situations, that looks like a human - has two legs, two arms, and things like that. But there's no white people, no black people, no - Just, it's a minefield. It's impossible make everybody happy, and I don't have to - And it's a shame. I value diversity, but it's a minefield for somebody who's an author. And especially illustrations need to be illustrated. They're not supposed to fight a political war, but we seem to be a period now where it's - That the best thing to do to avoid complaints is just avoid the whole thing at all.

Len: Yeah, actually, thank you very much for talking about that. This is - I mean, you're not alone - of course, in this. The fights over emojis and things like that are something that everybody will probably have heard about, with respect to diversity and things like that. Did you - and I don't mean to make light of it - but did you ever see the show, "Community"?

Gojko: Oh, no. No.

Len: There's a relevant joke about their school's mascot that I can send to you and probably link to in the transcription -

Gojko: Okay.

Len: Which you'll get right away -

Gojko: Yeah.

Len: But it, it's a genuine problem - both for people who are creating content and for people who are consuming it. Because at the same time as one person might want to see more diversity, and particularly people like them represented and things - when someone goes about then visually representing them with respect to the characteristics that they want to see, sometimes those then get represented in a way that they don't like. Or that other people might not like, if you know what I mean? And then it can be like, "Well, okay, so you depicted -" Say, this person is Asian - but if then, what the role that that identity is then mapped onto, might be something that people then object to having that identity mapped onto. If you know what I mean?

Gojko: Yeah, exactly.

Len: It's just like - and it's inherently fraught because, like, "Oh, woe is me," like as a creator, "Why am I subject to these complications?" It's because the whole thing in real life is fraught.

Gojko: And it is, it is a very complicated topic. But like I appreciate the topic is quite important. But it's very distracting from the message that I want to have in - If I'm writing a book on serverless programming, I'm not writing a book on cultural diversity in the world. And if the illustrations are there to provide support for the book readers, if they become distracting - then it's missing the point. And the problem is that it's very, very - as an indie author, where everything is coming out of my own budget, it's very difficult to fight bigger political fights at the same time as they're delivering the important technical content. And I - my solution is just - for this book, my solution is just don't even try to get into that. So we'll see. We'll see if people complain that I have too many bees and I don't have enough wasps.

Len: Yeah.

Gojko: Or -

Len: Well thanks, thanks for being willing to talk about that. This is something that I think - I mean, people producing content of any kind all over the place all face. And we don't, we don't really talk about it enough because it is -

Gojko: And the problem with - If you look at any illustrations, illustrations need to support the content, and very often resort to stereotypes. Because stereotypes are easy to recognize, they're supposed to be recognizable. But then at the same time - as you said, putting people in a stereotype situation might be offensive. And, that's why I guess now I have a bee.

Len: Yeah.

Gojko: Bees still don't have political activism. We'll see with machine learning if that's going to happen soon, but -

Len: Yeah, that's true. That's true.

So, the last question I always like to ask in these interviews is, if there was one thing we could fix for you on Leanpub, or one thing we could build for you, what would you ask us to do? And bracketing what you've already talked about.

Gojko: Well yeah, for most books - asite like Leanpub is just like perfect. Totally perfect. And we talked this about this before the interview, it's like you had my picture on the wall when you were designing the product.

So I think, one problem that I always have as an indie author is promoting the book. And any features around automating promotion and engaging in that is good. But at the same time, there's a whole minefield of GDPR and things like that - that helps prevent people from building features that they want to build. And that is something that, at the same time, needs to be just in place.

But yeah, in terms of this particular book - I would perhaps, be more flexible in terms of code formatting and line breaks and things like that - is an interesting thing. And I think programming language-wise, that probably is something that would be useful for other technical authors as well. There are a lot of Leanpub books with a lot of code.

Len: Yeah.

Gojko: And a book as a physical medium is, is relatively narrow - not wide, so you can't really fit a lot of code in. But at the same time, line positions sometimes are important.And for me, for this particular thing because of a lot of YAML - line positions, line numbers were actually quite important.

Len: Okay,. Well, thank you very much for sharing that. We really appreciate it and, and please don't hesitate to email us and ask us for anything.

Gojko: I will, I will. You know that. I do that all the time, yeah.

Len: Because you never know - and we always, we really like to hear about - I mean, even if we can't, or shouldn't do what people want, we do like to know what it is that people want.

Well, thank you very much, Gojko, for taking the time to do this.

Gojko: Thanks for inviting me to do this.

Len: And I should mention, you're doing this late at night. I think it's about 12:30 in the morning where you are in Belgrade right now.

Gojko: So it's one 1:37 in the morning.

Len: 1:37, okay.

Gojko: That's -

Len: Well, thank you very much for this. We really appreciate it. And thank you very much for being a Leanpub author.

Gojko: Well, thanks for creating Leanpub. You've made my work significantly easier.

Len: Okay, thank you.

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