Xavier Gouchet on Developing Performant Android Apps

Steve Westgarth: 0:00

My name is Steve Westgarth, and this is the engineering leader let me tell you a secret, you also write bad code. If you disagree, you may as well switch off. If you've been enjoying listening to the podcast then you might be interested in joining an online community to get to know other listeners and build your network. We've created a Discord server, there's open for everyone who listens to the engineering leader to join. If you would like to get involved, the link is available in the show notes. Down below joined on the engineering leader by Xavier che Xavier works as a software engineering team leader data dog, where He specialises in the development of Android SDKs. Prior to data dog, Xavier has worked with organisations including DISA and work well, always with a focus on Android, you proudly declares in his LinkedIn profile, that he has been working with Android since cupcake, which goes all the way back to 2009. During that time, he is also a very active with the software engineering community teaching. And also speaking at conferences, because a via it's a pleasure to have you on the engineering leader today. Before we begin, can I just confirm that you also write bad code?

Xavier Gouchet: 1:21

I do write bad code, bad code all day long. Yeah.

Steve Westgarth: 1:26

Always. I think we all do. listeners will know that I'm really passionate about iOS. And I guess your My upbringing in mobile is, has been as an iOS engineer going back many, many years. And I've always, maybe not passionately, but I have always avoided Android. So I guess you're well, you're literally the antithesis of all of that you love Android, you've kind of been in the Android ecosystem for so long. Why is Android better? Well,

Xavier Gouchet: 1:55

there's a two fold answer. The thing is that there is a difference with who you're talking to, if you're talking about like your the end users, the people just know just uses a phone, use a phone every day, I think iOS does a better job. Because it's been spending a lot of time making sure that everything is intuitive, everything is smooth, everything happens, you know, very, very fast. And this has been their focus and the fact that they do control the hardware as well as the software enables them to to have this very, very enjoyable experience for the for the consumers. But if you're talking about the developers, the people who are going to write code for those devices, I think that Android is far better. The reason I think that is because first of all, it's open source. So whenever I'm hitting a will, I'm hitting some, you know, weird bug or unknown issue, I can dig into the source code events, read and understand what's happening and fix it myself. Also, Android, as been has had this the same kind of philosophy as line x has been open in terms of your application can talk with any other application that's installed on the device. With the, all the intense with all the permissions that and it's been there for like the first day, as well as being able to adapt to any form factors there is that you can have a screen, a square screen, very wide screen, you can have like, everything happens very easy, because whenever we started having screens with different sizes, the fact that the UI was when you're building your UI and Android, you don't know what's going to be the size of the device you're going to be running in. So you need to take like an it take that into account. And this has been in Android since at least cupcake. Meaning that when the tablets arrived, when the smartwatches arrived, arid was already ready for that they didn't have to do too much to adapt to new form factors. So from a developer point of view, I think this is the this one.

Steve Westgarth: 4:16

You're right in the sense of form factors coming obviously, when iOS first came about when the iPhone was first announced, there was literally one device. And for a number of years, you know, that's all developers gonna have to care for. We're all designing for specific screen size. And it kind of has been retrofitted over the air as we kind of went through auto layout, and all of all of those things, and you're obviously laughing in the last couple of years with the introduction of Swift UI. You know, it has very much been an afterthought that actually we need to cater for different form factors, different device sizes, which I think you're right, your Android users have indicated from your since day one. I gave a talk a few years ago about your user experience and you say there that you're from a user perspective, your iOS is better. I have You agree by the way, just for a moment, I imagine that Android also has a place in the world, there is something about how different different devices, your Android or iOS do things differently. And what I mean by that is, I noticed that when on an iPhone, if you want to delete something, you swipe from the right to the left, you swipe for delete from the right. On an Android device, you typically swipe from the left to the right. And there are other examples of that within the OS. And there's something about your users developing mental models of the way that they expect things to work. And when I tried to devise and use that, I found that really challenging and really difficult, because so many of the things within Android was different, or the opposite of what I would do on iOS. And I think the same is true the other way. So do you think there's ever an opportunity for your for either Android or iOS to win the war? Or do you think that we're kind of you're now kind of set? And I think it's probably about what 6535 sort of split, you're probably in favour of Android in terms of user base worldwide? Do you think that we're gonna stick Oh, could that potentially your swing the other way or, or what, what's next in that space?

Xavier Gouchet: 6:13

What I mean, it's always difficult to to predict the future, but I think we're still going to have like those two major platform sting there, because the, like the Android because it can adapt to any kind of device, it can also adapt to low end devices. And we do need lots of those, we need, you know, very, very small devices that are cheap to make and cheap to buy. Because not everyone can put $1,000 in a phone. And, and also, because, like you said, like the user experience and the way people expect the application to work is going to be different. When you are in an Android or an iOS, and those fields, if you like apply to everything in the ecosystem, one is really tied with Apple and Apple's way of doing things. So you're also linked with your at your iTunes account, or Apple TV, and all those things. And the other one is returning to Google like a sim. And meaning that you're gonna have you do have like those people that are very tied to one or the others. And like you said, it's very hard to change the habits. So when you're checking when you're looking for a new phone, usually you're going to stay in the one that you'd know, instead of going to the other one, unless you've had a very, very bad experience. With the one you're just leaving to Yeah,

Steve Westgarth: 7:38

yeah, and I think you're right. I personally couldn't imagine changing, but maybe one day, you know, maybe we'll give it a go and kind of see see where we end up. But something we do have in common is definitely software engineering. And you've been building apps for years. What What got you into software engineering,

Xavier Gouchet: 7:53

I think it's the, the fact that it allows me to use both my scientific and creative brain. So like, engineering is very scientific in the sense that everything is logical. And the way computers are built, the way programming languages are built, it's very logical, you have, you know, a lot of logical gates, and it's all very mathematical. So it's very, you know, sciency. But at the same time, when you're writing a programme, whether it's like a console programme, or a, an Android application, or whatever, you're left with a lot of creativity in the sense that you know, what you're wanting to solve, you have problems to solve. That's basically what engineering is, it's just you have a product, so you want to you want to solve it with a computer. And, and like for one given problem, you have 1000s, if not hundreds of ways to write code that's going to solve this. Which is why like, we know, we have cold calls all over the internet, and you know, those kind of things. And being able to say, Okay, I'm going to imagine and create from scratch something new, that is going to solve a problem, while using all the sciency. Part of my brand is I think it's it's the best of both worlds. And when I started doing that, back in 2001, it was like, you know, like a revelation that okay, I want to do that for the rest of my life.

Steve Westgarth: 9:20

A question that often fascinates me when I talk to engineers, in particular senior engineers who've been developing for a very long time, is, what was your first experience of good code? It's something I've asked a number of people. And it's kind of that moment, when you realise that, you know, anybody can write code, you can hack something together that will do a job. But not all code is good code is not maintainable. It's not, you know, it's it's not going to do a good job for the application. So performance and all of those things. What was what was your first experience?

Xavier Gouchet: 9:51

I think, okay, it might not be my first experience, but it's the one that struck me the most and I dream For a lot, it happened at Deezer. So music streaming company where I was working on refactoring the, basically the player system, so handling the cue of what track is going to come next, making sure that everything is available on disk and making sure that the music you play one after another. And then basically, I've worked on this refactoring for two to three months, making sure that you know, every step was a unit tested, integrated, tested, and everything was, you know, properly done. At some point, I reached a task, I had to add a feature. And, and this feature was not, was not, it was not a feature that I knew about when I started the refactoring, it was something like brand new, and it's a, we shouldn't be able to do this with the player and so on. And it was so easy to plug that in, from the refactoring I made, like it was, like, just a matter of a couple of minutes, you know, just plugging two things together that I had already built. And it just worked flawlessly. All the unit tests that I wrote for this new feature, like, everything passed perfectly. And it was like, Okay, if I can add this feature, but it was not foreseen in this architecture, it means that it must be at least somewhat good. So it was very, very pleasant experience, because I thought, Okay, I'm going to spend like a week to do this. And in the end, it took like, 10 minutes, though, yeah.

Steve Westgarth: 11:46

And thinking about, you know, maybe junior engineers or people who are maybe you're new to coding continue to programming, maybe haven't your haven't had as much experience in, in development? What would you say to them to help them to, to recognise yo, that the code they're writing, yo, is maybe not good on your needs to be improved? Or, you know, what is the what is the bit of advice you would give to somebody to say, this is how to make your code Great.

Xavier Gouchet: 12:15

Hmm, that's a good one, and how to how to recognise bad code. That one is very difficult, because like, even today, I do write bad code. And I when I look at stuff I wrote, like, six months ago, I'm still cringing. So it's always hard to find bad code, because your your, your own opinion about code changes over time. I think one of the, one of the advice I would I would give is to not try to be smart. With I've seen a lot of younger, junior engineers trained to sit, yeah, trying to do something very, very smart. And they, they imagine something and say, oh, yeah, it's going to work. And it's going to be, you know, they, they, they want to have something that's complex and elegant, and so on. And they want to, and thing is that when you try to be too smart, usually you're going to miss something, and you're going to make something that's not maintainable. And the best advice would be to say, okay, just first, make sure that it works. And that it's, it's easy to understand. So if you can't, if you can't explain what you're doing to five years old, basically, it means that you're trying something too complex.

Steve Westgarth: 13:39

Thank you for that. And actually, I want to talk to you a code, right? So I mean, you're you're an engineer, and I guess, you know, especially in the Android space. Kotlin is currently where it's at. And I actually remember three years ago, called Mobile, there was a guy going up to do a lightning talk. And he started talking around to Kotlin. And Kenya, where I was gonna going, and we kind of almost laughing and the audience thinking as if Cortland thing like, where's that going to go. And actually, within six months, it's Google kind of putting all of their weight behind Kotlin as the language of choice for Android. So I guess your Kotlin is relatively new to you, what your 334 years or so.

Xavier Gouchet: 14:18

I, I've been using Kotlin for about five or six years. I think I started using it in small pet projects. Be when he's when when he was still in beta? And then as soon as you will say, Okay, we're going to work with cocaine. A we we used it in all the companies that we've been working

Steve Westgarth: 14:37

for. Why why do you think Google back Kotlin? What was it about Kotlin. That said, that was where we needed to go. And that's what we needed to to use for Android development?

Xavier Gouchet: 14:46

Well, I think that the main quality of Kotlin is that the compiler is very, very smart. It does a lot of thing to make sure that it knows everything, meaning that there are a lot Have of things that the Java compiler misses. And basically, it's only going to break at runtime, the Kotlin compiler prevents a lot of those issues is a lot about type safety, about nullability have pointers and so on. And it means that I think for from Google's point of view, having people use Kotlin would mean that the application would crash less, meaning that the overall quality of Android synth, from the point of view of customers would grow. Because if, like, if you're using a phone, and you'll notice that most of the application crash on the phone, you're gonna say, Okay, I'm going to try an iPhone. But if the overall quality of the application that you find on Android grows to a high quality level, people are gonna say, Yeah, Android is a good quality phone, because the the OS device is just as good as the application you're going to use. You're never, you know, one only uses the stock application just start application or on the phone, the download adventure mobile, like, I mean, all the social networks and sharing apps and, and messaging and so on. So Google, I mean, iPhone, Apple has had for years this validation, so you can publish an application on the on the on the App Store, without a manual validation that yeah, the application meets the apple standard. We didn't have that for the the Android Market, and then the Google Play Store for years. And even now, I think it's not manual. It's still like just bots, making sure that all the criterias I believe, and so they need to find a way to to ensure the quality and the basically, you mentioned that the user had a good experience when using the phone and the apps on the phone.

Steve Westgarth: 17:03

And I guess you obviously enjoy using the language. I mean, what is it? What is it about Kotlin that you really enjoy, and maybe pick on two or three features, or yo your facets of the language that you really think you're kind of your size? Language.

Xavier Gouchet: 17:20

One of the one of the features that I really, really liked about Kotlin is the ability to write extension functions, which is basically kind of the same thing as objective C, add for years, which I really liked, which is I think it's called categories, where you can basically say, Oh, I have this class, and I want to add a method to this class. And, and you're going to do that with Java. And Kotlin, wrote this, which makes basically Kotlin brings this and there are other features that make the code much more readable, because it gets rid of a lot of verbosity that Java had. And it adds a lot of, you know, syntactic sugar that makes it easier to read. And because it's easier to read, the easier to understand and the easier to maintain. So I think this is the main features that I really like about Kotlin.

Steve Westgarth: 18:12

Or one of the things I noticed, I mean, so I I'm a swift developer and your Objective C before that. And probably in the last, I would say, your four or five years, I've gotten much more into JavaScript. And actually, the similarities between swift and JavaScript are that there's a lot of a lot of facets of the language and the way the way we write things that are your are very similar. And I also noticed that I haven't done as much with Kotlin. I've been really, really upfront about that I haven't I haven't played with Kotlin as much. But I also get the impression that it is actually quite a similar language to yo to the way Swift is developed, or the way that the JavaScript is developed. And if you've got a view on that,

Xavier Gouchet: 18:52

it's similar. I know that it's one of the good thing that I really liked about Kotlin is that jet brain is independent, and it's not tied to a specific target. So at first, they started mostly for JVM, because it's the easiest one to tackle you just right, you just read bytecode Java bytecode. And basically, it's, it gives you, you don't have to worry about the runtime. But the thing is that I've seen a lot of discussions on the Kotlin discord and about like, you know, people think, Hey, we should have this or that feature. And the team guy Kotlin is very dedicated to make sure that the language as a whole stays very consistent and stay true to the the ideal that they had when they started Kotlin. So a lot of the time they say okay, this was for Yeah, it could be nice, but it would bring ambiguity or it doesn't work with the, the, you know, the the logic of Kotlin and And or there are other ways to do this without adding to the language, you can just use cognitive features to create this yourself. And we don't need to add this to the language, which is usually very, very nice because they don't just say, people want this. So I'm going to build this, they really have this reflection about what should or shouldn't be part of Kotlin. Yeah.

Steve Westgarth: 20:24

Cool. And then I guess all Simon do as well, swiftly on to talk them. So since contract by the community, and I think it's, it always amazes me, you know, how can the community engineering community kind of gets behind your big projects like this? Right? Because I mean, that would be it would be impossible, and also absolutely not desired, actually, for one company to kind of do to to own Kotlin or to to on Swift? I think it's one of the you know, from an iOS point of view, you're one of the one of the best things Apple have done is just open source Swift. And the, I think that it suddenly makes the language you're very accessible and available to, to anybody who wants to get involved. Right. And it's something I think, in terms of how the community is kind of evolving. You know, it's, it's about that shared ownership. And, you know, actually, everybody kind of feels feel some ownership of the languages and the tools were using, which I think is an incredibly powerful thing for the software developer community as a whole.

Xavier Gouchet: 21:19

Yeah, definitely. I mean, I think I think this is the something that's very important, the fact that those languages are completely open sourced. I mean, like Java was before and still is, and others. But the, the idea is that because you're going to use the language, being able to know about all the internals of how the language works, is going to help you become better and have better proficiency in the in this language, like it. I mean, of course, you don't need to look at all the implementation of how Catlin does this or that, to start writing in Kotlin. But once you getting interested in it, you can dig into it and say, Okay, this is how they do it. And it's really, really helpful. I think it kind of relates to one of the philosophy that we have in data where all the all the artefacts and libraries that we write that are going to be living inside our customers, back end computer or on the end users devices, everything is open source from scratch. Because people need to know what what we're going to run, they need to have this visibility and to be able to change that as well. So I think it's the same idea that the language that we use, we need to be able to know how it runs, and we need to be able to change it as well.

Steve Westgarth: 22:45

And I guess that's particularly important with data dogs, I mean, so for listeners who haven't heard of data dog, you're essentially an APM application performance monitoring tool that helps developers to write really great performance code, and to monitor that performance in production. And I guess actually understanding how the language works and how it how it operates at a runtime level is incredibly important for some of the tools and technologies you're writing.

Xavier Gouchet: 23:10

Exactly. Because the thing is that because we're we're monitoring the performance and ones, we want to make sure that the code runs fast, being able to know how a particular instruction is going to run actually can help us know where we can want to improve the performance and make some optimizations. In in, I mean, to be able to make optimizations you need to measure first and then what you're after and compare the both but knowing how it works exactly can give you a good pointers on where you need to make the changes.

Steve Westgarth: 23:51

So as we're talking about data, dog, I mean, what do you folks up to what's, what's exciting in the APM space at the moment? Well,

Xavier Gouchet: 23:59

actually, Daedong is not only an APM company like it started like that, but now we're bringing observability like on on everything you can think of even in CI, we bring the the team I am part of is bringing observability on the front end and mobile apps as well. So it's like real user monitoring, being able to basically know how long people use your application, what actions they are doing. We have some crash reporting. And whenever the crash happens, we can you know, link that to the actual context where happened. So we don't have we don't only have the crash, we'll also know what the user did and how they navigate in the app and what action they took. That led to the crash. And one of the big thing that we're working on right now is trying to bring a flutter SDK. So people writing mobile apps with flutter are going to be able to have this No, absolutely, yeah, as well. So yeah, that's, that's one of the big topic. And that's happening in my team.

Steve Westgarth: 25:07

And just just touching on flutter there, I mean, so cross cross platform development is something which you're kinda keeps rearing its head, right, but you kind of keep talking talking about it, we can look for the, you know, the author of the golden egg that is, back that, your crack that that beast. And, you know, something I've been reading a lot about recently is is Kotlin, multi platform, which which appears to have taken a very different approach to the subject of cross platform apps. And the I noticed that you're on top of modern platform, one of the things I really like about it, is that you can use Swift UI, and you can use jetpack compose those native features, which which in theory resolves all of the UI issues and the other the performance UI and things that didn't your maybe other frameworks, I've, of course, of course, problems, I don't know, if you've, you've read anything about it, or your use Kotlin multi platform, but you're interested in what you might know, and what you might have to share.

Xavier Gouchet: 26:05

I mean, I am used much Kotlin, multi platform, the I think the approach they have is that they're still thinking as language, and just making sure that, okay, you're writing your own code that express intention. And they just make sure that this intention can be translated into something that can be read by a JVM, or by a JavaScript runtime, or directly into native code compiling in something that's close to the, to the CPU. And, and the thing is that because they have this knowledge, they can invest in your transpile it to anything. So something that runs in Python is something that runs into any, any any kind of runtime that we can think of. And I think that's one of the good thing. It's trying to say, Okay, let's just speak the same language and keep, like you say, the adaptability to say, I'm on Android. So I'm going to use jetpack compose, I'm on iOS, I'm going to use Swift UI, I am on flutter. And I'm going to use like the flutter engine, and I'm on on the web. So I'm going to use React, or I'm going to use Angular or whatever to build my UI. And I think that that's the best way. Because when you when you're talking about multiplatform across platform technologies, the main idea is to say, Okay, I have multiple targets I want to address, but I want to have the same code base, or at least to share as much as I can, between all those targets. And I think this is where Zarin did something good is that they didn't try to write a UI system that would adapt to every an iOS and Windows Phone, whatever, they just say, Okay, we're going to have some shared code, which is going to be the domain logic. So it's going to be your, your data classes, your network, requests, your local database, your you know, all your domain rules that say, Okay, this is my business logic. And this is shared, and you should be the same for all my platforms. But then we are talking about the UI and daily Navarrete that we're using the Android layouts in iOS that we're using, like the zip files in Windows Form they were using. I don't remember what it was. But yeah, basically forms. And this is a way to go, I think it's say, it's the same thing that we're talking about earlier. It's when you're writing code for a platform, you need to make sure that your application is consistent with the expectation of the user on this platform. It's the fact that an Android user expects interactions expects UI to be a certain way. And there's nothing more frustrating when you're opening an app when it has the iPhone, look on an Android and use No. Okay. They just you know, did a copy paste and didn't think about it. And this is something I talked about it with the designers in, in previews company I was in where I said, Okay, it's important for us that the UI looks the same, because we have one brand, one identity, and we know how the app looks on iPhone and Android and on the web, and so on. And we want all of them to look the same. But our users, they don't care about that. They don't care that the application on the iPhone of the neighbour looks the same as the application on their Android phone. What they want is for the application on their Android phone to behave and look the same as the other application on their Android phone. And yes, you do have branding. So you have your colour scheme, your phones, your you know, the way your button looks like. But apart from that you still need to be consistent with your, your platform. So yeah,

Steve Westgarth: 29:51

it's something I evangelise about a lot. You're about our problems not being your users problems. And I think that's the engineering space I think is Very important for engineers, you're to think about software solving, you know, maybe it's an authentication issue or a way to do something on the phone, the user shouldn't be aware of that and your needs, it needs to be totally transparent to them, because it's not their problem. So we can take care of it. It's also my pet here to that captures, by the way, on the internet, you know, I hate very much that you'll because we've got a problem with, you know, bots, or whatever it might be, you're hacking into hacking into sites who make the user do something in addition to validate themselves as a user. But, you know, I think that that concept of your our problems not being users problems, also extends into companies. And in almost kind of, you know, the brand perception of the company and how that's perceived by users. That's a company problem. That's something that the, the we need to solve for. But you're right, actually, we did put our heads into what the user expects, and what they want to see. And actually, you know, by by integrating a company into a user's life in that way, it becomes seamless. And if you can move seamlessly across your phone and across your devices, in a way that you would expect, you're quitting the user experience you would expect. I think that that actually you'll gain a lot of traction with users, and actually gives you a much, much greater stickability, which, which is really important for, for driving wealth, and all sorts of things in terms of how your applications actually gonna get used.

Xavier Gouchet: 31:18

Yeah, and this, this goes well, as well for the way we develop libraries, like, so the word they will do in my team is, is writing libraries. So we don't write apps actually. And so what we want is that iPhone developers, iOS developers have the same kind of features that Android developers have has the same kind of features that website developers have. And the thing is that, although we want to be able to provide the same features will also need to adapt to what they expect in their own technology. So we have to make sure that the language that we use the API that we designed, so it's not No, it's not graphic, it's not UI, but the API, the methods and classes that we provide, follow the standards of what we do in Android or an iOS and not just say, Okay, you need to have a method named this on all the platforms we just need, we need to be able to enable this feature on all the platforms, but use what's native to the platform to do it. Just to give you an example. One thing that we use a lot in Android is to use builders. When you want to create a data class, you want you to basically extract or you want to create the configuration to initialise the SDK, you're going to use a builder. So you can say, I'm going to create a builder, and I'm going to have I'm going to chain the methods to say add this feature and enable that and do this and add this option. And then you do you call dot build, and you get your object that's, you know, prepared for you. And this is something that's, you know, very, very widely used in in the Android ecosystem. And in iOS, you don't want to use builders, because this is not the way you do things you Swift, usually, you're going to use a struct and you say, Okay, I'm going to create a struct and people can use this struct and write it their own way, in the Swift way. So yeah, it's exactly the same. Same idea is that you need to adapt to your target audience. So keeping some some unified brand across all platforms, but staying true to the platform specifics.

Steve Westgarth: 33:33

Yeah, and I think I think you talk a lot of sense there. And going going back to what users expect and in their apps and and how apps work. I think users expectations about application performance is rising every day. And we can say that, yes, because the hardware has kept pace. Without that, you know, actually, most apps do appear to be performance. But then if you actually look at you touched on Xamarin, a few minutes ago, and one of my observations about Xamarin is that the the payload of a Xamarin app is huge. It's very, very high. And that puts a lot of weight into the app. And my experiences and some web apps do tend to have a lot of performance challenges, which which makes it difficult for them to, you know, to, to meet users expectations and the way that you might want an app to do. But But I mean, that's what it says on when apps can't your meet users expectations, and you can't, you know, get those performance gains and improvements. But so much of that is about engineers thinking about performance as part of their development lifecycle. So I mean, you obviously talk to engineers every day, you're obviously working in data dog, which is very performance orientated. How do we help engineers to think more about performance as part of their everyday development lifecycle?

Xavier Gouchet: 34:45

Well, I think one of the the key thing is to try to think about, again, it's the mandate, but it's the thing about the target audience. So if your application is like no for a wider audience, you need to look at what device was was popular three years ago because like, except for, you know, tech savvy users and geeks and developers, I mean, yeah, most people keep the same phone for three, four years. So if you if you say, Okay, let's look at what what phone was popular released three years ago, make sure that your application works smoothly on this old phone and not on the latest pixel five or latest latest iPhone device that just came out two weeks ago. And so basically, this is this is the one of the things that we might want to do if companies stay, because in lots of companies, in the mobile teams, you do have devices that are put by the company to say, Okay, we want we're gonna give you a device to work on. Instead of buying the latest pixel iPhone, users just buy the popular phone from three years ago. And, and we did that, like a Deezer, I know that we had this. So it was like kind of a joke in the team. But we had one device that was very old, very low and very, very difficult. And this was like our benchmark device, we wanted to make sure that the application runs smoothly on this old device. And if it does, basically is going to run smoothly on any device at all. And I think this is this is, I think, the best way to approach performance, because once you do experience this, like, physically, you have the device in your hand, you're trying to use your application, it's going to be very, very frustrating, very, very fast, because you need to eat, you use your own application all day long as you're developing. And with this frustration, you're going to be very motivated to fix the performance issues.

Steve Westgarth: 36:54

I think there was definitely something about your walking a day in another person's shoes, if that's actually seeing, you know, how a user will experience your app and being a user of your app. I think it's something that we've talked a lot about in our development teams at GSK. And we're currently working on an app which will be launched in Italy later this year. And the Italian market is very, very different to the UK market. And you know, one of the things that we've been talking about is how do we how do we expose our engineers who are based in the UK, and predominantly to the Italian market and to the conditions that that application is ultimately going to be embedded in. And one of the things we did, we ran, we ran a couple of Google design sprints. And at the end of those design sprints, we got some real patients, and we'll pharmacists who are in the Italian market, and to come in and test some of our prototypes. And actually, those conversations with those real end users were incredibly insightful, in terms of learning the differences between how they were going to use the product, versus how we might have done the conversation. That's not because the engineering team was was it was phenomenal. I don't know if you've had any similar experiences.

Xavier Gouchet: 38:02

I'm not in my work. Because I mean, all for all the application that I've worked on, I've always chosen the company I wanted to work for because I, I was already using the app, I knew that I was going to use the app. So this is that something like you said, you need to be your own user. And this is something that's very, very important to say, Okay, I want you to know what it's like to use the application. But the fact that some companies some application are, are very badly perspective, presented by the users, is that the company that developed them, don't talk with them. I've had a conversation like this with my car, just I've had a conversation like this with my hairdresser, where they have, you know, software dedicated to their line of work and where they can, you know, do order products and do the billing into one that's, you know, dedicated for their line of work and all the all the guarantees skews the same application, all the headers are used, same application, and so on. And the thing is that those applications are so badly designed, and they both and others as well. They both saved me the safety that no one in this line of work would think about splitting this this way or organising things this way. It's not how we think. And, and the thing is that it's most of those applications are built like how developers or how App Designer think and not how the end users think and this is the the theme that we need to so in the companies that were I was wearing We could say okay, yes. Like, my this example is deserved because I use this everyday still they still do nowadays, is that whenever something was proposed that say, Hey, we should add that to the app, we all had our opinion, because we're all listening to music was Deezer. And we were all thing. Yeah, this doesn't work. Because the way I listen to music, I do this, and we're speaking not as developers or not as designers, but we're saying things as music lovers using an app to stream music.

Steve Westgarth: 40:35

I think that's so powerful. And you know, it's true. I think that engineers who are engrossed in actually custom us, you know, have a have an impetus to build a great app, right? You know, because actually, you're building it for yourself, you're building yourself, you know, I would argue you're always going to, to do a better job, I go that extra mile, really make sure that something works the way you'd expect. And sadly, we can't always be that way. And I guess we all have to work on products that ultimately, maybe we aren't the target market for, or we aren't going to use. And and maybe that's a nice segue to talk about testing. And I know, that is a topic which is really close to your heart. And actually, some of the very first conversations we had when we first met, we were all around test driven development. And I know that as an engineer, you're really passionate about that. Why is it so important to take that approach?

Xavier Gouchet: 41:26

Um, I think there is one thing I for a lot, where people say testing is doubting, and this is very true testing is doubting. And the thing is that for most people, doubting is a bad thing. But for an engineer, doubting is a very, very good thing. Like, I mean, this is what you say, in every instance of the boss guys, is that we all write bad code. And I know that the worst code I've ever written all the time was when I was making assumption. And I was not doubting myself, I said, I was very sure that yeah, it's going to work, it's going to be perfect. I don't test it, and then it's gonna fail. So yeah, testing is doubting but test doubting is very, very good. Because it's, it makes you clear out the assumption that you have about the context about a feature you're using also about your own code. And without testing, basically, the the A, when you're writing code, you don't write code just to have good written, if you just want to have good return, just you know, write a book about code. And I mean, it's nice to have a book about the code that's just printed on a sheet of paper is never going to be around when you're writing code that's going to be in an application or in the back end, or whatever. It's meant to be ran. And sometimes, depending on your release cycle, your code is going to stay there, and is not going to be ran until three weeks later, or a month later. Or like, if you're still living in the in the eighth is about six months later. And testing means that every time you're running your test, your code is going to be right, you're going to have the compiler go through your code, you're going to have the runtime go through your code. And if you're writing your tests, well, you're going to have your code running out of time with different values. Meaning that you can be sure that it does exactly what you want, because you have assertions on what should happen when your code runs. So yeah, I mean, because we can't really be there where when our customers are going to be using our application, we need to run the code on controlled environments, and run it as much as we can to make sure that it does work like we intend to, but also to make sure that its performance and make sure that there is no side effects. And there is no edge case that are going to crash the application or just you know, make the user lose 30 minutes of work or anything else.

Steve Westgarth: 44:10

So some people would argue that you're we should evolve and move beyond test driven development, and move to maybe a Behaviour Driven Development approach. Do you think the two approaches are mutually exclusive? Or what's your view?

Xavier Gouchet: 44:25

No, they're not mutually exclusive. They're quite complementary. And then is that test driven development is, is an algorithm that works with any kind of tests that you can write. So it works for unit tests, but they also work for integration tests, and they both work for end to end test and Behaviour Driven test. The idea with test driven development is that you write the test first, you watch test fail, and then you fix the code until it passes. And then there is the last step to make sure that you can refactor and improve and and optimise what's already there because you know that your test is going to be there for you to catch you if if something goes wrong. And this, this is usually taught around unit tests, because it's easier to understand. But you can actually write your tests first, when you're doing some integration tests or end to end test. Because you already know, the goal is to say, what is TDD? You need to think first about what is the outcome that what is that you want to test. So if your integration test you're having like, like 10 different classes that should work together, and you say, okay, at the end of the day, I'm going to call this and at the end of the day, I should have these outputs, whatever those 10 classes do, this makes you think about what's the outcome, what's the expected expected behaviour of the system that you're running. So Behaviour Driven Development is saying, okay, here, when I type my username and my password in the search field, and I press the button, eventually, I'm gonna get to a page that says, hey, you're logged in, here are your five new messages, you can do that in a test driven development idea as well, of course, this is like, this is like the nested thing, because when you say this, okay, my behaviour during my whole behaviour, end to end behaviour doesn't work, which means that I still need to write those small chunks of code, but still use the TDD approach to write them. And so you write the integration test, and then you go deeper and think, Okay, I'm going to write unit tests. And eventually you go back from the the nested code, and eventually the behaviour is going to run green. So yeah, the, they're not mutually exclusive. And the more tests you have, because we have like, there are lots of means that happen where you, you have those unit test version, versus integration tests, where you have like, okay, like my lock is working properly, and my door is working properly. But when you put the two together, actually, it's never going to be loved, because the door is a sliding door. And the lock is a sliding lock. And so, of course, it doesn't work. So, so, you know, we have this period of test. And the thing is that with all the levels, or other levels of the pyramid, we need the unit test to make sure that this this class in, independent from everything else is going to work. But we'll also meet the integration test to make sure that when my user experience uses my application, the whole behaviour of the application is known and it's tested.

Steve Westgarth: 47:43

And as you correctly calling out there, there are multiple different types of testing. And every type of testing is incredibly important to to an application, in order to make, we put a real quality product. And I know you're a very accomplished conference speaker. And actually, one of the first times I heard you talk, your talk with actual mutation testing. It's actually one of the most favourite talks I've seen you give. For people who maybe haven't come across that concept, maybe tell us more about it.

Xavier Gouchet: 48:12

Yeah, and the basic concept about mutation testing is to see your tests as a, an emergency drill. So basically, the idea of your, your I mean, your tests are basically your as your safeguard. So it's like your firefighters or your emergency crew. And the idea of mutation testing, is you're going to create a asef tutorial. So the idea is that, firstly, to have tests, that's the basic but, of course, everyone has test this. And then your tests need to be green, of course, the mutation is going to happen in your production code. So someone is going to introduce a false into one of the line of code from your application itself, or from one of your class or of your production class. And then we're going to run the tests again. And the idea is to see if those tests are going to catch the form that was introduced. If they do, you're good about this particular field. If they don't, it means that either your tests are incomplete, or the piece of code that exists doesn't do anything and is dead code and basically should be removed. So this is something that's very interesting because it's, it gives you trust into your the test that you've written. Usually, TDD is a very, very good way to be tricked to be trusted to sorry, it's a very good idea to trust your test. Because you see your tests fail, and then you see your test screen. And why you should do that is because the role of the test is to fail when something wrong would happen in your code. If you never see the test fail? How can you be sure that it's going to fail when you needed to. So that's the whole point of TDD, it's making it fail first. So you know that if something goes wrong, it's going to fail, it's it's, it can fail. The point of mutation testing is to go further than that. Because sometime you can have the test go green. And it might, it can fail in some circumstances. But it can stay green, when the code is actually wrong. So mutation testing goes a step further in this direction, by introducing faults in all places in your code. Running the test again, and making sure that yeah, this code was, was good. So it's, it's all a matter of making sure that through you you trust, the tests that you've written,

Steve Westgarth: 50:54

there are some really interesting parallels and some of the stuff you're talking about there to another concept that I find very interesting, which will be the Chaos Monkey. And it's the way that you know, some of our your large, large platform businesses, like your Spotify, or, you know, Netflix of the world, test their infrastructure. And that is to take out random pieces of infrastructure, you know, unexpected times, and then essentially observe what happens, and see what that means the application and what fails, it's a way to promote resiliency. So it's almost by kind of encouraging failure, and you're, and by it, you're, by learning through failing, we therefore have to become stronger overall. As, as, as engineers or as an application or or whatever we're doing, how important do you think failure is in the work that you

Xavier Gouchet: 51:39

do? Failure is very, very important. I mean, it's, it's usually it's for failure that we learn and that we remember the most. It's, I mean, there's this whole thing like, if you watch someone do something, you're going to remember, like 10% of it, if you actually do it, you're going to remember 90% of it. And basically, when you when you hit a failure, or when you hit a bug in the code, as engineers, you're going to spend a good amount of time dealing to this specific bug. So this is going to increase on a tiny bit, the the area of knowledge that you have about the system, or about the product or about the feature, but language about technology, but it's going to expand a bit, your understanding of what you're working on. And because you're spending time on it with sometimes a bit of stress, because this is a bag, this is important. We have some clients that are waiting, and so on, you're going to remember a lot of it and you're going to learn more and when you facing a similar situation, even years later, you're gonna remember that, oh, I had this bug at some point that did this. And that because of this particular situation, you're going to remember more about it than if someone in a code review said oh, by the way, don't do this. Because you can have you can have this issue, do this and said, You got to see the commands, you got to update your pull request, and you're going to forget about it. So failure is the best way to learn and to remember stuff and to basically expand our knowledge about the system that we work on.

Steve Westgarth: 53:24

So you're you're a team lead, or data dog, and you've just mentioned their code reviews. And different teams have different approaches to code reviews and different things where you're in different ways in different contexts, what's your code review, and then what makes a great code review.

Xavier Gouchet: 53:40

So we have two types of code reviews. I mean, for me, it's two types of going to reuse, we have human code reviews, and we have automatic conversion code review. So automatic code review is running or interest or integration test or end to end test or you know, all the favourite tests scheme that you have. It's also static static analysis. So running the linters running, running the static analysis that says, hey, if you do this, you might have this problem of concurrency or whatever. And all language to have great tools do that in CI. And it's really like all the checks that you might have about everything that's important to your particular team. But just to name a few we have this file that lists all the open source dependencies that we have in our projects. So we do have a check that check that looks at all the Gradle files that we have to make sure that we didn't forget to add one dependency in this file. We haven't checked to make sure that you know we don't we want run into a situation that's going to crash the application over Christmas because this will be very very bad. So this is that all the autumn automatic parts of the coverage view, and this is all in CI, and this is something that, you know, we we use a lot, because it's automatic, the computer does it very, very fast, and it's never going to miss a line. And then we do have manual code review. So it's going to be peer reviews, performed asynchronously, usually by people that knows the same project and work on the same team, as we do. And this is, this gives a more high level view of what could go wrong. And sometimes it goes into discussion about which design pattern is the best. Sometimes it's about discussions about is this the best solution to organise the or to fix this issue. But most of the time, it's, it's really helpful, because everyone in the team has a different background, they all have past projects that have been working on, and they will, we each have our own, you know, pet peeves, we each have our own preferences. And so every time that we have a coloured view, whenever I whenever I create a commit, I know that this person in my team is going to focus on this part of Michael myCRED. And this other person who's going to is going to look at my naming or my test, and so on. So it's very, very interesting. And the thing is that basically, because of this, we we have like a sharp rains, or a sharp brain of three or four or five rains, where everyone, you know, brings their own skills to the same piece of the code. And other The good point about this is that almost everyone knows about every line of code that we have in the product, meaning that on a moment's notice, everyone can jump on a bug, even in a part that they didn't call it themselves, they already know about it, they might not know be as familiar as the one wrote it, but they can jump on it, and understand it instantly that this is what's happening in here. And they know what what needs to be

Steve Westgarth: 57:25

something that I've found very effective in my own teams, especially when you're starting building a new product from scratch, is to almost kind of do a swarm or a mob programming event, your way you you have to understand computer and actually via teams and doing things remotely kind of in this post COVID world, actually kind of your mix that a little bit easier, because you can all kind of you know, see up close, you're exactly what's been working on the screen. But actually getting together in a group and you're doing you're doing doing group coding, I think is really powerful. And I actually I spoke to a leader in another organisation, not so long ago. And that comment was, but it's been a waste of money, because you're effectively you're paying multiple people to be loving the same thing. And I really found it difficult to to rationalise that because it didn't know, but actually, you've got the benefit of your 345 brains or working on the same thing. So actually, the quality of your product is much better as a result. But I guess it's that trade off between your quality and attend to mark and you've got to get the right balance. But you know, but so powerful to the engineers to to all contribute collectively together, which which really promotes and helps their learning, which is awesome.

Xavier Gouchet: 58:33

Yeah, and we do that small producing, but mostly for an architecture will do this decisions. So whenever we have a new, you know, big topic to address or a new activity to think of a couple of us are going to write a big documents that says, Okay, this is the problem that we want to tackle. These are our constraints. And this is what, what these are the options that we might go for. And the document, you know, can be reviewed as synchronously. Was everyone had any comments here and there? And eventually we'll do a meeting with everyone and say, Okay, we're going to go through all the comments, and we're going to discuss this. And I mean, yes, it does take some time when you want to have everyone in your team, be there because every tiny point can lead to a discussion that's going to spend 510 15 minutes or sometimes more. But the the thing that you gain from this is that you're going to avoid a lot of issues in the future. There is one graph that I really like that basically traces the cost of fixing a bug depending on when you detect it. So when it starts you detected during the architecture process. The cost of fixing the bug is like almost zero because you haven't written any code yet. The cost of fixing it when you're in the development phase you you're running out test, you find a bug, you fix it, it's going to be five minutes, then the cost of fixing it, when you're in QA, or in alpha release, it's going to be a bit more, you're going to have one to four hours, because you've developed this like a week ago. So you need to go back to it to get back into the context. And, and you know, you fix it. And then when you find it six months later, the cost of fixing it is going to be huge, because you're going to have the support involved, you're going to have that to have back and forth with customers, which maybe are going to be living in a different time zone, meaning that every back and forth costs you 24 hours. And then you eventually get to do a call with them to to understand the issue, and then you need to reproduce it and find it. And so basically, the earlier you you fix an issue, and the more one you're gonna keep in your company.

Steve Westgarth: 1:00:58

It's a really good point. And I mean, it's a really good, a really good anecdote there for for actually trying to drive your things left in your development cycle and actually deal with issues early. I mean, it comes back to the whole thing, we talked about performance earlier around, you know, if developers care about performance really early in their development cycle and, and really factor that into their thinking, you know, it's much easier to fix performance issues earlier in the cycle, rather than waiting in production, and we've got real issues. And also, once we're in production, you know, if we've got an issue like that, we're not surprising and delighting our users, you know, we've, we've caused a problem or we've caused them pain. So actually, you know, it's better for the product holistically, the early we can get into some of those some of those issues. And I guess we touched a little bit on on teaching there and kind of passing on knowledge. And I know, your teaching is a bit a big part of who you are. And you you really value kind of your sharing knowledge and, and helping learning why why is that so important to you?

Xavier Gouchet: 1:01:54

Ah, that's a really good question. I think so one thing that I really like about teaching is that, to be able to teach something, you must understand it completely. I mean, when you teach something, like, you're gonna spend a lot of time researching a topic, like whenever I do a talk, I'm gonna research topic and spend, you know, a lot of time on it, to basically just put 10 or 20%, of all that I've researched into the final PowerPoint, or in the final presentation. And, but because I wanted to teach it and higher, I had to undertake and understand completely, I've learned myself a lot. And, and this, this is very helpful, because whenever you have a question that comes from the audience, or from the students, the question is always going to be on something that you can't foresee. So you need to be prepared with a lot of area around the topic that you're teaching, or that you're talking about to be sure that you're going to be ready for whatever question happens. And another thing that I really like, and it's kind of the same, then, you know, creative creativity thing that I have with with coding is that whatever students, when you're explaining a topic, or like you, and you have a student that says, Okay, I didn't understand, you can't just repeat what you've just said, you need to find another way to bring the message home. So usually, you don't have time to say, Okay, give me one hour, I'm going to think of something, actually, you're on the spot. So usually, you need to think we can find another point of view, you know, you you shift your point of view, you can get another approach. And then you get to, to deliver the same information, but in a different way that they're going to relate with, they're going to understand. And this is, this is something I really like because it's it's driving me to understand better to be better at explaining things. And this is really helpful, like, just as a developer or an engineer, because I have to talk with sales and customers and product managers and so on, and make them understand something that are technical, in a non technical way. And having this background of teaching helped me being more efficient in explaining things and explaining constraints to them. So yeah, it's very it's very additive.

Steve Westgarth: 1:04:40

Yeah, no, definitely. I mean, actually hearing your talk there. It's actually quite motivational because you almost kind of use your your your teaching and passing on your knowledge as a way to promote your own self development and your own learning and making sure that actually you've got you know, the the right skills in order to be able to pass that knowledge on both technical which is a really powerful approach. I mean, how many to approach your self development as we've got any other strategies about making sure you're always up to date, or you've got the latest knowledge you want.

Xavier Gouchet: 1:05:10

Nobody, for the past year, like being elite, I've had not as much time as I wished to do that. But yes, self development in like, you know, in very general like that, not just in the engineering, engineering part of my myself, but yeah, something very important because you can't just stay with, with what you are, you are in this ever changing environment, in the ever changing world, like everything is happening so fast nowadays. And the technology changes so fast. I still haven't had time to play with Jetpack compose. And I still think again, you need to find some time to do that. Because it's going to be like it is already like the default for Android and, and I need to be able to work on that. But yeah, I mean, the, the some development, I think it can happen in a lot of ways. And not just technology. Like, of course, I'm listening to podcasts, and reading blogs, and so on. It's a good way to you know, to keep in touch with whatever's happening around. But I like to also expand my knowledge in a non engineering domains, like in music, literature, and in other things as well to just try to learn more things. Because the more you learn, the more you're you're going to feed on. Roll material, roll stuff into your brain that sometimes is going to help you find a solution to something that you have in an engineering workspace. Like for instance, I think that learning a lot about how jukebox works, just you know, just for fun, because I like many mechanical things in all things. And when I had to do this refactoring for Deezer years ago, basically I started thinking, okay, yes, but in a jukebox, we have this part that no fetches the disk or the record and put it on the plane. And then we have the part that actually plays the the recording, we have the way to say, Hey, by the way, next, the next song I want to play is this one. And this kind of drove the architecture that I made for this player eventually and the good name was player wasn't injured box, because it's really followed the way a jukebox actual work. And basically, like, this is this, this was possible, because I at some point, in my, in my time, I looked at a Wikipedia page for jukebox and looked at a video on YouTube of someone explaining how jukebox work. So this is this is something that you know, everything feeds each other. And this is very helpful.

Steve Westgarth: 1:08:17

So I love asking my guests to kind of get their crystal ball out and kind of look forward to the future. And what's what's coming downstream. You're obviously a really passionate Android developer that's come through loud and loud and strong over the course of the last hour, thinking about the mobile ecosystem more broadly.

Xavier Gouchet: 1:08:37

What's next? That's a very, very good, I think, I think that we're not going to have something very drastic change in the next five years. We're gonna have like, no faster phones, we're gonna have like, I'm going to say, aesthetic changes in the ICS. Because you need to say, Oh, this is new or shiny us. And so I I think that we were just going to have the same but slightly better, slightly faster. Because we already have, like, the all the internet of things is, you know, it's already there. So we're going to have a bit more of those and the more efficient and more powerful. We're going to have, like we're already have wireless for almost everything. So it's going to just keep expanding and be more efficient. The hopefully maybe the battery life is going to expand, but in terms of the technology, we we still have a drag because we want to make a change in the paradigm of how we use our phone nowadays, because we're to use to what it is like the way we use websites nowadays, even though it's shinier and it's our It's more the UI change. And now we have JavaScript that does everything, it's one is faster than it was like in the in the 90s. But essentially, it's always the same thing that you have a page that displays information, you have links to click on, and you have a bit of interaction with it. And and, and this still drive the way we think about website like, like, except for some experiments or some games, the way we interact with websites is still the same. And it's for mobile phones, I think we've reached kind of maybe another plateau, but we've reached again of a way that okay, application is still working the same. And sometime, we're going to have many more interactions. Entering started this with these slices, where you can export a slats tiny part of your application into something else, or the big train, picture, and so on. So we're going to have more ways to let applications blended to each other. But overall, I don't think we're going to have drastic change in the next year is

Steve Westgarth: 1:11:09

now Zevia. It's been an absolute pleasure talking to you today. If anyone wants to get in touch with you or kind of reach out to you, where can they find you online,

Xavier Gouchet: 1:11:20

you can find me on Twitter or on LinkedIn, with the same handle execution. I think it's going to be in the in the show notes. Yeah, and on GitHub, obviously.

Steve Westgarth: 1:11:34

Zevia thank you so much for joining me on the engineering leader today. Catching up with Xavier was so much fun, and really reminded me about the importance of focusing on application performance, right from the outset of any development project. The earlier in the development cycle that we fix performance issues or catch bugs, the easier and cheaper it is to fix the problem. It was also great to spend some focus time on approaches to automated testing. I'm definitely going to revisit mutation testing, and encourage my teams to incorporate this approach into their work. You've been listening to the engineering leader, a weekly podcast where I chat to folks working within the software engineering industry, and share best practices to help us to collectively raise the bar. The podcast has now been going for a few weeks. And it's been really great to get feedback from people who have reached out to me to let me know what they think of the podcast, and also to offer to come and talk on the podcast as a guest. If you're enjoying the show, please take a moment to share a link on LinkedIn or Twitter. And also drop me a message with any ideas you have for how we can evolve the show and grow the community. My name is Steve Westgarth and this is the engineering leader. Let me tell you a secret. You also write bad code. If you disagree. You may as well switch off