066: Xp, CI, CD with Jon Barber
Hello there. You're listening to go podcast. I'm Demnique Saint Pierre. I'm a software engineer. I've been, you know, I've been doing a lot of things in in my life so far, mainly trying to build a software as a service in the last, I would say, fifteen years or so.
Dom:I've been I've been writing Go since 2014 and I have a hard time doing any any other languages these days because Go is so so nice after all. Even even, you know, even with all the boring stuff and verbosity and things like that, it's still it's still great. We will have an interview today with John Barber. We will talk about XP and CICD and things like that, and you will see. It's a it's a great it's a great interview.
Dom:And don't forget to join the go podcast channel if you can, if you are on the Gopher's Slack community. So if you are not there, there's a link to join on the gopodcast.dev website. If you are there, well, the channel is go podcast. No space and, you know, just one shot, go podcast. I also have my my course that I launched two weeks ago, zero to Go For.
Dom:If you want to check that out, if you are starting with Go and want your fundamentals covered and whatnot, there's a generous discount on the show notes, by the way, for listeners of this podcast. And there's always the Patreon subscription if you want to to chip in and support the show and things like that. As you might imagine, it takes times. It takes takes money and things like that to, to do a podcast. And on that, I will leave you with the interview with John.
Jon:So hello there. So I'm with John Barber this week. So thank you, John, for, you know, accepting the invitation to come to the podcast.
Speaker 3:Oh, my pleasure. And I'm really looking forward to it.
Jon:So like we always do, I always ask, you know, guests to introduce themselves a little bit. You anything that you want to to give as information is is you know, it's it's up to you. Usually, I'll I, you know, I like to to focus on the technical aspect and a little bit how you discover Go and things like that, you know, if we if we can stay in in that realm. And from there, we will start the discussion.
Speaker 3:Sure. Okay. So My name is John Barber. I live on the South Coast in The UK in a great town or city called Brighton. And I've been a software engineer professionally.
Speaker 3:I getting paid for it for over thirty years now. I did a computing science degree at, Polytechnic and, then, yeah, was a software engineer. And this was before the Internet really, I think it was around, but I hadn't really taken off, then it took off. But I'd say very much I I'd say I became of age as an engineer really with Java. So at college did c then oh, we started with Pascal and did c, loved c, did Unix, then did c for a couple years after graduating.
Speaker 3:Then Java came along, and I managed to avoid c plus plus because I thought it I read about object oriented oriented programming and thought that's way too that's beyond me. I couldn't understand it, you know. So I just kinda like, oh, I'll stick with c. I like c. I get it.
Speaker 3:But then Java came along and I managed to understand a little bit about object oriented programming, I think, with Java and, really loved, I was a huge fan of Sun Computers as was, RIP. Their engineering was superb. Loved Java. You know, loved the new thinking that came along with it at the time, and spent quite a lot of time with Java. I think I started with Java 1.2.
Speaker 3:Yeah. I did Java for a long time. And as both an employee and then as a consultant, helping other teams to kind of like solve problems together. And because alongside Java, the kind of thing I I found and really loved was continuous delivery and I guess extreme programming. And so that's the kind of mode that I've spent a lot of my late years in it as an engineer with.
Speaker 3:And but and as part of continuous delivery, that I I joined another consult a certain consultancy when DevOps started being a thing. And and like I say, continuous delivery I loved. And it seemed to me at the time, platform engineering or DevOps was a way to really help teams magnify their impact. So I moved a bit more into platform engineering, so infrastructure as code. I'm initially with chef and tools like that.
Speaker 3:Because I've always loved as well as writing software, understanding how the systems work. And that's how I kind of came across Go because initially, all the tools or a lot of the tools are written in Ruby or Python. And then we started using the HashiCorp tooling a lot initially with Vagrant, which I think I'm right in saying is Ruby based. Really? Wow.
Speaker 3:I think. There's a really interesting essay written by HashiCorp guys about how painful that was for them. Having to support that across Windows, Linux, you know, it was just so that's what inspired them to look at Go. And, so then I think I'm I'm right in saying all their tooling from then on was written in Go. And so that's when I first kinda came across it with Terraform and what have you.
Speaker 3:Obviously not writing it, but just being aware that it was written in Go. And then just starting to yeah. Just kinda like as you do. I mean, I've been using Java for a long time. Thought, oh, it's good to learn new languages every now and then.
Speaker 3:So I started learning Go and just really fell in love with it because, again, what caught me was the freshness of thinking again that came with Go as opposed to Java. And it's very much got its kind of you can see its roots in c, which isn't surprising given the authors. But it's got very much got that c Unix kind of feel to it, which I really love, you know. And also just just the just the speed of working with it, know, the the the speed of of feedback with tests and yeah. And so now and so I've been working with Go for seven or eight years, and and it's my default language of choice.
Speaker 3:I just, yeah, just love it and really really enjoy working with it.
Jon:Nice. Yeah. There's there's a lot of things that we we could unpack. I think I think I will need to restrain myself. First of all, it's it's rare that you see someone that says that, you know, you hear the word love and Java in the same sentence and it's
Speaker 3:Oh, it's well, that's well, that's an I I and huge respect to the Java community and, you know
Jon:Oh, yeah.
Speaker 3:It it it you know, it it it changed it changed the engineering world. But recently, as the company where I am at the moment, I try as much as I can to write in Go. But a lot of the systems we have are Java based. Yeah. And I haven't written Java in anger for quite a few years now.
Speaker 3:And I go back to it now and it's so interesting. You know that feeling of something you did an awful lot of, but then you don't do it for years and and you go back and it's like, oh, wow. It's like and so now it's kind of now it's hard for me to understand how I feel about it now. Is that because I've changed or the language has changed or is it both? Or is it you know, and especially given the ethos of Go, which is kind of like I'm sure you've heard that joke, right, which is, you know, in in languages like Python and Scala and what have you, there's 10 ways to do a problem.
Speaker 3:Right. And in Go, there's like point eight. You you know, you've you've always got a kind of, you know, you're always kinda like, oh my good lord, gotta write a set again. Oh, yeah. Okay.
Speaker 3:Map a boolean to string to boolean, you know, whatever. So going back to Java now, my overwhelming impression is and again, I could be doing it wrong, all due respect to people who do it for a living, but it's it strikes me as there's a lot of magic there, especially with the annotations. It's kind of like it seems a lot of the expertise now in the Java world to be effective in that world, you really have to know what the annotations are all about because there's so much pulled in through that. Mhmm. But like I say, I could be doing it wrong.
Jon:Well, yeah, it's a language I haven't dabbled much, to be frank. And and you say you you you say something about Pascal. So I I came I came across Pascal basically with with Delphi. Yeah. And I really, really, really enjoyed that Yeah.
Jon:Time. That was I I was extremely junior programmer at that for that. I was still in in school learning my craft basically
Speaker 3:Right.
Jon:When I yeah. The Delphi five and that that that that to me was crazy, the idea of being able to build a well, when you think about that, when when we build a binary with Go, Delphi was doing that, you know, in in in the nineties at the end of the year. That that is still crazy. You could you could build this this executable on your Windows machine, and you could distribute that without any dependencies. That was extremely nice.
Speaker 3:I I I never had the pleasure, but I've I heard, you know, for a long yeah. I remember mean, I haven't heard it for some time now, but I remember back in the day, people who'd used Delphi, that the that was a very universal love for Delphi, you know. People seem to really enjoy using it. And I remember, as you were saying about actually being able to build something, I mean, I started off before, you know, before going to uni, with, like the BBC microcomputer and similar, you know, like ZX Spectrum. So writing stuff in in basic really.
Speaker 3:And I and, you know, it's just interpreted. And I remember going to I remember my first first year at Polytechnic. Yeah. Pascal was the the language we learned from in the first year. And it blew my mind, there were no line numbers.
Speaker 3:It's kinda like, how what? There's no line numbers. How can that possibly work? And then that was but that was still interpreted on like a mini computer. But then then we yeah.
Speaker 3:We moved into c and Unix. And I think the first thing we did in c was write a device driver for Unix, which was like and that's when we first got this idea of everything in Unix is a file. And like, oh, yeah. That really works. And and then they our professor, he introduced us to Minix because I think we're studying the Tannenbaum book, you know.
Speaker 3:And so we got Minix and installed that on a had an Amstrad PC and installed Minix. And he was like, this is amazing. And I managed to get another friend to log on to my PC the same time I was logged on to it through a serial TTY lead. And that was kind of like, this is just magic. What do mean there's two people using this computer?
Speaker 3:This is just, I just can't cope. And and we I think we also managed to get the it might have been the very early GNU c compiler and, yeah, actually built a binary, which again was just this is just witchcraft.
Jon:Oh, yeah. Yeah. Yeah. That that was the that seems to be probably five or seven years before I start all of this. I I started in basically 1998.
Jon:Right. 1999. My first job was in 2000. So yeah. And and just just another parenthesis, I I I I thought I I call I I I would call it Delphi because it it was in my time in my life where I was not talking in English, so I I always call it Delphi.
Jon:In French, it's Delphi. So I I thought, well, it should should be Delphi. Hearing you saying that, maybe it's because you're you're from The UK, but, yeah, it's a it's a made me smile.
Speaker 3:Right. Good.
Jon:So we we came across yeah. We there was the the the there was something that happened when I talked about Docker and Punnen recently. And
Speaker 3:Yeah.
Jon:We we were on the Slack, community, and and it was very interesting. So let's let's jump into that discussion. I think we will have a lot to to unpack. But first of all, I'm very curious to because I I heard you say CICD in your story, and it's it seems to be early, very, very early. You know, you you were you were working with Java and things like that.
Jon:So I'm I'm pretty pretty interested. Oh, yeah. How it happens in your life because you you seems to to have been a precursor in in that in that world.
Speaker 3:Well, I was I was lucky. So I was it was in the early naughties, the early two thousands. And I was working at a company lastminute.com. And it was a great place to work. Lots of really interesting people working there.
Speaker 3:And also the travel sector is just a great place to work because generally speaking, people are really happy because people are going on holiday. So you know, generally, it's a nice place to work. It's and last minute was a great interesting place for lots of reasons. And it was the height of the .com boom and all that kind of good stuff. And when I was there well, you probably remember, nobody cared about making a profit.
Speaker 3:Right? Yeah. It was it was great times. So it was all about eyeballs. So oh, yeah.
Speaker 3:There was I learned a lot at lastminute.com and had a lot of fun. I was really lucky there. One of the many reasons was that I'd applied. I was a I think on my job title is software engineer. And then they started using the title architect.
Speaker 3:So I applied to be one of the architects and I didn't get it and I was kinda so disappointed. But my line manager at the time, he was really great guy. He said, look. He said, yeah, you didn't get it. He said, but don't worry about it.
Speaker 3:You know, we'll see. He said, but look, I think we've just been acquired by a North America company in Texas. And and they'd arranged for a training course with Robert Martin in No way. Yeah. Oh, yeah.
Speaker 3:No Yep. And so as a consolation prize, I was flown out to New York and spent a week learning TDD with Robert Martin. No. And and at this point, I had no idea what TDD was. I mean, I knew what unit testing what, you know.
Speaker 3:I think I think j unit was out. So I went on this week with Rob and mine, absolutely blew my mind. It really did. I mean, he's a larger than life character. I, you know what I learned on that call, it was like this is yeah.
Speaker 3:It was amazing. Had a had a ball and and came back and yeah, TDD became my thing. Really loved it. So started reading about Kent Beck, all that, you know, all the the the great stuff. And yes, I guess that was my first taste of XP and that kind of ethos.
Speaker 3:And then later on, I really wish at the time again, I had I've never been very confident as an engineer, which is why I mentioned before about, you know, being scared about o o p and c plus plus. And can you can you hear my dog barking? I do apologize.
Jon:Yeah, a little bit. What
Speaker 3:was I saying? Yeah. So later on, I wish I'd applied earlier. But later on, I was lucky enough to get a job at Thoughtworks. But that was many years later.
Speaker 3:But that's that really cemented the XP practices. And because that was very much in the bones of the company. And although I think when I joined a lot of the early movers had moved on. But that really just built on top of that as well. So and it just, yeah, it just that whole kind of, I think for me, what I like about all that is that it's XP is one of the agile practices which really emphasizes engineering discipline.
Speaker 3:Whereas some of the other agile approaches, I think I'm right in saying don't even mention engineering practices. Right. It's more kinda like, you know, organizing work, which is fair enough. But yeah, that's why. And I think at heart, I'm I'm an engineer and I love that kind of just doing good engineering, you know, because it it yeah.
Speaker 3:It's it's very pleasurable and it can make a big difference.
Jon:Well well, yeah. I'm I'm, very, speechless at the moment. Yeah. I I remember I've I've I read a couple of book. You you mentioned Ken Beck and things like that, you know.
Jon:But I can imagine that attending a, you know, a session with, with with Robert and things like that. Tell me if I'm wrong, but since you were that early in in that in that, space and whatnot, you might have encountered a lot of places after that that just didn't do much. Yeah. So it did must have been have been hard for you.
Speaker 3:Oh, yeah. Oh, yeah. I mean, so I think I think I think there's probably it's a standard kind of curve for engineers in that, you know, whatever the practice is as you go through kinda like maturing as an engineer, you kind of there's a particular thing that you learn and you love it and it really makes a difference for you. It might be TDD, but it could be anything. It could be a language.
Speaker 3:It could be an operating know, just just something. Right? And then you become evangelical about it. Right? And and and you just you just and then you get angry and you don't understand why other people just don't get it and, you know, and and then, you know, you you you you know, you just yeah, you just you just really get yeah, you just get really emotional about it.
Speaker 3:And then after a while you realize, you're not going to persuade anybody or or rather than that, I think I think that well, that's what I I think the only way you can really persuade people is to pair with them and show them. Right. Say, let's try this thing. And and in fact, yeah, I mean, nowadays, kinda like kinda like answering your question. I I think and I've heard a similar thing from other people who I work with.
Speaker 3:Nowadays, we don't even talk about the thing in the terms that they were called because some of them become trigger words like even agile. Right? Becomes such a a trigger word and it's such a shame, you know, because what it originally was. And it's partly I think Martin Fowler's coined a term called semantic diffusion. And what if I'm right, what that means is the term over time becomes almost opposite of what it originally was.
Jon:Right.
Speaker 3:Right. It's just one of those weird things about humans. And you know, and also I saw something recently as well somebody saying, it's really hard to explain to anybody why a practice works and you'll get so much pushback. I strongly believe the only way you can make your case is sitting with somebody and doing it together and letting them make up their own mind and not even talk about this, not even use the terms that you're using. But yeah, the it was it was so much so much waste and so much time wasted with people or or other engagements where people wouldn't do the thing.
Speaker 3:And I remember again with the various consultancies I've worked at often almost invariably, you know, we'd be hired by the c level execs to go in and try and make things better. And we'd land on the ground and invariably we'd be told by somebody that the techniques that we wanted to use, there's no possible work that way they could work there even though they work everywhere else.
Jon:Yeah. So
Speaker 3:it's kind of like, well, you you're you're paying us an awful lot of money for this and it really does work. Should we just give it a go? But, yeah, it was, yeah, it was a bit frustrating sometimes.
Jon:Yeah. Totally. So I I guess this might be one of the reason why you decided to start your consultancy at some point and and put yourself into, you know, into the shoes of, you know, I I can help a couple of teams get better at Yeah. Software engineering processes.
Speaker 3:Yeah. And and Because because yeah. And I think and also it's addictive in the sense that I think most engine I think most people most people wanna do a good job, not just engineers. Everybody wants to do a good job. No.
Speaker 3:Very few people. I don't think anybody works up thinking I'm gonna do a really poor job or just even a mediocre job today at my work, you know. And so the the best time, some of the most rewarding times I've had have been like just sitting with people and they get excited. And it's kind of like Yeah. Just get out of their way.
Speaker 3:They got so excited. And one of the most rewarding times was we were at a particular customer and we paired with a team for like we embedded with a team, so it's fiftyfifty their people and our people. And we did a chunk of work for about six to eight months. And we were talking about continuous delivery principles like pipelines and TDD and all the XP practices. And anyway, we rolled off as naturally the engagement came to an end.
Speaker 3:But at the time, there was a conference run-in London called pipeline, which was a continuous delivery conference. It was really, really good, really enjoyed it, really sad when it came to an end. But I remember going to pipeline later on in the same year maybe. And two of the engineers from the customer walked in. And they'd and that was amazing.
Speaker 3:And they said, you know, all the stuff we told them or most of the stuff we told them had really they well, it's all it's credit to them. They've made it work for them. Yeah. And it really made a difference for them. And they've chosen to spend their limited budget, learning budget on coming to this conference.
Speaker 3:And that to me was was brilliant, you know. Nice. It made it made a a big difference for them. So that was great.
Jon:So what what, you know, what have you seen that was kind of recurring in in a couple of clients that you have done consultancy? You know, what what was the main or what what have you seen that was kind of returning and maybe was an an easy fix or or an easy adoption, you know, things that were not showing any, you know, repulsion from the team and things like that?
Speaker 3:Oh, okay. Well, I think some the the I think the main one is getting people to talk to each other. Problem. Seriously. I mean, we would go in not so much engineering, but we'd select when we work on.
Speaker 3:So when we get hired to, you know, go in and do a piece of work for the customer. We do workshops to start off. So we'd have, you know, discovery and we'd we'd work out what we're gonna do and define what we're gonna do. And, so we had a handful of techniques that worked really well, to run workshops and to, you know, get people speaking to each other. But none of it was secret.
Speaker 3:It was all everything we did was publicly available. It was blogged about, know, it was no there was no secret sauce. And invariably, we'd get, you know, we'd get, stakeholders from different departments in the same room. We'd just use a few of these techniques to get them speaking to each other and just prioritize stuff and everything. And at the end of this, every single time, they were all kinda like, this has been amazing.
Speaker 3:This has been great. And it's kinda like, you're thinking that's I mean, you're thinking, yeah, it's great. It's great for us. But honestly, we all we did was we we put down a bit of a framework and we let you people speak to each other. And it's kind of like, you know, only you did this, you know, you'd save yourself so much money.
Jon:It's a bit sad to hear. Well,
Speaker 3:it is. And also the other one would we would be often we'd go into and we'd kind of like, you know, there'd be issues and we'd sit down with engineers and we say, okay, so what's what are the problems? And they tell us and we go, yeah, okay. Yeah. Yeah.
Speaker 3:Okay. We can see that. And then we go and speak to the c levels and say these are the problems and they go, oh, yeah, of course. And because we were the expensive consultants, they listen to us. And they didn't listen anyhow.
Speaker 3:But at more kinda like macro level at the sorry, micro level, kinda like the teams. Well, again, not speaking to each other. So I think that's just kinda like we've got a myth in software engineering as a lone hero. Right? Of of we've got to do our stuff by ourselves and, you know, just people kinda like putting headphones on, coding away furiously in the corner.
Speaker 3:And and yeah, it's it's it's an interesting one because pairing is one of the practices I think can be hugely a huge accelerate accelerator.
Jon:Mhmm.
Speaker 3:However, I do now appreciate that it's not for everybody, you know, that we got to we got to be very mindful, different people work in different ways and not everybody it's really hard work. It you know, it needs to be done well. And I think one of the problems with pairing is often it's one of the practices where you really benefit if people have if you're pairing with somebody who's done it a lot before because otherwise if you come cold to it, it's really hard, it's really tiring and you could really be put off of it for life. So I think just collaborating with a pairing or talking or that kind of stuff, that was a really powerful one. And then I'd say the big one really for me, given no surprise with TDD, is is testing and approaches.
Speaker 3:Or rather thinking when you're writing a thing, how can this thing fail? Or rather, what's the best way we know if this thing is what's the fastest way we know that this code works and there's any problems? And just putting a bit of thought into how how you can do that.
Jon:Yeah. Yeah. That's interesting. So yeah. Pair pairing is a is a yeah.
Jon:It's a difficult topic for have you seen that with people going remote? Strangely enough, you know, where pairing should be, you know, potentially more easier Mhmm. But maybe less enjoyable? Less you know, you're not getting as much? Have you have you seen that?
Speaker 3:Well, that's as you say, ironically enough, actually pairing works works really great remotely. There's some fantastic tooling out there to I think some of the best pairing experience I've had has been doing it remotely. And because there's yeah. There's free software out there that's really great. We use we use a software called pop to share our our desktop and it's really nice.
Speaker 3:It's You can share just sections of your screen and then there's a fantastic tool called mob. Sh which is all about working effectively with with git and being able to very rapidly ping pong between two people. So you can very easily, you know, swap between who's driving and who's observing. And I think that works really well better than sometimes being side by side with somebody because often you've got to put more thought into the tooling when you're remote. Sometimes you go, oh, we're just next to each other and often it gets a bit clunky about, oh, do we share the keyboard?
Speaker 3:Do we share the mouse? Know? And so yeah, I think doing that remotely often can be better. But but yeah. Well, you could but similarly, you've got to be mindful about
Jon:how people wanna work. Oh, yeah. Totally. Totally. So would let let's continue with with pairing, for example.
Jon:Let's, let's would you have would you have a quick a quick recommendation? Let's say let's say there's someone that is listening that are not doing that at the moment with ins inside their team. How how do you how do you bring the pairing mindset to to a team? You know, is is it is it like something you should try to start doing that like twenty minutes per week for, you know, to start and things like that? What what are the tricks?
Speaker 3:That's a really good question. And it's context so that's a really good question. I think one of the things to get over I think one of the things that makes people nervous about pairing is a feeling that everybody else is really good at what they do and those and you'll be revealed as a fraud. So I think what can make it more comfortable is if you can see that that's not the case. That everybody everybody just everybody makes the same mistakes.
Speaker 3:Everybody's, you know, we're all the same. So for example, one thing you might consider that we did early on that particular engagement where the some of the team came to the conference later on.
Jon:Mhmm.
Speaker 3:We actually it's easier if it's a new chunk of work you're working on, you know, a new project or something or a new or a new feature or whatever. But we started off by mobbing. And So we got everybody in a room and we followed the mobbing kind of like general approach, which is so we choose a task to work on as everybody. I think we had about six or seven people in the room. And the idea would be, if I remember correctly, we we chunk cut it down into like five minute chunks or maybe ten minutes.
Speaker 3:And the idea would be one person would have the keyboard, so they'd be typing. Another person would be the driver and they would be asking the person with the keyboard to do things like write a function that did blah blah blah blah blah. And then the rest of the room could think out loud or give suggestions. But the driver was the person who would, you know, work out what was done next. And at the end of the five minutes, it rotated.
Speaker 3:So it went around the room. Now that was extremely intense. It was I mean, we came out of that we came out of that room. You gotta remember, it was fifty fifty our team and the engineers of the client. We didn't know each other that well.
Speaker 3:But it was amazing for working out how we're gonna work together.
Jon:Right.
Speaker 3:It was kind of like, you know, that is it storming, norming and forming phrase, I think, about teams? It accelerated that. So it was extremely intense. I mean, there were sometimes we came out and it was like, we really need a break because it got pretty you know, people could get really uncomfortable in there. But it worked really well in the end and we came out with an understanding about we're all equally idiots.
Speaker 3:We all make mistakes. Yeah. But also we did some really cool stuff. And this might work. So that kind of like gave that confidence to then let's give pairing a go.
Speaker 3:And then so what we did around that, again you can have as much structure as you want. But you can set down things like, I think the main thing to be aware of is it will be extremely demanding. Be kind to yourself and the person you're pairing with. Maybe just try it for twenty minutes initially. Yeah.
Speaker 3:There's some great resources. I mentioned that app called Pop, but there's a really great app called Tuple. Yeah. T u p l e. And they have and highly recommend it.
Speaker 3:If you can get some budget to spend on it, please just use that. It's really, really good app. They've also got some really good resources on their website about how to pair and some example pairing setups. And I think that their resources are really good. So you could have a look at that because they have some guides about how you might want to set up pairing and some guidelines for going down that.
Speaker 3:So maybe just follow their guidelines and then work out one thing that I think they mentioned on their site, which worked well for us initially, especially if you're doing TDD would be ping pong TDD. So that would be, you know, as you're going through the cycle, so you start with a failing test. So one part of the pair writes a failing test. Then then the other pair gets a test. So you know, you go red, then the other person goes green, then you go back and you go, shall we refactor now?
Speaker 3:And the nice thing is that, you know, that that works well with the whole going around that wheel. You you've got that nice demarcation. And so yeah. And and the person pairing, they can go, oh, that thing you're doing, I'm gonna when it's my turn to refactor, I might do that little refactoring, you know. And that that can work really well, ping pong, that kind of way.
Speaker 3:And, yeah, just use that's that's maybe a nice way to get into it.
Jon:And am I wrong in thinking that sometimes it's those are ideas are hard to sell to upper management and things like that?
Speaker 3:Oh, Yeah. Okay. Yeah. Okay.
Jon:Are still we are still there today?
Speaker 3:Yeah. We had we had we had one client. It was in the financial services sector
Jon:Yeah.
Speaker 3:Which, as you can imagine, are quite can be very careful about their money. And I remember one of the managers came up to me. We'd been on-site for maybe three or four weeks and we were pairing and he just came up and he just said, you know, he came up with the standard thing about, well, you know, two engineers working on one thing and half is productive.
Jon:Yeah.
Speaker 3:And so you've got to you've got to, you know, there's some really great resources out there about explaining, you know, well firstly, programming isn't a typing problem. You know, we're not constrained by the rate at which we type. Yeah. It really is a thinking problem and but again, you can make all those arguments. But again, some people just don't buy into it.
Speaker 3:So, yeah, you've just got to, Yeah, it's a hard one. You've got to kind of come up with some way to maybe measure the gains you get from it. But, I think I'm right in saying the studies out there on pairing are some are pro, some are con, you know, it's it's it's a hard one.
Jon:Yeah. Oh, yeah. Yeah. Because yeah. My myself, I I've been I've been more of a a Bootstrap founder in in the last fifteen years.
Jon:But before that, I was I was still working in in smaller companies, and I remember that back then, it was it was it was pretty it was even hard to to sell. We should we should we should write tests before we write code. Even even just that. For, you know, on on smaller companies I'm talking about, I thought I thought it was a little bit easier. But but yeah.
Jon:Let's let's return a little bit to our good old friend, the the continuous integration, continuous delivery. So you have some pretty interesting opinion, I or at least sensation about Docker, and and I'm really really interested to to hear them. So first of all, I I will I will first by start by saying, to me, when when I discovered Docker at first, it was it was a game changer. I started my professional career with Visual Basic six, And the dependencies for the dependencies challenge for you know, even for the software engineer back then, just, you know, creating your development machine, reinstalling what you needed to Yeah. To to make the project work.
Jon:It it was multiple days to to
Speaker 3:Yeah.
Jon:And and for me, Docker was dead at first. For me, it was really like, oh, you know what? Now no matter what I need as as a dependencies, because now now nowadays, my dependencies are mainly services and things like that, and I don't want them to install on my on my machine. I want I want to be be free of that. I always liked Docker, you know, but but I understand that you you might you might have had some some very interesting, you know, experiences and and whatnot.
Jon:So I'm I'm I'm curious to hear about you kind of seems to to say that for even for developer machine, it it might not be the the right the right tools today.
Speaker 3:Yeah. And yeah. So again, let me start by saying huge respect to Docker. Everybody, it's a fan fantastic piece of engineering. Well, the under the underlying stuff, you know, is Linux kernel stuff, isn't it?
Speaker 3:It's the control groups, all that kind of good stuff. So it's phenomenal piece of engineering, you know, huge respect to that. The thing that I've seen a lot of which does drive me crazy is it's
Jon:kind
Speaker 3:of like a gateway drug for engineers. So in the sense that it does provide a lot of flexibility and but it's interesting. Well, okay. So let's spill back a little bit. It's interesting, you know, so when you obviously, you know, you're you're building your thing that's gonna be deployed into Kubernetes or something that runs a container, a container image.
Speaker 3:And it's really interesting that that just that kind of extra step that the thing you build has to be pushed to a registry somewhere, how complicated that makes life. It's just kind of you know, on paper it would seem so simple and you know, it seems great. But having been on the side where we do the build pipelines as well, it just makes life so complicated. Anyway, that you know that by itself isn't the reason not to do it. But what I've seen a lot of is well, first off, it it you can go down that route of, you know, you got you're using well, first off, it can it it people can go down the route of micro services.
Speaker 3:And then it's kind of, oh, we can run all the services on my machine. Oh, we use Docker to do that. Mhmm. Because it'll be easy. And it I don't think it ever is easy.
Speaker 3:So what I've seen a lot of is and a lot of companies is Docker Compose. And that and these are companies that are running Kubernetes in production, say, for example, because Kubernetes won that particular thing a while ago. Yep. So Docker Compose is just really used to run the things locally. And there's a lot of complexity in Docker Compose.
Speaker 3:There's a lot of cognitive overhead in the team, just keeping Docker Compose working. And it's kind of like, I'd say it's wasted effort because it's it's a dead end. It doesn't leave it's never used for anything other than on the developer's machine. So it's all that extra stuff, and it's it's wasted work, I'd say. Whereas what you're running in production is Kubernetes.
Speaker 3:And and I think really what your time would be better off spent would be why do we wanna run all of these things locally? What's the need to do this? Is it testing? It might well be. You know, it might be lots of reasons.
Speaker 3:But I'd say your time is better off spent working out how to do that not on your machine. So it might be things like moving testing left or right. So where I am at the moment, we're putting a lot of effort into we're one of those places where we're running using Docker Compose in the build pipelines to run dependencies for testing. But what I'm a keen advocate for in this particular context, and of course context is king, is, well, very much, testing in production. So we deployed Kubernetes and one thing, which was already deployed when turned up, we weren't using that much is Argo rollouts.
Speaker 3:So we're using that to basically, canary deploy and slowly shift traffic, but to also run our tests in in the cluster. So we can basically, you know, it's it's that thing about separating deployment from release. So we deploy a candidate into the cluster. We can then run our tests against it in situ. And then if it's all good, we can shift the traffic across.
Speaker 3:And if it's not, then we roll it back. And that's got lots of benefits. And one of the issues with coming back to trying to run stuff in your machine, we're running in Google Cloud and we use PubSub a lot. So there is an emulator for PubSub which people use when we run stuff locally. But the emulator works maybe 9095% of the time.
Speaker 3:But the 5% when it doesn't is such a time suck for an engineer. Know, it can be days to try and work it out. And then there's a great a great fan of a guy called Yan Xue, the burning monk. He does a lot of work in serverless. And I think he's maybe softened his view a little bit recently, but he was very much, look, just run the stuff in the environment you're gonna run it.
Speaker 3:So don't run emulators. Don't run on your machine. Just deploy and run it in the environment you're gonna be running it in. And that was very much the conclusion I came to with PubSub and all that. The emulators, they work most of the time, but a lot of the issues you get aren't so much around happy passers, you know.
Speaker 3:It's around when things go wrong, which is permissions, configuration. That won't be exposed when you run it on your machine, but it will be exposed when you run it in the environment. Right? So Yeah. I would say I can understand my engineers trying run it on their machines because it initially seems like the easier path to go down.
Speaker 3:Because working out how to deploy and run this stuff in a production like environment is hard. But yeah, it's hard. But it's it's one of those things continuous delivery I'd say is about, yeah it's hard but it's engineering and ultimately it'll make life better for everybody. So that's one of the reasons why I'm not such a fan of Docker just because it it yeah. It can be a bit of a a gateway drug to a rabbit hole that can initially seem to save time, but ultimately, it can be a real time suck.
Jon:And when you say you you are deploying your your January version, the the thing that that might be the next production version for this thing, are you saying that you are deploying that in in the real production?
Speaker 3:Yeah. Into the production cluster. Yeah.
Jon:Not not in in a staging environment or whatever.
Speaker 3:I'm sure I'm sure you've been places where staging has little relationship with production. And then ironically enough, we were another consultancy gig for a big commercial bank. And ironically enough, I mean, often you find that the problem was that staging was nowhere near like production because it was much less powerful than production. So, you know, if you wanted to do low tests, it was, you know, just wasn't representative. This particular bank had the opposite problem.
Speaker 3:They were so scared about touching their production system. They'd upgraded staging to a much more powerful set of hardware and later software, and they just wouldn't touch production. So ironically enough, staging was way more powerful than production. So it's kind of
Jon:yeah. Oh, okay. I I I thought you was going to say they they they switched they switched server at some point. Okay.
Speaker 3:No. Maybe they did that. That's a good idea. Maybe they should do that.
Jon:Okay. Wait wait a minute. I mean okay. I'm I'm coming from a fintech background myself. And how can you okay.
Jon:I'm sorry. I can how can you trust something to run-in into production? Something that might touch the database. Something that let let let let let's give me a good example. In in the the last, fintech company I I worked, we were producing, you know, risk score for credit, credit line.
Jon:So, you know, so I I what I'm saying is that there is some dangerous things that can happen. How how can you Sure. Then prevent that from happening?
Speaker 3:Well well, con context is king as ever. So maybe it wouldn't work where if everywhere, which would be perfectly fine. But but maybe it can. So this is where you've got to think about I mean, the the where we'd like to get to would be to be able to do synthetic monitoring. And what I mean by that is, okay, so coming back to that thing about continuous delivery and testing.
Speaker 3:So how do you know right now that your critical production paths that make your company money are working? Or how quickly would you know they're not working? So one way to do that is would be to, you know, fire transactions through your critical paths. Right? Really check out stuff.
Speaker 3:Yeah. Really go through. Really buy stuff. But so so an amusing story, amusing ish. That place I talked about last minute, the travel place, we were we were doing that way back then.
Speaker 3:So we'd the automated testing would go through by a flight with a real credit card. The I think that what we what was in place was the passenger had to be called mister test test. And it wouldn't do the very final, yes, I really want this flight part. It'd do everything else. It'd do the credit card transaction, but it would, you know, a time out, all that kind of stuff.
Speaker 3:Right. And amusingly enough, apparently, folklore has it, I never heard. But somebody changed it to be mister test testing. And apparently, thankfully, all we all the company did was book a whole flight from London to Paris. And had to pay it.
Speaker 3:A whole plane. I mean, we bought the whole plane. But it could have been a lot worse. Right?
Jon:Yeah. Sure.
Speaker 3:But it very much comes down to your domain. And it might not be possible. But what could you do? Is it possible? You know, could is there some way, you know, like, in that particular case with a particular customer name or, you know, could you put a header in there?
Speaker 3:Or is there just some way to flag it and say, put this through the system as much as we can, but, know, don't actually action the thing.
Jon:Okay. So so what what you're saying basically is that you have you have some guardrails around your services all over the place that are capable of recognizing that, you know what, this thing that you're going to run is considered test.
Speaker 3:Yeah. Do it treat it as much as you can. And and if you if when you do this, you end up finding you're writing a load of conditional statements in your code, then that's a smell that this isn't working. It's not gonna work. Mhmm.
Speaker 3:Because the idea is it's gonna exercise the critical parts of your code. Or you and what I mean by that is that the the the parts of the code that make you money. Yeah. Yeah. And if you're if you're commenting all that out, then it's no use.
Speaker 3:Right? It's not just not gonna work. But
Jon:Yeah. You keep saying that the part that keeps money, but there there is still some lesser important part that could mess up a lot of things in the system, though.
Speaker 3:Yep.
Jon:I mean I mean, I I understand your point. I'm extremely interested and triggered at the same time to I I don't know. It's like returning twenty five years earlier to to deploy in production right away. It's a it's it's it's it seems scary.
Speaker 3:Yeah. It is. It is scary. It is. But then what's the alternative?
Speaker 3:It's kind of like it's like all of those things. It's kind of like, why are we doing this thing? And the reason you're doing it is to really just like it comes back to that question. Again, it comes back to that that testing first approach, test driven development, not just in terms of like code on your keyboard, but this thing, this system we've created. And can you prove to me right now it works?
Speaker 3:Or the reverse, how quick do we know if it's broken? Mhmm. And that might be for really critical stuff like you say where it's just not possible and it could well be the case. Then maybe what it's around is observability. And just kind of like having working out a couple of key metrics, a key alert and it's only gonna be two or three because otherwise everybody gets Yeah.
Speaker 3:You know, alert fatigue. It's kinda nobody watches the dashboard anymore. But if we have like just two or three alerts that trigger that kinda like say, look, this is really bad. We're not making money or whatever, then maybe that's the best we can do. But that's better than nothing.
Speaker 3:Right? It's kinda like we can look at that and we can compare maybe this week with the same time last week and see trends and go, do you know what? It's looking it's looking kind of alright. And that's maybe the best we can do.
Jon:Yeah. But okay. So I don't know. Let's say let's say you are 20 or 30 or 50 engineers, and they are all deploying to production. I mean, I I I I don't understand.
Jon:It's how how do you trace exactly and and and first of all, you you were mentioning that you you were going to do a a kind of rethink. So what what happened if, I don't know, 10 people are are pushing the, you know, different code in the same service? I don't know. It it seems it seems very, very, out of my world. Sure.
Speaker 3:Well, so you you may, you may again, it very much depends on the context, but you might what you may want to say is, look, what we're to do when we do a release, we'll so this particular thing we're using Argo rollouts when you do the canary phase, you can pretty much specify how long that that traffic shifting will take, how long the tests are going to run for. And the tests can be things that can be black or white, like what your eye would normally call your test, like, you know, pass or fail with asserts. Or it can be things like Prometheus metrics, all that kind of stuff. So you can different ways of gauging whether things are going well or not. So you could say, look, give it ten, twenty minutes.
Speaker 3:We're gonna watch these critical stats slowly shift the traffic over. And so what you could say, you could say, look, the deal is when a team deploys into into production, then it's kind of like it's theirs for say thirty minutes. Nobody else can deploy. So at least then you know, you know.
Jon:Mhmm.
Speaker 3:Okay. That's looking okay. You know? And so you're still allowing a a fairly decent release cadence, but you're also giving it time to say, you know, something's broken. What what degree of confidence do we need to have to say, oh, it was this release that broke it.
Jon:And is this baked into your CD, the the pipeline?
Speaker 3:It's not something we do, but it's something you you choose to do.
Jon:Okay. Okay. Okay.
Speaker 3:But what's interesting about all this though is I would argue that these kind of things are a forcing function for kind of it's a bit of a bit of a sweeping generalization, but for better engineering practices. So for example, like you say, you know, okay. So maybe you got a couple of teams releasing at the same time. How do you make sure that they don't stomp all over each other? Well, one way to do that is you've got to there's there's various patterns like this, releasing, expand and contract, for example.
Speaker 3:So it might be, you you know, you're you're you're you're making a change where a service for a while has got to accept both old and new data formats. You see what I mean? Mhmm. So it can kind of you've got be it's not it's, you know, Postel's law. Be generous in what you accept and conservative in what you send.
Speaker 3:So you've got to build in stuff that says, yeah, okay, so maybe the things I'm interacting with, they might change or they are going to change. So I've got to build that in for now. And then later on, we we reduce that back down, so that it it only accepts that, you know, what is the standard now. And again, it comes back to teams speaking to each other.
Jon:And how do you how do you couple that with TDD? Because if you cannot really run your test locally while you are developing. Now now if I understand correctly, you kind of need to deploy to run tests.
Speaker 3:Oh, no. Oh, oh, so I do beg your pardon. No. No. You're still TDD ing.
Speaker 3:You still you still have you're still testing the code on your machine. You absolutely are.
Jon:Yeah. So unit unit test, but for any kind of integration test or?
Speaker 3:Well, you you might choose to you might still choose to do that. So you might choose to run synthetic services locally. So you might choose to run copies of your dependencies and things that mimic them.
Jon:Mhmm.
Speaker 3:And so there's things like wire mark or there's a mountebank or there's all kinds of things where you can well, in the more kind of some places what they do when when you've gone down that route of, you know, if these are internal services you're depending on. Some places, the team that creates that service will also create the synthetic version that can be used for testing. So, you know, it'll it'll and that's when you get into contract tests. So effectively, you can run locally their copy of their system, you know, that looks like their system but isn't really, but you know, it's got canned responses, all that kind of stuff. So you can run them quickly locally and you can interact with them locally and get a degree of confidence that it's looking pretty good.
Speaker 3:And we can move to the next stage, which might be deploying it into a production like environment and and doing some end to end tests.
Jon:But you're not running them via Docker or Punman on your
Speaker 3:No. No. Not at all. I I absolutely well, you know my feelings on that. I I would say absolutely.
Speaker 3:Why why? You know, if it's if it's something like mount a bank or something in Go or something like that, you could absolutely just run it straight in your machine without that that overhead of of running Docker and what have you, which often in in believe I'm right in saying especially if you're not on Linux boxes, that's gonna be slower because you're gonna be running, you know, an emulator to run Docker and and etcetera etcetera. And it's all about that speed and you want that feedback quickly.
Jon:Interesting. Interesting. Yeah. Okay. Yeah.
Jon:And then I I I will I will I would love to to see something like that, to be frank. Yeah. I I I you know, don't get me wrong. I I kind of really understand what you're saying. It's just that it's it's, you know, it's it's a little bit unconfirmed uncomfortable to
Speaker 3:to imagine. Of course. And that's the great thing about this stuff. It makes you think. And maybe isn't possible in your particular domain.
Speaker 3:Maybe just impossible. But again, it's kind of like it's always useful to and these questions about how do we know things are working or they're not working and how quickly would we know that? They're questions to ask all the time. Right? They're not things that have solved at any particular you don't solve them forever.
Speaker 3:Yeah. You can continually kind of iterate on this stuff and make things better. And it's just that creativity around that. This might be one approach that that works or it might not. It might not work.
Speaker 3:But but it's it's kind of like the thing about it is as well, especially in the early days of when microservices became a thing, became so popular, it's a lot of the hidden consequences of that decision that people Yeah. Didn't do. And and that's when it gets that's when it can get really messy.
Jon:Although yeah. I think we have we have gone too far with the microservices,
Speaker 3:but yeah. I I I wouldn't disagree with you on that one. Yeah.
Jon:But if your system is not built to do that, you know, the efforts to and the the phrase that you you keep you keep telling, you know, how do you know that your system is is doing the thing that brings money to the company? If if you're not ready to do that, it's still a decent amount of efforts for a team to to, you know, take some, you know, challenges and and think about what they they they need to do and say, it's still a big decision. That's what I'm trying to say.
Speaker 3:I'm sorry. You cut out you cut out a little bit then. Would you mind repeating that? Yeah. Sorry.
Jon:So I'm I'm I'm I'm wondering if it's a hard sell to to have some team, accept to to adhere to to this kind of deployment because their system might not have been done or have been written in a way that it's easy for them to to know.
Speaker 3:Oh, yeah. Oh, no. Well, sadly, that is often often the case, you know, as you're saying, what what patterns did I see? And this is very much one of those one of those it's it's the it's it's like every startup, right? You've got to make money.
Speaker 3:So it's the race to to make money. And these engineering things cost a lot of money. It's hitting that right balance. And it's a really tricky thing to do. And again, that's kind of like you might choose to go down that path, know, again, that term technical debt, which again is another one of those ones I think Martin Fowler with his, you know, semantic diffusion technical debts become a bit over a bit misused maybe.
Speaker 3:But in this sense, technical debt is that one where you it's a conscious decision to make that we're not going to do this thing. Yeah. But that's alright. Because you know what? We've got to make money.
Speaker 3:We're a startup. We can't sink all this engineering effort into all this great stuff, which, you know, which is absolutely understandable. The issue is, know, hopefully your startup will be successful and you know, you'll do really well. And at some point you will hit the point where you really do need to have these things in place now. You know, you need to make sure that you're how yeah.
Speaker 3:How do you know you're making money because you're doing really well, but the complexity is starting to get a bit, you know, off the scale and, you know, and we're finding releases get painful and we gotta we gotta do release trains and all that kind of stuff.
Jon:Yeah. Yeah. I believe when the when the company hasn't released something in six months, they might they might find the the idea not so bad after all too.
Speaker 3:But this is this is the thing. Right? Yeah. Exactly that. Right?
Speaker 3:Or or there's lots of failed releases or the release stuff and and and, you know, and and or the worst thing is, you know, you release stuff and and and then you find out three weeks later via your customers that it's not working. Yeah. Okay.
Jon:Yeah. Totally. Well, very interesting, John. I mean, if you I I I think I think we will need to to end this call. But I mean, you want to return at some point, I that there it's very very interesting.
Jon:Is there is there any closing thoughts that you you want to say to the listeners? Anything we we forgot?
Speaker 3:Oh, just that I'm I'm full of hot air and it's, you know this stuff's kind of worked for me more or less most of the time but again context is king and you know everybody's different but just yeah just pay attention pay attention to engineering, good engineering practices, whatever that means for you. And, yeah, try not to take things too seriously, I guess.
Jon:Yeah. Totally. And again, communication is is always Oh, yeah. Recommended. Absolutely.
Jon:Alright, John Barber. Thank you very much for this.
Speaker 3:Oh, my pleasure. Have a great evening.
Jon:Alright. Bye.
Creators and Guests
