1 00:00:00,040 --> 00:00:02,160 I was doing a consulting project for Walt Disney Parks and 2 00:00:02,160 --> 00:00:03,640 Resorts. We kept finding ourselves in 3 00:00:03,640 --> 00:00:06,120 this situation where we were supposed to integrate with an 4 00:00:06,120 --> 00:00:09,080 API and it wasn't ready or the team delivering it said it was 5 00:00:09,080 --> 00:00:11,440 ready, but it didn't behave the way that the specification said 6 00:00:11,440 --> 00:00:13,440 it would. And I actually went on paternity 7 00:00:13,440 --> 00:00:15,840 leave and I kind of thought that this is an HR being wanted to 8 00:00:15,840 --> 00:00:18,120 scratch for a while. And so I spent quite a lot of my 9 00:00:18,120 --> 00:00:20,840 paternity leave kind of hacking away on what became the first 10 00:00:20,840 --> 00:00:22,560 version of Why I'm. On So Tell us what is why I'm 11 00:00:22,560 --> 00:00:25,040 not why people should consider using tools like wire more? 12 00:00:25,320 --> 00:00:28,720 The benefit is that you're bringing into your inner loop of 13 00:00:28,720 --> 00:00:31,120 development the ability to learn and then get feedback about that 14 00:00:31,120 --> 00:00:32,920 real world integration. You know when you're working 15 00:00:32,920 --> 00:00:35,080 with something that closely resembles a real API, rather 16 00:00:35,080 --> 00:00:37,360 than your own abstraction with your own set of assumptions 17 00:00:37,360 --> 00:00:39,200 about it as the thing you're integrating with. 18 00:00:39,600 --> 00:00:42,000 If you refer to the testing pyramid, where do you think 19 00:00:42,000 --> 00:00:45,280 Wyomops sits in that pyramid? What I've observed in practice 20 00:00:45,400 --> 00:00:48,200 over the years, you get the testing trophy shape more often 21 00:00:48,200 --> 00:00:49,640 than you do the testing pyramid shape. 22 00:00:49,960 --> 00:00:52,320 One of the sort of points of resistance around mocking that 23 00:00:52,320 --> 00:00:55,080 you hear a lot is this idea that it can't really be trusted. 24 00:00:55,080 --> 00:00:57,760 It's not really realistic. And you see some organizations 25 00:00:57,760 --> 00:00:59,680 who will do the vast majority of their testing in a sort of 26 00:00:59,680 --> 00:01:01,480 complete the integrated arrangement. 27 00:01:01,600 --> 00:01:03,880 And the advantage of bringing mocks into the equation is that 28 00:01:03,880 --> 00:01:05,480 they kind of flatten the economics out. 29 00:01:05,560 --> 00:01:09,440 The difficulty involved in testing some weird edge case is 30 00:01:09,440 --> 00:01:12,400 about the same as the difficulty involved in testing your sort of 31 00:01:12,400 --> 00:01:13,480 #1 happy path. So. 32 00:01:13,720 --> 00:01:15,960 WI MOC itself was created in 2011. 33 00:01:15,960 --> 00:01:19,240 It's been like 14 years now. It has like 6,000,000 monthly 34 00:01:19,240 --> 00:01:21,200 downloads. Lots of contributors, right? 35 00:01:21,240 --> 00:01:24,280 How do you actually make this open source project successful? 36 00:01:24,640 --> 00:01:26,920 There are a number of things that make open source projects 37 00:01:26,920 --> 00:01:28,400 successful, but it's kind of about. 38 00:01:42,450 --> 00:01:44,770 Hello guys, Welcome back to the new episode of the Technology 39 00:01:44,770 --> 00:01:48,050 General Podcast. Today I have with me Tom Akers. 40 00:01:48,290 --> 00:01:51,130 He's the creator of Wire Mock. If you don't know, it's an open 41 00:01:51,130 --> 00:01:54,450 source tool for API testing, API mocking and things like that, 42 00:01:54,800 --> 00:01:56,600 which has been created a long time ago. 43 00:01:56,640 --> 00:02:00,480 So it's like in 2011. I think I will learn from Tom 44 00:02:00,480 --> 00:02:04,160 today how he made that open source project successful, and 45 00:02:04,160 --> 00:02:07,520 we'll talk a lot more about API testing and API development in 46 00:02:07,520 --> 00:02:09,440 general as well. So welcome, Tom to the show. 47 00:02:10,080 --> 00:02:13,560 Thank you for inviting me on. Right Tom, I always love to 1st 48 00:02:13,560 --> 00:02:16,280 invite my guests to share a little bit more about you, maybe 49 00:02:16,280 --> 00:02:18,840 by telling your career turning points that you think we all can 50 00:02:18,840 --> 00:02:20,520 learn from. Sure. 51 00:02:20,560 --> 00:02:23,760 So I'm sort of, I guess a career software developer. 52 00:02:23,760 --> 00:02:25,840 I've been doing it for my whole adult life. 53 00:02:26,200 --> 00:02:30,480 I've usually worked in enterprises that have complex 54 00:02:30,480 --> 00:02:34,080 and often distributed network systems integration problems to 55 00:02:34,080 --> 00:02:37,400 solve that kind of thing. And to give a little bit of, I 56 00:02:37,400 --> 00:02:39,800 guess the Genesis story of why I'm not, which is probably my 57 00:02:39,800 --> 00:02:41,280 most significant career turning point. 58 00:02:41,320 --> 00:02:43,960 I was doing a consulting project for Walt Disney Parks and 59 00:02:43,960 --> 00:02:46,840 Resorts, working on what what is now the magic band system. 60 00:02:46,840 --> 00:02:49,920 So their system of kind of RFID wristbands that you get as a 61 00:02:49,920 --> 00:02:53,160 guest that grants you access to rides and your hotel room and 62 00:02:53,160 --> 00:02:55,760 various other things. When that system was first being 63 00:02:55,760 --> 00:02:59,800 conceived of and built, I ended up working on that programme and 64 00:02:59,920 --> 00:03:03,280 Disney needed to do a sort of huge digital transformation in 65 00:03:03,280 --> 00:03:05,480 order to enable this. So they had a load of systems 66 00:03:05,480 --> 00:03:08,880 that sort of operated different bits of the park and hospitality 67 00:03:08,880 --> 00:03:10,920 experience, but they were kind of quite siloed. 68 00:03:10,920 --> 00:03:13,720 They, they did some integration, they had some sort of existing 69 00:03:14,040 --> 00:03:16,680 service oriented architecture in there, I guess, but the, the 70 00:03:16,680 --> 00:03:19,440 degree of integration needed to be far greater in order to, to 71 00:03:19,480 --> 00:03:21,720 support this initiative to build the magic band system. 72 00:03:21,760 --> 00:03:26,200 So I got involved in that program and it was sort of 73 00:03:26,200 --> 00:03:28,600 before micro services have been coined as a term. 74 00:03:28,600 --> 00:03:31,720 And it was when rest was really just catching on as the sort of 75 00:03:31,720 --> 00:03:35,360 hot new architectural style. One of our senior engineers from 76 00:03:35,360 --> 00:03:38,040 my company actually persuaded the Disney senior engineers, the 77 00:03:38,040 --> 00:03:40,760 architects, that they should be using Restful design principles 78 00:03:40,760 --> 00:03:42,920 rather than continuing to build things on SOAP. 79 00:03:43,520 --> 00:03:45,320 And that was great and that was forward-looking. 80 00:03:45,320 --> 00:03:48,280 But the downside of this was that nobody really knew what 81 00:03:48,280 --> 00:03:51,240 they were doing at this point. And it was a, a huge programme. 82 00:03:51,240 --> 00:03:53,880 Lots of developers kind of parachuted in from various 83 00:03:54,160 --> 00:03:56,760 integrators and consulting companies very quickly onto this 84 00:03:56,760 --> 00:03:59,520 programme. And the the result was, to put 85 00:03:59,520 --> 00:04:02,720 it politely I suppose, friction being caused in various places 86 00:04:02,720 --> 00:04:05,120 and things not being quite as productive as they needed to be. 87 00:04:05,160 --> 00:04:08,600 And the team that I was working on was building a set of apps 88 00:04:08,600 --> 00:04:11,800 for cast members for Disney staff members to help customers 89 00:04:11,800 --> 00:04:15,760 with their experience. And these systems needed to talk 90 00:04:15,760 --> 00:04:18,040 to lots of different APIs that have been provided by various 91 00:04:18,040 --> 00:04:20,000 different vendors. We kept finding ourselves in 92 00:04:20,000 --> 00:04:23,240 this situation where we were supposed to integrate with an 93 00:04:23,240 --> 00:04:26,640 API and it wasn't ready or the the team delivering it said it 94 00:04:26,640 --> 00:04:29,480 was ready, but it didn't behave the way that the specification 95 00:04:29,480 --> 00:04:31,800 said it would. A lot of the time environments 96 00:04:31,800 --> 00:04:33,720 would be unstable, things would be broken. 97 00:04:34,080 --> 00:04:36,480 This whole sort of litany of problems that are really common 98 00:04:36,480 --> 00:04:40,480 in micro services now or so or anything networked really that 99 00:04:40,480 --> 00:04:43,080 you kind of need to address in order to to, to be productive. 100 00:04:43,120 --> 00:04:46,760 And I actually went on paternity leave and I kind of thought that 101 00:04:46,760 --> 00:04:48,560 this is an itch I've been wanting to scratch for a while. 102 00:04:48,560 --> 00:04:51,440 There must be a, we need a tool that's that's going to help 103 00:04:51,760 --> 00:04:54,840 decouple us from this sort of slightly kind of chaotic 104 00:04:54,840 --> 00:04:56,640 environment in which we're trying to build software. 105 00:04:56,920 --> 00:05:00,000 And so I, I spent quite a lot of my paternity leave kind of 106 00:05:00,000 --> 00:05:03,240 hacking away on what became the first version of wire mock. 107 00:05:03,240 --> 00:05:05,640 And it was really the, the first requirement for it was I just 108 00:05:05,640 --> 00:05:08,640 want to be able to copy and paste the examples on the wiki 109 00:05:08,640 --> 00:05:11,560 that formed the specification of these APIs into a tool. 110 00:05:11,840 --> 00:05:14,080 And then I want to be able to test my product against these, 111 00:05:14,080 --> 00:05:17,120 these simulated responses. Rather than having to rely on 112 00:05:17,120 --> 00:05:20,720 all of these other teams to provide working services, to 113 00:05:20,720 --> 00:05:24,720 provide test data, to provide me documentation telling me how to 114 00:05:25,000 --> 00:05:26,800 operate these things, all of that kind of stuff. 115 00:05:27,160 --> 00:05:29,280 So that was kind of how Weimart was born. 116 00:05:29,640 --> 00:05:33,520 This episode is brought to you by Swim dot IO, and I'm excited 117 00:05:33,520 --> 00:05:37,840 to have its CTO and cofounder Omer Rosenbaum with me today to 118 00:05:37,840 --> 00:05:40,760 tell you more about Swim. Hi Henry, very nice to meet you 119 00:05:40,760 --> 00:05:43,440 and thank you for having me. So tell us a little bit more, 120 00:05:43,440 --> 00:05:46,720 what is swim dot IO? At Swim, we want to help 121 00:05:46,920 --> 00:05:49,360 companies understand their code bases. 122 00:05:49,440 --> 00:05:53,800 We combine static code analysis with generative AI to create 123 00:05:53,800 --> 00:05:57,600 comprehensive documents that help you navigate the code base. 124 00:05:57,720 --> 00:06:00,400 As an engineer myself, I wouldn't want engineers to spend 125 00:06:00,400 --> 00:06:03,720 so much time understanding existing code. 126 00:06:03,800 --> 00:06:07,280 I would want them to spend time creating and building new stuff. 127 00:06:07,600 --> 00:06:11,680 When you have code that has accumulated over decades, and 128 00:06:11,680 --> 00:06:17,360 especially in legacy languages that not many people are adapted 129 00:06:17,400 --> 00:06:19,880 nowadays, then the problem is even bigger. 130 00:06:20,280 --> 00:06:24,320 Swim dot IO is specializing into helping mainframe developers to 131 00:06:24,320 --> 00:06:26,280 understand their code base. Why mainframes? 132 00:06:26,280 --> 00:06:30,880 We actually didn't start there. COBOL had been by some people 133 00:06:31,000 --> 00:06:36,440 obsolete for a few years, and I discovered that it's not really 134 00:06:36,440 --> 00:06:39,280 obsolete, not at all. There are more than 800 billion 135 00:06:39,280 --> 00:06:43,240 lines of COBOL code that are in production and they drive lots 136 00:06:43,240 --> 00:06:47,160 of the business in the world. And we got more and more 137 00:06:47,160 --> 00:06:52,200 requests from customers to help them understand the legacy code 138 00:06:52,200 --> 00:06:55,360 business that was written decades ago and get accumulated 139 00:06:55,360 --> 00:06:58,840 over a very long period of. Time So from your customers so 140 00:06:58,840 --> 00:07:01,520 far, what are the some of the success stories that you can 141 00:07:01,520 --> 00:07:04,080 share? So we worked with an analyst who 142 00:07:04,400 --> 00:07:08,720 shared with us that it took them a year to document a single 143 00:07:08,720 --> 00:07:11,960 mainframe application, and using SWIM they were able to document 144 00:07:11,960 --> 00:07:14,560 a similar application in a matter of hours. 145 00:07:14,920 --> 00:07:18,400 So saving that amount of time enables them to focus on. 146 00:07:18,520 --> 00:07:22,560 Other tasks Thanks Amir for sharing with us about SWIM 147 00:07:22,560 --> 00:07:24,800 today. To learn more about SWIM, check 148 00:07:24,800 --> 00:07:26,880 out their website at swim dot IO. 149 00:07:28,720 --> 00:07:30,920 Right. So very exciting that you were 150 00:07:30,960 --> 00:07:33,120 sharing with us. Like how did you start with this 151 00:07:33,120 --> 00:07:35,760 WI MOC tool, right? I could still remember back then 152 00:07:35,760 --> 00:07:38,840 as well, like when early in my career we used to work with SOAP 153 00:07:38,840 --> 00:07:43,080 UI and things like that when SOAP was still the main thing in 154 00:07:43,080 --> 00:07:45,920 application development. And SOAP UI back then was kind 155 00:07:45,920 --> 00:07:49,960 of like the go to tool for API mocking, testing or just doing 156 00:07:50,000 --> 00:07:51,480 things like WI MOC is doing, right? 157 00:07:51,480 --> 00:07:54,440 So I think when we switch to REST, definitely there are a lot 158 00:07:54,440 --> 00:07:57,920 of gaps, for example, the tools, you know, the maturity of the 159 00:07:57,920 --> 00:08:00,280 tools as well. So I think it was really great 160 00:08:00,280 --> 00:08:04,760 to see such solution like Wyomok exists because as we adopt more 161 00:08:04,760 --> 00:08:07,800 Restful AP is I think we need such tools in place. 162 00:08:08,320 --> 00:08:11,520 So Wyomok itself was created I think in 2011, right? 163 00:08:11,520 --> 00:08:15,280 It's been like 14 years now. I think it's such a successful 164 00:08:15,280 --> 00:08:17,800 project. It has like 6,000,000 monthly 165 00:08:17,800 --> 00:08:20,120 downloads, lots of contributors, right? 166 00:08:20,120 --> 00:08:23,160 And a lot of companies and maybe other tools integrating while 167 00:08:23,160 --> 00:08:25,080 mock as part of their systems as well. 168 00:08:25,400 --> 00:08:28,920 So maybe if you can share a little bit of your insights, how 169 00:08:29,240 --> 00:08:31,960 do you actually make this open source project successful? 170 00:08:32,840 --> 00:08:34,080 Yeah, it's a really interesting question. 171 00:08:34,080 --> 00:08:36,799 I think there are a number of things that make open source 172 00:08:37,000 --> 00:08:39,559 projects successful. I think there is a degree to 173 00:08:39,559 --> 00:08:42,159 which obviously you need to be solving a problem which is 174 00:08:42,159 --> 00:08:44,720 really important and top of mind for people in a given moment. 175 00:08:44,720 --> 00:08:46,640 There is an element of timing around that. 176 00:08:46,720 --> 00:08:50,240 I started building wire mock at the point that rest started 177 00:08:50,240 --> 00:08:53,160 becoming popular. And then a few years after that, 178 00:08:53,600 --> 00:08:56,480 micro services became this thing that everybody was talking 179 00:08:56,480 --> 00:08:58,400 about. And it particularly with respect 180 00:08:58,400 --> 00:09:01,600 to micro services, I think it had reached a maturity at the 181 00:09:01,600 --> 00:09:04,680 point that people really got into doing that, where it was 182 00:09:04,680 --> 00:09:06,840 the tool for the moment and it became very useful in that 183 00:09:06,840 --> 00:09:08,520 regard. I think there's a number of 184 00:09:08,520 --> 00:09:11,200 design choices that I'd made that turned out to be good ones. 185 00:09:11,200 --> 00:09:13,640 I guess that made it a popular and useful tool. 186 00:09:14,160 --> 00:09:16,320 I'll go into that a little bit more in a moment, but I think 187 00:09:16,320 --> 00:09:18,640 there's another element as well, which is to some extent about 188 00:09:18,640 --> 00:09:21,440 kind of showing up and doing the boring things and doing them 189 00:09:21,440 --> 00:09:24,720 repeatedly. So writing documentation, fixing 190 00:09:24,720 --> 00:09:27,800 bugs, being available on a support channel of some kind so 191 00:09:27,800 --> 00:09:31,000 that people can interact with you over it and demonstrating 192 00:09:31,000 --> 00:09:33,400 that you're there for the long term to support the project. 193 00:09:34,120 --> 00:09:36,280 I think in terms of the API design, it's interesting you 194 00:09:36,280 --> 00:09:38,000 mentioned SOAP UI. Actually, I think there there 195 00:09:38,000 --> 00:09:40,840 was a, because it's sort of in addition to the the transition 196 00:09:40,840 --> 00:09:43,600 away from SOAP as the kind of predominant API style. 197 00:09:43,880 --> 00:09:46,400 There was also around that time a sort of transition in the way 198 00:09:46,400 --> 00:09:49,680 people were building software and the devil movement was 199 00:09:49,680 --> 00:09:52,040 getting into full flow around that time. 200 00:09:52,080 --> 00:09:55,120 And the sort of the desire and the kind of the impetus to 201 00:09:55,120 --> 00:09:57,360 automate things and to make things a lot more kind of 202 00:09:57,360 --> 00:10:01,080 developer centric and work that way was also a kind of a trend 203 00:10:01,080 --> 00:10:02,880 at the time. And I think the tools of the 204 00:10:02,880 --> 00:10:06,320 sort of SOAP UI generation that tended to be kind of customized 205 00:10:06,320 --> 00:10:11,320 IDs essentially were not always necessarily a great fit in that 206 00:10:11,320 --> 00:10:15,440 context where you wanted a sort of code based or an API based 207 00:10:15,440 --> 00:10:18,240 primary interface onto the tools that you you used rather than 208 00:10:18,320 --> 00:10:21,520 AUI. And one of the ways in which 209 00:10:21,520 --> 00:10:24,840 Wymock thrived is that it was right from the outset that there 210 00:10:24,840 --> 00:10:27,040 was this design principle I wanted to kind of hold on to 211 00:10:27,040 --> 00:10:30,080 which was everything should be representable as data. 212 00:10:30,080 --> 00:10:32,280 So there should be an externalized data format. 213 00:10:32,280 --> 00:10:35,440 It should be well documented and something you can check into 214 00:10:35,440 --> 00:10:37,960 source control and something which is kind of legible by 215 00:10:37,960 --> 00:10:40,840 human beings rather than just this thing that gets dumped out 216 00:10:41,000 --> 00:10:43,520 wholesale by a tool just as a way of kind of persisting its 217 00:10:43,520 --> 00:10:47,680 state into a file system. And the idea was that this data 218 00:10:47,680 --> 00:10:51,400 model was at the core, but then you would have ADSL kind of over 219 00:10:51,400 --> 00:10:54,360 the top of that as a nice way of expressing that data 220 00:10:54,360 --> 00:10:57,360 programmatically and getting all get all the benefits you get 221 00:10:57,360 --> 00:10:58,600 from a full programming language. 222 00:10:59,240 --> 00:11:03,480 And I think that combination yielded a lot of benefits. 223 00:11:03,480 --> 00:11:05,720 Some of them that I was maybe predicting when I made those 224 00:11:05,720 --> 00:11:08,920 choices and some of them that I wasn't having everything is 225 00:11:08,920 --> 00:11:12,160 expressed as a sort of externalized data format allowed 226 00:11:12,160 --> 00:11:14,400 a degree of interoperability in ways that I think I wasn't 227 00:11:14,400 --> 00:11:16,720 predicting. So maybe some more obvious ways 228 00:11:16,720 --> 00:11:19,600 a lot of people went off and wrote other programming language 229 00:11:19,600 --> 00:11:21,120 bindings. So I think to take this sort of 230 00:11:21,120 --> 00:11:24,120 eight or nine third party programming language is 231 00:11:24,120 --> 00:11:26,640 supported as clients to wire mod that I had nothing to do with 232 00:11:26,640 --> 00:11:29,000 writing. There are sort of some other 233 00:11:29,000 --> 00:11:31,760 benefits as well, ones I've noticed much more recently 234 00:11:31,760 --> 00:11:33,640 actually. So being able to by describing 235 00:11:33,640 --> 00:11:38,640 things as data rather than as code, you can make kind of 236 00:11:38,640 --> 00:11:41,760 inferences about what that data means that you you can't very 237 00:11:41,760 --> 00:11:44,560 easily with code. So a good example is in our 238 00:11:44,560 --> 00:11:47,160 commercial product, we have this kind of two way generation 239 00:11:47,160 --> 00:11:52,320 between open API and mocks and getting from a stub definition, 240 00:11:52,320 --> 00:11:56,600 which is describing in a sort of declarative way, I guess, how a 241 00:11:56,840 --> 00:11:59,160 stub should respond to an input document. 242 00:11:59,440 --> 00:12:02,280 It's far easier to take that and then turn that into a useful 243 00:12:02,320 --> 00:12:06,560 open API element. Whereas the alternatives that a 244 00:12:06,560 --> 00:12:08,760 lot of previous generation tools did where they'd kind of say if 245 00:12:08,760 --> 00:12:10,800 you want to do anything complex, you kind of have to break into 246 00:12:10,800 --> 00:12:12,440 scripting. You have to write a Groovy 247 00:12:12,440 --> 00:12:16,360 script or a bit of JavaScript in order to express this rule. 248 00:12:16,680 --> 00:12:20,400 You can't really then go and pause that and use it in this 249 00:12:20,400 --> 00:12:22,640 other context. So there's some design elements 250 00:12:22,640 --> 00:12:23,960 like that. I think putting lots of 251 00:12:23,960 --> 00:12:26,520 extension points in there has definitely been a good choice. 252 00:12:26,520 --> 00:12:28,360 I think there are times when there's an I can source 253 00:12:28,360 --> 00:12:29,960 maintain. You get asked to put things into 254 00:12:30,000 --> 00:12:33,000 the core of your product and you have to say no because it feels 255 00:12:33,000 --> 00:12:35,840 like this is too much of A niche use case, adding a lot of 256 00:12:35,840 --> 00:12:38,320 complexity. So you are going to have to take 257 00:12:38,320 --> 00:12:41,840 on and maintain that is then maybe not kind of pulling its 258 00:12:41,840 --> 00:12:43,960 weight in terms of the amount that it gets used. 259 00:12:44,480 --> 00:12:47,680 But if you can provide good extension points for people and 260 00:12:47,760 --> 00:12:50,640 encourage them and sort of help them to to take advantage of 261 00:12:50,640 --> 00:12:53,560 those, then you're not just flat out saying no, you're kind of 262 00:12:53,560 --> 00:12:56,040 saying, I'll give you some help towards this, but then you can 263 00:12:56,040 --> 00:12:57,880 do the work to build this particular feature. 264 00:12:57,960 --> 00:13:01,000 So I think that's been kind of quite important as well. 265 00:13:01,440 --> 00:13:02,720 There's probably the main things. 266 00:13:02,720 --> 00:13:04,480 I think there's maybe a few other things I could point to 267 00:13:04,480 --> 00:13:06,520 about the design, but those are the key things really. 268 00:13:06,520 --> 00:13:09,680 I think giving people the opportunity to use the tool in 269 00:13:09,680 --> 00:13:12,960 ways that you didn't necessarily expect as a sort of general 270 00:13:12,960 --> 00:13:15,080 unifying principle. I suppose the other thing that's 271 00:13:15,080 --> 00:13:17,480 worth mentioning as well is focusing on the first run 272 00:13:17,480 --> 00:13:21,560 experience, kind of making sure that when people first encounter 273 00:13:22,160 --> 00:13:24,800 your tool that they get some value from it very quickly. 274 00:13:24,800 --> 00:13:27,480 I think that the same kind of heuristics that you apply when 275 00:13:27,480 --> 00:13:30,320 you're first building a start up, I think also apply here 276 00:13:30,320 --> 00:13:34,120 where you sort of get 10 seconds of someone's attention when they 277 00:13:34,120 --> 00:13:36,120 first become aware of the thing that you're building or 278 00:13:36,120 --> 00:13:38,440 promoting or whatever. And then if you can, they 279 00:13:38,440 --> 00:13:39,800 capture their attention in that 10 seconds. 280 00:13:39,800 --> 00:13:42,240 And then they might give you 2 minutes or 5 minutes or 281 00:13:42,240 --> 00:13:44,800 whatever. And then if you can give them 282 00:13:44,800 --> 00:13:47,000 something of value in that time, then they might give you an hour 283 00:13:47,000 --> 00:13:48,320 in order to try and set the thing up. 284 00:13:48,320 --> 00:13:50,600 And you have to kind of make sure that at each of these touch 285 00:13:50,600 --> 00:13:54,280 points, you're allowing people to make meaningful progress or 286 00:13:54,280 --> 00:13:56,560 to sort of have a moment of enlightenment where they realize 287 00:13:56,560 --> 00:13:58,200 what the value is that you're delivering. 288 00:13:58,640 --> 00:14:00,880 I don't think I was concretely thinking about it in these terms 289 00:14:00,880 --> 00:14:02,800 when I first built it, but I think I just had this 290 00:14:02,800 --> 00:14:05,200 instinctive sense that if you can give people little snippets 291 00:14:05,200 --> 00:14:08,000 of code that they can paste into to their projects, and the thing 292 00:14:08,000 --> 00:14:10,200 will just work. Because when I first started 293 00:14:10,200 --> 00:14:12,520 building Wyomot kind of programmatically set, standing 294 00:14:12,520 --> 00:14:15,600 up an HTTP server in Java was quite an onerous process. 295 00:14:15,600 --> 00:14:18,920 You had to understand slightly opaque APIs, I suppose you could 296 00:14:18,920 --> 00:14:20,960 say, in the web servers that were available at the time. 297 00:14:20,960 --> 00:14:23,720 So part of the real value of Wyomot was you could paste in 298 00:14:23,720 --> 00:14:26,440 the original version. It was AJ Unit 4 rule. 299 00:14:26,800 --> 00:14:28,440 So you could paste in these two lines where there was an 300 00:14:28,440 --> 00:14:32,080 annotation and a class being UW. And in the background. 301 00:14:32,080 --> 00:14:34,480 That would mean that the the web server would would start up, 302 00:14:34,480 --> 00:14:37,440 bind to a port, configure itself in a, in a way that meant you 303 00:14:37,440 --> 00:14:39,440 could start using it and then shut itself down at the end of 304 00:14:39,440 --> 00:14:41,280 your test. And you didn't have to worry 305 00:14:41,280 --> 00:14:43,800 about any of that and any of, you know, sort of jetties 306 00:14:43,800 --> 00:14:46,400 internals or anything like that. So I think that was quite a 307 00:14:46,400 --> 00:14:48,680 powerful tool to to to gain adoption. 308 00:14:49,400 --> 00:14:51,600 Well, thanks for sharing all these learnings and insights, 309 00:14:51,600 --> 00:14:54,040 right? Maybe for those people who, you 310 00:14:54,040 --> 00:14:56,760 know, just started their career in the last five to 10 years, 311 00:14:56,760 --> 00:14:58,560 right? Maybe you would think this is a 312 00:14:58,560 --> 00:15:02,040 natural thing to do, like code as configuration, code as data, 313 00:15:02,120 --> 00:15:03,920 and all this fast bootstrap, right? 314 00:15:03,920 --> 00:15:06,520 You know, like starting up web server in one line or just 315 00:15:06,520 --> 00:15:08,640 annotation. I think these days these things 316 00:15:08,640 --> 00:15:11,080 are quite ubiquitous. But back then I think it was 317 00:15:11,120 --> 00:15:13,760 maybe more revolutionary. So I think kudos to you for 318 00:15:13,960 --> 00:15:16,600 thinking in that way. And I think looking at the 319 00:15:16,600 --> 00:15:19,040 success of Wire Mock, right, it's been around for quite a 320 00:15:19,040 --> 00:15:21,280 number of years. I don't get the chance to talk 321 00:15:21,280 --> 00:15:24,600 to so many open source founder who have this kind of project, 322 00:15:24,600 --> 00:15:26,400 right? And the last I checked, you have 323 00:15:26,400 --> 00:15:29,000 about 246 contributors on the GitHub. 324 00:15:29,440 --> 00:15:32,360 So that is kind of like quite a lot out of developers, you know, 325 00:15:32,400 --> 00:15:34,760 like, and not many companies also have like that number of 326 00:15:34,760 --> 00:15:36,360 developers, right, working as a team. 327 00:15:36,360 --> 00:15:39,360 But you're having this as part of the open source team, open 328 00:15:39,360 --> 00:15:41,280 source project. So maybe tell us a little bit 329 00:15:41,280 --> 00:15:43,840 more share for those people who want to build big open source 330 00:15:43,840 --> 00:15:47,120 project, how do you ensure that people are aligned or you have 331 00:15:47,440 --> 00:15:50,400 good amount of people willing to contribute and expanding the 332 00:15:50,400 --> 00:15:52,560 project? That's an interesting 1. 333 00:15:52,560 --> 00:15:55,120 I don't profess to be very expert at this, I have to say. 334 00:15:55,160 --> 00:15:58,840 So I, I probably didn't do anywhere near enough for a long 335 00:15:58,840 --> 00:16:01,680 time in the Wymot project to sort of promote contributor 336 00:16:01,680 --> 00:16:04,000 accessibility. But in Wymot, the company, we 337 00:16:04,000 --> 00:16:07,440 had a head of community working for us for a little while and he 338 00:16:07,440 --> 00:16:09,440 actually, he moved things forward enormously in that 339 00:16:09,440 --> 00:16:11,320 regard. So he did all the sort of 340 00:16:11,320 --> 00:16:13,520 obvious things around improving documentation, kind of 341 00:16:13,520 --> 00:16:17,040 signposting people to contribution guidelines and so 342 00:16:17,040 --> 00:16:18,880 on. Put things in places where you 343 00:16:18,880 --> 00:16:22,000 would expect to find them in GitHub, helped clean up a lot of 344 00:16:22,000 --> 00:16:24,240 things that just made it difficult to get started working 345 00:16:24,240 --> 00:16:25,920 with the source code, all of that kind of thing. 346 00:16:25,920 --> 00:16:28,760 So I think there's sort of a load of project hygiene factors, 347 00:16:28,760 --> 00:16:31,400 you could call them that. I suppose it's kind of the first 348 00:16:31,400 --> 00:16:34,760 run experience for contributors rather than users. 349 00:16:34,760 --> 00:16:37,320 And while I'd focused a lot on the users first run experience, 350 00:16:37,320 --> 00:16:39,760 I think I'd kind of neglected for a long time the contributors 351 00:16:39,760 --> 00:16:40,760 one. Really, you want to be able to 352 00:16:40,760 --> 00:16:44,840 check the project out, build it, run the tests, open it in an IDE 353 00:16:44,840 --> 00:16:47,240 and be able to kind of poke around and see how things work. 354 00:16:47,400 --> 00:16:50,520 And if you make it so that somebody's got to install a 355 00:16:50,520 --> 00:16:54,200 bunch of tools that can't be easily installed automatically 356 00:16:54,200 --> 00:16:56,560 and they have to jump through a lot of hoops before they can 357 00:16:56,560 --> 00:16:59,840 even start doing that, then you set the bar very high for them 358 00:16:59,840 --> 00:17:01,440 to show up and make a contribution. 359 00:17:01,440 --> 00:17:04,800 And they probably won't. I think setting clear guidelines 360 00:17:04,800 --> 00:17:07,480 around how you accept contributions and what you'll 361 00:17:07,480 --> 00:17:09,640 accept and what you won't. I mean, I've always tried quite 362 00:17:09,640 --> 00:17:12,760 hard to say to people, please come and so speak to us before 363 00:17:12,800 --> 00:17:15,960 writing a load of code because it's always awful to when you 364 00:17:15,960 --> 00:17:18,440 can see that someone's put loads of effort into building 365 00:17:18,440 --> 00:17:20,839 something new and you have to say, look, sorry, this probably 366 00:17:20,839 --> 00:17:22,800 doesn't belong in the core. So this is we're not going to 367 00:17:22,800 --> 00:17:25,440 merge this. So I think trying to be as 368 00:17:25,440 --> 00:17:28,119 upfront as possible about that kind of thing so that people 369 00:17:28,119 --> 00:17:29,800 feel like their time's being valued while they're 370 00:17:29,800 --> 00:17:32,200 contributing is definitely a good thing. 371 00:17:33,120 --> 00:17:34,680 Yeah. So I think you emphasize again 372 00:17:34,680 --> 00:17:37,160 the developer experience right before this term getting 373 00:17:37,160 --> 00:17:39,920 hijacked lately because of developer productivity and that 374 00:17:39,920 --> 00:17:41,760 thing, right. But it used to be a term, right? 375 00:17:41,760 --> 00:17:44,400 Developer experience, you know, the first time you check out the 376 00:17:44,400 --> 00:17:47,920 code, how do you get up to speed very fast API, the CLI 377 00:17:47,920 --> 00:17:50,440 experience and things like that. Thanks for emphasizing that 378 00:17:50,440 --> 00:17:53,080 again, because I can see that so many successful open source 379 00:17:53,080 --> 00:17:55,840 project, simply they have this investment on developer 380 00:17:55,840 --> 00:17:57,880 experience. And also not to mention the 381 00:17:57,880 --> 00:18:00,880 contribution guidelines and being being like a safe 382 00:18:00,880 --> 00:18:03,000 community for people to contribute, right? 383 00:18:03,280 --> 00:18:06,200 I think that's also another key. Let's go to the wire mock 384 00:18:06,200 --> 00:18:08,440 itself, right? So maybe tell us what is wire 385 00:18:08,440 --> 00:18:10,360 mock? Why people should consider using 386 00:18:10,360 --> 00:18:14,640 tools like wire mock? So in a nutshell, wire mock is 387 00:18:14,880 --> 00:18:17,920 an API mocking tool. What it allows you to do is to 388 00:18:17,920 --> 00:18:21,760 simulate the behaviour of networked APIs over the wire. 389 00:18:21,960 --> 00:18:25,480 It's conceptually similar to kind of object mocking or encode 390 00:18:25,480 --> 00:18:27,480 mocking for those that are familiar with those kind of 391 00:18:27,480 --> 00:18:30,280 techniques. But instead of substituting 392 00:18:30,640 --> 00:18:33,200 implementations of interfaces within your code or something 393 00:18:33,200 --> 00:18:36,880 along those lines, substituting function implementations, you're 394 00:18:36,880 --> 00:18:39,280 instead kind of going outside of the process and you're 395 00:18:39,280 --> 00:18:41,200 substituting something on the other side of a network 396 00:18:41,200 --> 00:18:44,080 connection. So if you're testing an app or a 397 00:18:44,080 --> 00:18:47,640 service that needs to call out to an API, it can still call out 398 00:18:47,640 --> 00:18:50,120 over a network interface it and you're still, when you're 399 00:18:50,120 --> 00:18:53,960 testing with API mocks like the sort of WI mock provides, you're 400 00:18:53,960 --> 00:18:56,920 still exercising kind of all the production code paths around 401 00:18:56,920 --> 00:18:59,840 networking and serialisation and all of those things that kind of 402 00:18:59,840 --> 00:19:02,000 have to happen in order to integrate with an external 403 00:19:02,000 --> 00:19:04,120 service. And there's a number of benefits 404 00:19:04,120 --> 00:19:06,720 to doing this versus doing object mocking. 405 00:19:07,200 --> 00:19:09,880 I would argue that the particularly kind of micro 406 00:19:09,880 --> 00:19:13,360 services and systems being increasingly composed from large 407 00:19:13,360 --> 00:19:17,080 numbers of networks components, a lot of the complexity of our 408 00:19:17,080 --> 00:19:20,680 systems has kind of moved onto the wires or has moved into the 409 00:19:20,680 --> 00:19:22,680 code which governs what happens on the wires. 410 00:19:23,360 --> 00:19:26,160 While you can create abstractions within your code 411 00:19:26,160 --> 00:19:29,400 base for the things that happen on the wire and then do all of 412 00:19:29,400 --> 00:19:31,840 your testing with respect to those, you know, you're 413 00:19:31,840 --> 00:19:34,720 essentially abstracting away a lot of the real world complexity 414 00:19:34,720 --> 00:19:37,760 which is going to bite you in production if it isn't correct. 415 00:19:38,360 --> 00:19:42,240 The the the benefit of of doing the kind of over the wire 416 00:19:42,240 --> 00:19:45,480 mocking is that you're bringing into your inner loop of 417 00:19:45,480 --> 00:19:48,560 development, I suppose, the the ability to learn and get 418 00:19:48,560 --> 00:19:50,600 feedback about that real world integration. 419 00:19:50,600 --> 00:19:52,720 You know when you're working with something that closely 420 00:19:52,720 --> 00:19:56,040 resembles a real API, rather than your own abstraction with 421 00:19:56,040 --> 00:19:58,600 your own set of assumptions about it as the the thing you're 422 00:19:58,600 --> 00:20:00,320 integrating with. Right. 423 00:20:00,520 --> 00:20:01,960 So I think it's really interesting, right? 424 00:20:01,960 --> 00:20:04,320 For people who may not experience using this kind of 425 00:20:04,320 --> 00:20:07,800 game mocking tool, if you refer to the testing pyramid where you 426 00:20:07,800 --> 00:20:10,720 have the unit test, integration test, end to end test, maybe API 427 00:20:10,720 --> 00:20:13,960 test somewhere as well, where do you think why a mock sits in 428 00:20:13,960 --> 00:20:16,480 that pyramid? Can it be in multiple layers as 429 00:20:16,480 --> 00:20:18,000 well? Like how do you think we should 430 00:20:18,200 --> 00:20:21,280 apply this kind of API mocking tool in the testing pyramid 431 00:20:21,280 --> 00:20:23,440 paradigm? It's funny you should mention 432 00:20:23,440 --> 00:20:24,960 this actually. I wrote a blog post on this a 433 00:20:24,960 --> 00:20:28,120 few weeks ago which garnered a lot of vigorous conversation. 434 00:20:28,120 --> 00:20:32,120 You could say what I've observed in practice over the years of 435 00:20:32,120 --> 00:20:35,960 doing lots of projects and using API mocking as as part of them 436 00:20:35,960 --> 00:20:39,440 is that the really useful kind of band of testing migrates to 437 00:20:39,440 --> 00:20:41,720 the middle. So you get the testing trophy 438 00:20:41,960 --> 00:20:44,840 shape more often than you do the the testing pyramid shape. 439 00:20:45,280 --> 00:20:47,240 I kind of have this sense you shouldn't be aiming for a 440 00:20:47,240 --> 00:20:49,240 particular shape at all. You know, the the shape as a 441 00:20:49,240 --> 00:20:52,320 heuristic is probably that I think there are better ways of 442 00:20:52,320 --> 00:20:55,600 figuring out how you should balance your testing strategy, I 443 00:20:55,600 --> 00:20:58,520 suppose. Whereas I, I think kind of back 444 00:20:58,520 --> 00:21:01,000 when I first started developing, well when I first started doing 445 00:21:01,000 --> 00:21:03,760 test driven development, anything above the unit test 446 00:21:03,760 --> 00:21:06,560 layer, anything integrated at all tended to be very expensive 447 00:21:06,560 --> 00:21:09,200 and difficult and tests were costly to build. 448 00:21:09,200 --> 00:21:12,720 The infrastructure around them was costly to build and running 449 00:21:12,720 --> 00:21:15,640 them tended to be difficult and slow and error prone and so on 450 00:21:15,640 --> 00:21:17,880 like that. So the reason for the testing 451 00:21:17,880 --> 00:21:20,440 pyramid being the shape it was is that if you push as much as 452 00:21:20,440 --> 00:21:23,480 possible down to the sort of unit layer, then things will be 453 00:21:23,480 --> 00:21:25,000 sort of fast and easy and so on like that. 454 00:21:25,000 --> 00:21:28,040 But I think the combination of, as you mentioned, sort of 455 00:21:28,080 --> 00:21:31,040 frameworks and servers and all that kind of thing shrinking to 456 00:21:31,040 --> 00:21:34,840 be small and fast boot up and all that kind of thing. 457 00:21:35,480 --> 00:21:37,800 Combined with the the availability of tools like wire 458 00:21:37,800 --> 00:21:41,480 mock, you can now do far more of your testing. 459 00:21:41,680 --> 00:21:43,600 What I think of as the Goldilocks zone in the middle, 460 00:21:43,600 --> 00:21:46,520 where you're isolating individual apps and services by 461 00:21:46,520 --> 00:21:50,240 mocking out sort of outside of them on the network, but you're 462 00:21:50,240 --> 00:21:52,520 still get getting the benefit. Most of your tests are 463 00:21:52,520 --> 00:21:54,960 exercising real production code paths. 464 00:21:55,560 --> 00:21:57,280 Combine that with sort of improvements in things like 465 00:21:57,600 --> 00:22:00,840 observability and debugging tools, you can get the sort of 466 00:22:00,840 --> 00:22:03,440 the maximum bang for your buck I think a lot of the time by 467 00:22:03,440 --> 00:22:05,000 writing tests that way, if that makes sense. 468 00:22:05,720 --> 00:22:08,080 Right. And I think the emphasis here is 469 00:22:08,080 --> 00:22:10,920 also not in terms of the so-called the functional 470 00:22:11,040 --> 00:22:12,800 accuracy of the input output, right? 471 00:22:12,800 --> 00:22:14,840 But it's more also like to simulate like what you mentioned 472 00:22:14,840 --> 00:22:17,280 like the Http://behaviours the networks, right? 473 00:22:17,280 --> 00:22:19,400 So it's more like an integration kind of thing, right? 474 00:22:19,840 --> 00:22:22,280 And I think these days people are also familiar with this 475 00:22:22,280 --> 00:22:25,080 thing called contract testing. How do you actually 476 00:22:25,080 --> 00:22:27,520 differentiate between API mocking and contract testing? 477 00:22:27,720 --> 00:22:29,520 Are they the same or are they different? 478 00:22:29,840 --> 00:22:33,640 If different than in which part? Yeah, it's an interesting one. 479 00:22:33,840 --> 00:22:37,240 They're they're kind of adjacent concepts and mocking is often 480 00:22:37,240 --> 00:22:38,760 used as part of contract testing. 481 00:22:38,760 --> 00:22:41,360 So actually why mock is used as part of the Spring Cloud 482 00:22:41,360 --> 00:22:45,040 contract testing module. The way the way sort of those 483 00:22:45,040 --> 00:22:47,760 kind of consumer driven contract testing tools tend to work is 484 00:22:47,760 --> 00:22:51,600 that you define a mock, which is kind of just sufficient for your 485 00:22:51,600 --> 00:22:53,280 client code, the thing that you're building. 486 00:22:53,640 --> 00:22:57,440 And then you run some tests with the tool and the tool then sort 487 00:22:57,440 --> 00:23:00,560 of derives a set of tests that it can apply to the server based 488 00:23:00,560 --> 00:23:02,800 on what you mocked. So mocking is kind of integral 489 00:23:02,800 --> 00:23:05,760 to the process in that regard. More abstractly, the notion of 490 00:23:05,760 --> 00:23:08,240 contract testing in the context of mocking is really important. 491 00:23:08,240 --> 00:23:10,880 I think that there are a whole load of benefits to kind of 492 00:23:10,880 --> 00:23:12,640 building things with mocks beyond. 493 00:23:12,760 --> 00:23:15,080 There are benefits around sort of things like environments, 494 00:23:15,080 --> 00:23:16,760 stability and so on like that as well. 495 00:23:16,760 --> 00:23:19,200 But I think there's also a similar benefit that you get to 496 00:23:19,200 --> 00:23:22,720 kind of mock driven test driven development where you are kind 497 00:23:22,720 --> 00:23:25,440 of saying, this is my interface definition, this is the thing 498 00:23:25,440 --> 00:23:27,840 that we're building to and there are going to be two 499 00:23:27,840 --> 00:23:29,440 implementations of it right from the off. 500 00:23:29,440 --> 00:23:31,120 There's going to be the mock implementation and then 501 00:23:31,120 --> 00:23:32,960 eventually there's going to be the real implementation. 502 00:23:33,360 --> 00:23:37,920 Yeah, I know there is a contract that both must adhere to and 503 00:23:38,040 --> 00:23:42,040 contract testing is valuable in that context as well. 504 00:23:42,640 --> 00:23:44,720 The conversation happens a lot. 1 of the biggest sources of 505 00:23:44,760 --> 00:23:46,640 scepticism about mocking, I suppose. 506 00:23:46,640 --> 00:23:48,560 I'm sorry, I'm going off on a slight tangent here, but 507 00:23:48,560 --> 00:23:51,600 hopefully it will make sense. One of the sort of points of 508 00:23:51,600 --> 00:23:54,720 resistance around mocking that you hear a lot is this idea that 509 00:23:54,960 --> 00:23:57,200 it can't really be trusted. It's not really realistic. 510 00:23:57,200 --> 00:24:01,080 And you see some organisations who will do the vast majority of 511 00:24:01,080 --> 00:24:03,120 their testing in a sort of completely integrated 512 00:24:03,400 --> 00:24:06,760 arrangement. And it's this kind of testing 513 00:24:06,760 --> 00:24:10,640 where all of it is kind of, I guess the sort of slightly 514 00:24:10,760 --> 00:24:13,800 diffuse goal of we're going to exercise the system in a way 515 00:24:13,800 --> 00:24:16,320 that the a user would and then we're going to see if anything 516 00:24:16,320 --> 00:24:18,480 goes wrong with it. And we're not going to attempt 517 00:24:18,480 --> 00:24:21,640 to kind of categorize tests by risk with managing or anything 518 00:24:21,640 --> 00:24:22,640 like that. We're just going to do a whole 519 00:24:22,640 --> 00:24:24,480 load of testing and maybe things will break or maybe they 520 00:24:24,480 --> 00:24:27,120 weren't. This tends to be a very costly 521 00:24:27,120 --> 00:24:29,520 and inefficient and, you know, in some ways very kind of error 522 00:24:29,520 --> 00:24:33,040 prone way of testing. And an alternative to that, 523 00:24:33,040 --> 00:24:36,400 making effective use of mocks, I would say is to have an explicit 524 00:24:36,400 --> 00:24:39,960 kind of segmentation of what risks you're trying to managed 525 00:24:39,960 --> 00:24:42,880 with different kinds of testing. 1 type of testing you're doing 526 00:24:42,880 --> 00:24:45,440 where you're saying, given that my assumptions about the 527 00:24:45,440 --> 00:24:48,000 external contracts I'm integrating with are correct, 528 00:24:48,560 --> 00:24:51,040 does the thing that I'm testing actually work the way I expected 529 00:24:51,040 --> 00:24:52,440 to? Is it functionally correct? 530 00:24:52,800 --> 00:24:55,240 And then outside of that, you can have a usually much smaller 531 00:24:55,240 --> 00:24:57,280 set of tests saying, are my assumptions correct? 532 00:24:57,640 --> 00:25:00,320 There's, there's still the, the, the place for kind of integrated 533 00:25:00,320 --> 00:25:03,360 testing in order to say both in terms of contract testing and 534 00:25:03,360 --> 00:25:06,200 some fully integrated testing, where you're saying, are these 535 00:25:06,200 --> 00:25:09,000 contracts being adhered to by the, the real system where you 536 00:25:09,000 --> 00:25:11,600 know, the mock contract and the real contract the same thing. 537 00:25:12,160 --> 00:25:15,360 But by sort of separating those two risks out, you can save 538 00:25:15,360 --> 00:25:18,480 yourself a whole load of, you know, energy and runtime and 539 00:25:18,480 --> 00:25:22,360 labour and all sorts of things versus sort of saying, I, I just 540 00:25:22,360 --> 00:25:24,160 don't trust this. I'm going to do everything fully 541 00:25:24,160 --> 00:25:25,760 integrated. Yeah. 542 00:25:25,760 --> 00:25:27,800 So I think when you mentioned risk based approach, right, I 543 00:25:27,800 --> 00:25:30,040 had a previous episode also covering about this. 544 00:25:30,080 --> 00:25:33,320 I think tests should be driven by the kind of risk they want to 545 00:25:33,320 --> 00:25:35,320 cover, right. So it's not like you can test 546 00:25:35,320 --> 00:25:37,960 any different permutations are available out there. 547 00:25:38,040 --> 00:25:40,920 And also not to mention when you integrate with third party APIs 548 00:25:40,920 --> 00:25:43,600 that you don't actually have control or you don't have like a 549 00:25:43,600 --> 00:25:46,520 line of communication with, it's very hard to simulate corner 550 00:25:46,520 --> 00:25:50,200 cases, H cases behavior that and sometimes could happen, right? 551 00:25:50,200 --> 00:25:53,200 But it is random instead of, you know, like you could drive it 552 00:25:53,200 --> 00:25:55,680 from a certain input, right? So sometimes all this can be 553 00:25:55,680 --> 00:25:57,760 simulated through a mock behaviour, right? 554 00:25:57,800 --> 00:25:59,960 You know, using wire mock or some other tools available out 555 00:25:59,960 --> 00:26:01,760 there. So I think thanks for mentioning 556 00:26:01,760 --> 00:26:04,240 about this risk coverage, right one. 557 00:26:04,480 --> 00:26:06,400 More observations about you make about that actually. 558 00:26:06,400 --> 00:26:09,040 So it's, I'm glad you mentioned that aspect of it because 559 00:26:09,400 --> 00:26:12,360 another challenge, I guess within testing is the economics 560 00:26:12,360 --> 00:26:14,240 of testing sort of different scenarios. 561 00:26:14,240 --> 00:26:17,160 And quite often there are things that are relatively 562 00:26:17,160 --> 00:26:20,440 straightforward to test where there's happy paths or near 563 00:26:20,440 --> 00:26:23,760 happy paths and don't require a lot of data in order to 564 00:26:23,760 --> 00:26:26,520 implement that kind of thing. And then as you kind of step 565 00:26:26,520 --> 00:26:29,360 away from those cases, often things get progressively more 566 00:26:29,360 --> 00:26:33,040 difficult if you have cases where you need to load the 567 00:26:33,040 --> 00:26:35,560 systems you depend on with very specific data or very large 568 00:26:35,560 --> 00:26:38,520 amounts of data. And then as you alluded to, I 569 00:26:38,520 --> 00:26:42,520 think the cases where you want to simulate failures or errors 570 00:26:42,520 --> 00:26:45,600 that you can't really make these systems produce on demand, they 571 00:26:45,600 --> 00:26:47,280 become sort of difficult or impossible. 572 00:26:47,360 --> 00:26:50,760 The other downside of integrated testing is you tend to gravitate 573 00:26:50,760 --> 00:26:53,280 towards the tests that you can practically implement rather 574 00:26:53,280 --> 00:26:55,480 than maybe the ones that are actually most valuable in 575 00:26:55,480 --> 00:26:58,080 managing risk. And the advantage of bringing 576 00:26:58,080 --> 00:27:00,160 MOX into the equation is that they kind of flatten the 577 00:27:00,160 --> 00:27:02,920 economics out. The difficulty involved in 578 00:27:03,200 --> 00:27:06,400 testing some weird edge case is about the same as the difficulty 579 00:27:06,400 --> 00:27:08,880 involved in testing your sort of #1 happy path. 580 00:27:09,840 --> 00:27:11,480 Right. And it's, it's very important, 581 00:27:11,480 --> 00:27:13,800 especially in the integration kind of scenario, right? 582 00:27:13,800 --> 00:27:16,200 There will always be certain cases that you never thought 583 00:27:16,200 --> 00:27:18,680 before and sometimes when it happened, you want to cover it 584 00:27:18,680 --> 00:27:20,680 as well, right? So maybe in the future so that 585 00:27:20,680 --> 00:27:23,120 it won't happen again. So again, like this is a quite a 586 00:27:23,120 --> 00:27:25,520 common, typical use cases whenever you integrate with 587 00:27:25,520 --> 00:27:28,440 third party APIs, right? In the explanation you just 588 00:27:28,440 --> 00:27:31,440 gave, you mentioned that actually a mock driven 589 00:27:31,520 --> 00:27:32,960 development kind of thing, right? 590 00:27:33,200 --> 00:27:36,840 So I think this is quite similar to the concept of API design 591 00:27:36,840 --> 00:27:38,400 first or something around that, right? 592 00:27:38,640 --> 00:27:41,360 So you know, I trader of Weimock, what kind of 593 00:27:41,360 --> 00:27:44,040 development workflows should people do whenever they want to 594 00:27:44,080 --> 00:27:46,440 integrate with third party APIs? Or you know, in the micro 595 00:27:46,440 --> 00:27:48,600 service environment, is it always the case that we should 596 00:27:48,600 --> 00:27:52,920 always come with the API first? So I I think in certainly in 597 00:27:52,920 --> 00:27:55,280 cases where you're in environments where there is an 598 00:27:55,280 --> 00:27:58,680 API that needs to be built and there is some opportunity for 599 00:27:58,680 --> 00:28:01,440 collaboration between consumer and producer. 600 00:28:01,440 --> 00:28:04,560 So very typical in micro service environments, you have this 601 00:28:04,560 --> 00:28:08,000 problem of a new product feature needs to be built, but there's 602 00:28:08,000 --> 00:28:10,920 this API and it doesn't have this API feature yet. 603 00:28:10,920 --> 00:28:13,520 And the mobile team need it and the web team need it, the data 604 00:28:13,520 --> 00:28:16,120 team need it. So there has to be this kind of 605 00:28:16,120 --> 00:28:19,000 collaborative design process. And I think it can be very 606 00:28:19,000 --> 00:28:20,480 valuable to build things upfront. 607 00:28:20,560 --> 00:28:23,200 So, so design things upfront and to actually think about these 608 00:28:23,200 --> 00:28:26,640 things rather than writing code first and then generating the 609 00:28:26,640 --> 00:28:28,840 design from it for all of the usual reasons. 610 00:28:28,880 --> 00:28:31,920 You know, sitting and thinking about things and designing them 611 00:28:31,920 --> 00:28:33,840 and actually sort of mulling over the consequences of 612 00:28:33,840 --> 00:28:36,800 designing things a particular way generally produces better 613 00:28:36,800 --> 00:28:39,400 results than just kind of bashing the keys and going for 614 00:28:39,400 --> 00:28:41,760 it. But I think also specifically in 615 00:28:41,760 --> 00:28:45,440 the context of APIs, I guess, and this is another facet of 616 00:28:45,440 --> 00:28:48,080 kind of organizations that rely heavily on integrated testing. 617 00:28:48,080 --> 00:28:50,960 I think there are places where internal APIs are kind of like 618 00:28:50,960 --> 00:28:53,840 these opaque pipes where two things talk through them, but 619 00:28:53,840 --> 00:28:56,360 nobody really cares what's going on as long as the system 620 00:28:56,360 --> 00:28:59,840 functions overall. And that's maybe OK when there's 621 00:28:59,840 --> 00:29:01,680 sort of a producer and one consumer. 622 00:29:01,680 --> 00:29:05,360 But then if The thing is to be genuinely an API, if at some 623 00:29:05,360 --> 00:29:07,240 point there are going to be 10 other teams who are consuming 624 00:29:07,240 --> 00:29:10,360 this, then they're not sort of driving the design forward 625 00:29:10,360 --> 00:29:12,240 thoughtfully. So if you continue to take that 626 00:29:12,240 --> 00:29:14,840 approach where if these two endpoints can communicate, then 627 00:29:14,840 --> 00:29:18,640 it's all fine, then you'll probably make erratic design 628 00:29:18,640 --> 00:29:21,600 choices that aren't really consistent with the organization 629 00:29:21,600 --> 00:29:24,440 style or the API style. You'll probably introduce 630 00:29:24,440 --> 00:29:26,560 breaking changes. You'll do things which are going 631 00:29:26,640 --> 00:29:29,680 to make it harder and harder for more and more people to adopt 632 00:29:29,680 --> 00:29:31,800 this. So actually treating it as a 633 00:29:31,800 --> 00:29:36,440 proper API is something which is to be Co designed and evolved in 634 00:29:36,440 --> 00:29:38,920 a way which avoids breaking changes and surprises and all 635 00:29:38,920 --> 00:29:40,800 that kind of thing is really important. 636 00:29:41,080 --> 00:29:44,800 Where I think mocking fits into this is that mocks can be 637 00:29:44,800 --> 00:29:47,560 prototypes of APIs. I mean, this is something that 638 00:29:47,560 --> 00:29:50,080 our cloud product is particularly oriented towards is 639 00:29:50,080 --> 00:29:53,160 the idea that when you're designing an API, you want to to 640 00:29:53,160 --> 00:29:55,440 kind of get it into people's hands so that they can try it 641 00:29:55,440 --> 00:29:57,440 and they can validate it as quickly as possible. 642 00:29:58,200 --> 00:30:01,920 I think a lot of API first type tools stop shorts of actually 643 00:30:01,920 --> 00:30:04,120 giving you something practical you can work with, you know, so 644 00:30:04,160 --> 00:30:06,320 you have a design document and maybe you have a bunch of 645 00:30:06,400 --> 00:30:08,200 governance rules that you can run against them, which is 646 00:30:08,200 --> 00:30:10,000 great. The way I think of it is they're 647 00:30:10,000 --> 00:30:12,080 kind of validated by inspection. You know, you have a lot of 648 00:30:12,080 --> 00:30:14,480 people looking at them and going yeah, OK, this looks about 649 00:30:14,480 --> 00:30:15,920 right. Whereas really what you should 650 00:30:15,920 --> 00:30:18,640 be doing is giving it to developers and saying OK, go and 651 00:30:18,640 --> 00:30:21,240 code something, try and build some version of the thing that 652 00:30:21,320 --> 00:30:23,120 you want to use this API feature for. 653 00:30:23,640 --> 00:30:27,040 You can guarantee that nearly always there'll be that oh 654 00:30:27,080 --> 00:30:30,560 moment where you realise that despite the fact you spend 3 655 00:30:30,560 --> 00:30:33,400 hours in a design session talking to people about what 656 00:30:33,400 --> 00:30:34,560 this API design should look like. 657 00:30:34,560 --> 00:30:36,640 The second you try and write some code that uses it, you 658 00:30:36,640 --> 00:30:39,880 realise some really obvious thing that you've missed some 659 00:30:39,880 --> 00:30:42,400 fields that you're absolutely going to need in the data or 660 00:30:42,400 --> 00:30:44,040 otherwise you can't proceed with your workflow. 661 00:30:44,600 --> 00:30:47,280 And it's that kind of thing. You know, the sooner you kind of 662 00:30:47,280 --> 00:30:49,400 get it out to the, the woodwork, the better. 663 00:30:49,840 --> 00:30:52,400 Particularly in organisations that are built where APIs are 664 00:30:52,400 --> 00:30:55,600 being built is kind of as facades over legacy stacks and 665 00:30:55,600 --> 00:30:57,240 so on like that. Or where the the cost of 666 00:30:57,240 --> 00:31:00,560 implementing an API feature is very, very high and itself 667 00:31:00,560 --> 00:31:04,200 involves kind of lots of coordination, then the value of 668 00:31:04,200 --> 00:31:07,360 sort of shifting left, that kind of feedback point where you 669 00:31:07,360 --> 00:31:09,320 discover whether or not the API design is right. 670 00:31:09,320 --> 00:31:12,320 It's huge. You know, you see these banking 671 00:31:12,320 --> 00:31:15,280 environments and so on like that where an API is facade over 672 00:31:15,280 --> 00:31:19,360 decades and decades of legacy tech and it can literally take 673 00:31:19,360 --> 00:31:21,480 months to surface 11 new piece of data. 674 00:31:21,480 --> 00:31:24,360 I mean, there was a friend of mine who works for a big bank 675 00:31:24,360 --> 00:31:27,480 who was saying he had to sort of project manager a kind of three 676 00:31:27,480 --> 00:31:30,160 month piece of rework because there was 1 field missing from 677 00:31:30,160 --> 00:31:34,240 an API, and that involved this stack of five teams going all 678 00:31:34,240 --> 00:31:37,080 the way down to some really old text to expose this field. 679 00:31:37,120 --> 00:31:39,800 So yeah, personally I'm a very strong believer in using mocking 680 00:31:39,800 --> 00:31:42,760 as prototyping as a way of surfacing those problems early 681 00:31:42,760 --> 00:31:45,200 so that you can deal with them as cheaply as possible. 682 00:31:46,040 --> 00:31:48,960 Yeah, I used to work in a bank as well and I could really 683 00:31:48,960 --> 00:31:52,440 relate that experience, right? So changing especially when it 684 00:31:52,440 --> 00:31:55,240 involved a lot of coordination with different teams, especially 685 00:31:55,240 --> 00:31:56,840 distributed teams some more, right? 686 00:31:57,120 --> 00:31:59,840 So it's always a good idea to nail down the interface, the 687 00:31:59,840 --> 00:32:02,800 contract, the API spec and things like that before you 688 00:32:02,800 --> 00:32:05,880 actually start implementing and figure out the issue later on, 689 00:32:05,880 --> 00:32:07,400 right? So if you can kind of like shift 690 00:32:07,400 --> 00:32:10,600 left the API design, I think that will be definitely useful. 691 00:32:10,920 --> 00:32:13,800 And besides, if everything really to the spec, right, like 692 00:32:13,800 --> 00:32:16,320 you nailed it down, you implement as expected by the 693 00:32:16,320 --> 00:32:17,880 spec. I think when you first 694 00:32:17,880 --> 00:32:20,600 integrate, it would work typically quite beautifully. 695 00:32:20,600 --> 00:32:23,760 Like everyone will just be happy simply because you have verified 696 00:32:23,760 --> 00:32:25,160 everything in a simulated behavior. 697 00:32:25,160 --> 00:32:27,960 And when it comes the real production one, it actually 698 00:32:27,960 --> 00:32:31,240 works really, really well. So thanks for mentioning about 699 00:32:31,240 --> 00:32:33,880 this, right? Another aspect of using tools 700 00:32:33,880 --> 00:32:36,280 like wire mock you mentioned is about developer experience and 701 00:32:36,280 --> 00:32:38,680 developer productivity. So maybe we are not talking 702 00:32:38,680 --> 00:32:40,680 about, you know, like open source developer experience, but 703 00:32:40,680 --> 00:32:43,240 it's more like the developer experience team, right, 704 00:32:43,240 --> 00:32:45,080 engineering team and productivity. 705 00:32:45,280 --> 00:32:48,080 So tell us what are some aspects that you think tools like Wild 706 00:32:48,080 --> 00:32:50,880 Mock helps in terms of improving developer experience and 707 00:32:50,880 --> 00:32:52,480 productivity? Sure. 708 00:32:52,560 --> 00:32:55,400 I think we've touched on some of these already, but the biggest 709 00:32:55,400 --> 00:32:58,960 aspect is simply that in a lot of environments where you have 710 00:32:58,960 --> 00:33:03,400 lots of APIs and lots of different types of API, varying 711 00:33:03,480 --> 00:33:05,840 levels of sort of developer experience and accessibility 712 00:33:05,840 --> 00:33:07,400 themselves. They come from different 713 00:33:07,400 --> 00:33:09,400 sources, different vendors, all that kind of thing. 714 00:33:10,160 --> 00:33:12,360 Your development environment, the one that you as the 715 00:33:12,360 --> 00:33:15,280 developer are working within, where that environment is 716 00:33:15,280 --> 00:33:18,680 made-up significantly of kind of other people's APIs, the 717 00:33:18,680 --> 00:33:20,640 stability. And as I say, they think the 718 00:33:20,640 --> 00:33:23,520 kind of the developer experience that those APIs themselves 719 00:33:23,760 --> 00:33:27,840 expose has a huge impact on your ability to be productive. 720 00:33:28,240 --> 00:33:31,960 So, you know, concretely, if you're integrating with a third 721 00:33:31,960 --> 00:33:36,880 party API, which is old, it's maybe run by a vendor who didn't 722 00:33:36,880 --> 00:33:38,760 put a huge premium on developer experience. 723 00:33:38,760 --> 00:33:43,480 And as a result, it has a sandbox which is slow, flaky, 724 00:33:43,720 --> 00:33:46,560 maybe not always running quite the same code as the production 725 00:33:46,560 --> 00:33:50,360 system, hard to get large amounts of data into, doesn't 726 00:33:50,360 --> 00:33:52,680 have the capacity to do any performance testing. 727 00:33:53,160 --> 00:33:56,880 All of these things will impact you directly as a developer, you 728 00:33:56,880 --> 00:33:59,520 know, by destabilizing your environment and as if you're 729 00:33:59,640 --> 00:34:02,120 working on a sort of highly integrated piece of software. 730 00:34:02,520 --> 00:34:06,320 Every one of these external AP is that isn't presenting you an 731 00:34:06,320 --> 00:34:10,000 excellent developer experience is kind of degrading the quality 732 00:34:10,000 --> 00:34:12,960 of yours by a little bit. It's a little bit like sort of 733 00:34:13,080 --> 00:34:16,080 availability where you're, you know, if you're in a highly 734 00:34:16,080 --> 00:34:19,639 networked environment, kind of every non perfect sort of 735 00:34:19,639 --> 00:34:22,280 availability number for each individual dependency reduces 736 00:34:22,280 --> 00:34:25,120 yours by a proportionate amount. And it's similar with developer 737 00:34:25,120 --> 00:34:26,800 experience. And I think if you're wrestling 738 00:34:26,800 --> 00:34:29,440 with dozens of different third party sandboxes that have all 739 00:34:29,440 --> 00:34:32,040 got these different sets of problems associated with them, 740 00:34:32,040 --> 00:34:35,719 then you can spend a lot of time not actually doing your job. 741 00:34:36,480 --> 00:34:39,520 It's not just third parties, it's APIs built on top of legacy 742 00:34:39,520 --> 00:34:41,840 systems, sometimes sort of commercial off the shelf 743 00:34:41,840 --> 00:34:44,040 software that's sort of installed on premise. 744 00:34:44,040 --> 00:34:47,280 And maybe you've only got one kind of non production license 745 00:34:47,280 --> 00:34:49,280 for us where everyone's sharing the same environment. 746 00:34:49,600 --> 00:34:52,639 It's running on some ancient server infrastructure that no 747 00:34:52,639 --> 00:34:55,440 one wants to buy any more or so you can't run any more of it and 748 00:34:55,840 --> 00:34:58,760 all of these kinds of problems. So mocking really get lets you 749 00:34:58,760 --> 00:35:01,160 kind of build this sort of insulating wall, I guess around 750 00:35:01,160 --> 00:35:02,880 your own environment. You can kind of say, I don't 751 00:35:02,880 --> 00:35:04,800 need all of that while I'm doing my development. 752 00:35:04,800 --> 00:35:07,400 I'm going to keep it. I'm going to sort of build an 753 00:35:07,400 --> 00:35:11,040 environment that I can fully control and, you know, get that 754 00:35:11,040 --> 00:35:13,320 kind of determinism and performance and all of those 755 00:35:13,320 --> 00:35:15,760 things that I need in order for my developers to remain in flow. 756 00:35:16,680 --> 00:35:18,040 Yeah. So I think maybe it's slightly 757 00:35:18,040 --> 00:35:21,120 related to that as well as if let's say those third party APIs 758 00:35:21,120 --> 00:35:23,800 or systems, right, needs kind of like a hardware driven, you 759 00:35:23,800 --> 00:35:26,160 know, like you have to install something on a certain location 760 00:35:26,160 --> 00:35:28,160 probably that's also hard to simulate, right. 761 00:35:28,480 --> 00:35:31,360 So I think if you are able to mock that, I think that would be 762 00:35:31,360 --> 00:35:33,440 perfect as well. And I think you mentioned 763 00:35:33,440 --> 00:35:34,600 something quite interesting, right? 764 00:35:34,600 --> 00:35:39,160 These days, I mean, many people work with, you know, SAS, APIs, 765 00:35:39,160 --> 00:35:41,440 even micro services within their environment. 766 00:35:41,720 --> 00:35:45,080 And as we can see, the trend is going more and more towards that 767 00:35:45,080 --> 00:35:47,360 distributed system, right? And there are a lot of 768 00:35:47,360 --> 00:35:50,200 challenges definitely working with distributed services. 769 00:35:50,520 --> 00:35:53,320 So maybe in your view, what are some insights that you think we 770 00:35:53,320 --> 00:35:55,840 can think about in terms of improving our experience in 771 00:35:55,840 --> 00:35:58,000 working with this type of distributed system? 772 00:35:58,920 --> 00:36:01,040 Yeah, I guess a lot of the things I've already mentioned, 773 00:36:01,040 --> 00:36:04,000 you know, I think treating the API is the messages you pass 774 00:36:04,000 --> 00:36:06,800 around between these systems as kind of first class artefacts. 775 00:36:07,080 --> 00:36:09,600 However you do that, you know, ones where you make them visible 776 00:36:09,600 --> 00:36:11,800 and legible, you make them things that you treat as 777 00:36:12,200 --> 00:36:15,680 independent artefacts of design, you apply governance rules to 778 00:36:15,680 --> 00:36:17,000 them, you try and make them consistent. 779 00:36:17,000 --> 00:36:18,960 All of these kinds of things will make it easier. 780 00:36:19,320 --> 00:36:21,920 And then I think, like I say, adopting testing strategies that 781 00:36:21,920 --> 00:36:25,040 take advantage of this. So having this notion of I will 782 00:36:25,040 --> 00:36:28,200 do most of my testing out to the edge of my boundary for my 783 00:36:28,200 --> 00:36:30,200 service or my app or whatever I'm interested in. 784 00:36:30,200 --> 00:36:32,800 And I will assume that my assumptions about my contracts 785 00:36:32,800 --> 00:36:34,680 are correct. But then I'll have other 786 00:36:34,680 --> 00:36:37,040 supporting testing strategies that will be about validating 787 00:36:37,040 --> 00:36:40,400 whether that's actually true. It's a sort of a vintage time at 788 00:36:40,400 --> 00:36:42,720 the moment, I suppose for tooling generally in the API 789 00:36:42,720 --> 00:36:45,000 space, I mean, but there's lots of progress happening around 790 00:36:45,000 --> 00:36:48,480 standards at the moment. So open API has added a Razzo 791 00:36:48,480 --> 00:36:49,960 and overlays and all these kind of things. 792 00:36:49,960 --> 00:36:53,400 So I think the richness with which you can describe AP is and 793 00:36:53,480 --> 00:36:58,560 you can increasingly sort of describe facets of APIs in ways 794 00:36:58,560 --> 00:37:02,280 that are useful for them, verifying them, observing them, 795 00:37:02,280 --> 00:37:03,880 documenting them, all that kind of thing. 796 00:37:04,280 --> 00:37:07,040 You know, I think that both the standards and the tooling around 797 00:37:07,040 --> 00:37:09,560 those standards is improving a pace at the moment. 798 00:37:10,080 --> 00:37:12,680 Yeah, there's this sort of diffuse area, you know, kind of 799 00:37:12,680 --> 00:37:14,560 referred to as API observability, which I think 800 00:37:14,560 --> 00:37:18,040 looks really interesting at the moment where the the sort of 801 00:37:18,040 --> 00:37:20,640 consolidation around those standards and sort of open API 802 00:37:20,640 --> 00:37:24,080 in particular that kind of allows you to then look at API 803 00:37:24,080 --> 00:37:26,480 traffic and draw lots of kind of rich conclusions from it. 804 00:37:26,480 --> 00:37:28,680 So I think it's going to be increasingly necessary to take 805 00:37:28,680 --> 00:37:31,480 advantage of that kind of tooling where you have these 806 00:37:31,480 --> 00:37:35,120 vast API landscapes, you can figure out what's going on 807 00:37:35,120 --> 00:37:38,480 within, you know, when and how things are changing and and what 808 00:37:38,480 --> 00:37:41,160 the direction of travel is. Yeah, you mentioned standard. 809 00:37:41,160 --> 00:37:44,400 I think Open API has been kind of like the go to standard these 810 00:37:44,400 --> 00:37:45,920 days, right? But I could remember back then 811 00:37:45,920 --> 00:37:49,200 when REST was just starting to pick in terms of adoption, 812 00:37:49,200 --> 00:37:50,960 right? There was no, you know, such 813 00:37:50,960 --> 00:37:52,760 tools. And for people who work with 814 00:37:52,760 --> 00:37:55,280 SOAP UI, you know, this SOAP land before, right? 815 00:37:55,480 --> 00:37:57,520 I think one good thing about SOAP is like it's pretty 816 00:37:57,520 --> 00:37:59,680 standardized. You know, it's an interface that 817 00:37:59,680 --> 00:38:01,840 is well defined. You can actually use any kind of 818 00:38:01,840 --> 00:38:03,640 tools as long as it conforms to the spec. 819 00:38:03,880 --> 00:38:06,720 So I think thank God that, you know, Open API exists, right? 820 00:38:06,720 --> 00:38:08,160 It used to be called Swagger, by the way. 821 00:38:08,360 --> 00:38:10,960 So I think that these tools and standardization definitely is a 822 00:38:10,960 --> 00:38:13,400 good thing, right? For us developers so that we can 823 00:38:13,480 --> 00:38:14,720 easily integrate with each other. 824 00:38:15,120 --> 00:38:17,880 There's another trend that I see in API world called API 825 00:38:18,200 --> 00:38:21,200 virtualization or maybe a simulation, that kind of thing. 826 00:38:21,200 --> 00:38:23,520 So maybe if you can tell us what is this actually? 827 00:38:23,520 --> 00:38:26,800 Is this something about virtual machines or something like that? 828 00:38:27,560 --> 00:38:29,800 Yeah, I'm glad you brought this up actually, because this is a, 829 00:38:29,800 --> 00:38:32,920 there's definitely kind of a language problem in API mocking 830 00:38:32,920 --> 00:38:35,960 or simulation or virtualisation depending on how you you want to 831 00:38:36,120 --> 00:38:38,200 look at it. So to to give a very brief 832 00:38:38,200 --> 00:38:40,200 history lesson that might explain this a little bit, there 833 00:38:40,200 --> 00:38:43,720 was the sort of SOAP UI and even kind of before that, I would 834 00:38:43,720 --> 00:38:46,160 argue that past a generation of tools that called themselves 835 00:38:46,160 --> 00:38:48,520 service virtualisation. The product that really 836 00:38:48,520 --> 00:38:51,200 popularized it was Lisa from it was originally from a company 837 00:38:51,200 --> 00:38:53,080 called ITCO and then it was Computer Associates. 838 00:38:53,080 --> 00:38:55,720 And that was they used the category term service 839 00:38:55,720 --> 00:38:57,560 virtualization. And I think this was before kind 840 00:38:57,560 --> 00:39:00,760 of VM Ware and that kind of virtualization really took off. 841 00:39:00,760 --> 00:39:02,960 So it was a lot less of a confusing term back in those 842 00:39:02,960 --> 00:39:04,800 days. Mocking obviously sort of came 843 00:39:04,800 --> 00:39:07,760 out of the agile movement came out of the kind of London 844 00:39:07,760 --> 00:39:10,080 extreme programming way of doing things, I guess. 845 00:39:10,640 --> 00:39:13,720 And I, I thought I was very into that around the, the, the time 846 00:39:13,720 --> 00:39:15,240 that I first started building Wymock. 847 00:39:15,240 --> 00:39:17,760 And so, you know, mocking is a sort of language in a set of 848 00:39:17,760 --> 00:39:20,640 idioms kind of made most sense. And one of the reasons for 849 00:39:20,640 --> 00:39:23,840 Wymock's appeal was it sort of spoke that the language of that 850 00:39:23,840 --> 00:39:26,080 kind of growing cohort of agile developers. 851 00:39:26,440 --> 00:39:29,280 So the mocking thing sort of came from that period and that 852 00:39:29,280 --> 00:39:32,480 set of practices API virtualization, I guess is a 853 00:39:32,480 --> 00:39:35,200 kind of reheating of service virtualization, I suppose. 854 00:39:35,640 --> 00:39:38,120 I, I don't think there's really, I don't feel like there's really 855 00:39:38,120 --> 00:39:39,920 a sort of meaningful difference there. 856 00:39:39,920 --> 00:39:44,320 And then simulation is this sort of term that some open source 857 00:39:44,400 --> 00:39:46,520 tool vendors and commercial vendors have sort of started 858 00:39:46,520 --> 00:39:49,480 using as a further break with the past that's maybe a little 859 00:39:49,480 --> 00:39:53,200 bit more descriptive than than virtualization or mocking. 860 00:39:53,440 --> 00:39:55,600 I think one thing is worth clearing when I talk about 861 00:39:55,600 --> 00:39:58,520 mocking personally, and, and I'm, I'm probably in a, 862 00:39:58,840 --> 00:40:01,600 something of a minority here, I have quite a broadview of what 863 00:40:01,600 --> 00:40:04,640 that could mean. I think it can mean very simple 864 00:40:04,640 --> 00:40:06,920 kind of. Canned responses, you know, the 865 00:40:06,920 --> 00:40:09,080 thing that I think most people associate mocking with all the 866 00:40:09,080 --> 00:40:12,480 way up to sort of quite complex, rich, dynamic behaviour. 867 00:40:12,840 --> 00:40:15,400 We actually did the survey within the company recently 868 00:40:15,400 --> 00:40:18,120 about this and we sort of discovered that most people seem 869 00:40:18,120 --> 00:40:22,080 to see those two as being very different parts of the spectrum. 870 00:40:22,080 --> 00:40:24,640 If you like, you know, the mocking is the sort of simple 871 00:40:24,960 --> 00:40:27,240 canned example type thing that you do when you're writing a 872 00:40:27,680 --> 00:40:30,400 unit test or a narrow integration test. 873 00:40:30,960 --> 00:40:33,000 And then simulation and virtualisation. 874 00:40:33,000 --> 00:40:34,760 And all of that is where you're doing things that are 875 00:40:34,760 --> 00:40:38,440 data-driven or sort of templated and dynamic or stateful or 876 00:40:38,640 --> 00:40:40,920 introducing any of those kind of sources of complexity. 877 00:40:41,440 --> 00:40:43,800 So yeah, I hope that's cleared up a little bit. 878 00:40:43,800 --> 00:40:46,560 I think maybe the convention we're going for is mocking if 879 00:40:46,560 --> 00:40:49,240 it's if you're doing it in code in your inner loop, and then 880 00:40:49,240 --> 00:40:51,640 maybe simulation if you're doing more complex stuff and you're 881 00:40:51,640 --> 00:40:54,120 doing it in your outer loop as a simple rule of thumb thing. 882 00:40:54,720 --> 00:40:56,440 Right. And sometimes I think I see 883 00:40:56,440 --> 00:40:59,800 people also introduce this kind of like fault injection as part 884 00:40:59,800 --> 00:41:02,240 of their simulation, right? So that you can kind of like 885 00:41:02,240 --> 00:41:05,680 simulate the failure behavior that your API sometimes is not 886 00:41:06,080 --> 00:41:08,600 designed for, I guess, right. So thanks for clarifying that 887 00:41:08,600 --> 00:41:11,040 and a little bit of history as well how all this naming 888 00:41:11,040 --> 00:41:12,880 actually came. So thanks for that. 889 00:41:13,440 --> 00:41:16,440 So I think talking about technology these days, we can't 890 00:41:16,440 --> 00:41:19,640 run away from AI. So what do you see AI 891 00:41:19,640 --> 00:41:22,640 involvement in this API mocking and API development? 892 00:41:23,600 --> 00:41:25,880 I don't like making predictions about AI because it feels like 893 00:41:25,880 --> 00:41:28,440 everything's changed within 5 minutes of you making any kind 894 00:41:28,440 --> 00:41:30,720 of declaration. But I guess from what I'm saying 895 00:41:30,720 --> 00:41:33,640 at the moment, one thing that seems to be becoming clear is 896 00:41:33,640 --> 00:41:36,840 that the LLMS need to interact with APIs in order to get things 897 00:41:36,840 --> 00:41:39,840 done. And while there's some 898 00:41:39,840 --> 00:41:43,080 discussion happening at the moment about whether APIs will 899 00:41:43,080 --> 00:41:46,360 go away and agents or LLMS or whatever will just kind of 900 00:41:46,360 --> 00:41:48,960 become web scrapers and we we won't need to build separate 901 00:41:48,960 --> 00:41:51,360 APIs anymore. Firstly, I'm, I'm not so sure 902 00:41:51,360 --> 00:41:53,760 about that because I, I think when you're looking at sort of 903 00:41:53,800 --> 00:41:57,240 consumer facing web-based systems, then there is an 904 00:41:57,240 --> 00:41:59,920 argument that they generally have much better human UIS than 905 00:41:59,920 --> 00:42:02,640 they do APIs. But I think it's a whole huge 906 00:42:02,640 --> 00:42:05,160 swathe of software out there that is only accessible via its 907 00:42:05,160 --> 00:42:07,360 API. So in order to make those kind 908 00:42:07,360 --> 00:42:09,600 of things available to AI applications, it's going to be 909 00:42:09,600 --> 00:42:13,120 necessary to provide APIs that AIS can use. 910 00:42:13,120 --> 00:42:17,800 And it seems that AILLMS are supposed kind of they have a 911 00:42:17,800 --> 00:42:19,840 different taste in APIs and developers do. 912 00:42:20,320 --> 00:42:24,560 And the kind of very normalized DRY style that we tend to go for 913 00:42:24,560 --> 00:42:28,200 in developer API design is not very AI friendly. 914 00:42:28,200 --> 00:42:32,560 That AI tend to prefer things where all the context is kind of 915 00:42:32,560 --> 00:42:35,120 there and present and made explicit in one place rather 916 00:42:35,120 --> 00:42:37,920 than it being, you know, achieved through references and 917 00:42:37,920 --> 00:42:40,160 shorthands kind of all over the place. 918 00:42:40,680 --> 00:42:46,200 So I think there's going to be a move to start building APIs 919 00:42:46,200 --> 00:42:49,160 which are intended for agents and that adopt this very 920 00:42:49,480 --> 00:42:52,760 denormalized style relative to previous generation APIs. 921 00:42:53,120 --> 00:42:55,480 So I guess that's one thing I would say another thing I think 922 00:42:55,480 --> 00:42:59,200 is happening generally is the AI coding assistance. 923 00:42:59,200 --> 00:43:01,880 And I guess you know, the sort of agents that are just starting 924 00:43:01,880 --> 00:43:04,600 to come into the fore now for assisting with coding, I think 925 00:43:04,600 --> 00:43:08,360 are producing a a lot of demand and revealing bottlenecks and 926 00:43:08,360 --> 00:43:10,200 kind of enterprise software delivery systems. 927 00:43:10,600 --> 00:43:13,760 So it's interesting that Google Dora report that came out, I 928 00:43:13,760 --> 00:43:16,520 think at the end of last year, you know, which is quite a big 929 00:43:16,520 --> 00:43:19,400 sort of quantitative study of developer productivity and the 930 00:43:19,400 --> 00:43:20,680 sort of various influences on it. 931 00:43:21,240 --> 00:43:24,000 And one of the things they looked at is the use of AI 932 00:43:24,000 --> 00:43:26,080 coding assistance. And they found that on average, 933 00:43:26,080 --> 00:43:29,680 it was actually there was a net negative productivity impact 934 00:43:30,000 --> 00:43:32,800 where these were present. And my hypothesis on this is a 935 00:43:32,800 --> 00:43:35,880 sort of theory of constraints. You know, that if you make the 936 00:43:36,440 --> 00:43:38,800 thing, it's something faster, which is not the thing which is 937 00:43:38,800 --> 00:43:42,600 constraining your system's throughput overall, then you 938 00:43:42,600 --> 00:43:45,760 will just build up work in progress kind of around wherever 939 00:43:45,760 --> 00:43:47,560 the, the, the actual bottleneck is. 940 00:43:47,560 --> 00:43:51,120 And that a lot of organisations don't have the downstream kind 941 00:43:51,120 --> 00:43:54,800 of software delivery throughput to be able to cope with the more 942 00:43:54,800 --> 00:43:57,880 untested code being produced. I guess add to that that we 943 00:43:57,880 --> 00:44:00,680 probably at the moment trust the code produced by LLMS a bit less 944 00:44:00,680 --> 00:44:02,520 than that produced by most human beings. 945 00:44:03,160 --> 00:44:06,120 I think there's this big problem to solve generally in in terms 946 00:44:06,120 --> 00:44:10,200 of how organisations do end to end software delivery in a way 947 00:44:10,200 --> 00:44:13,600 that can take advantage of the the productivity benefits of 948 00:44:13,640 --> 00:44:15,480 coding assistance. Right. 949 00:44:15,680 --> 00:44:18,040 So I'm sure, I mean, many people would have tried, you know, 950 00:44:18,040 --> 00:44:20,480 coding assistance, right, including generating tests. 951 00:44:20,480 --> 00:44:23,840 And I'm sure people will be able to generate while more compliant 952 00:44:23,840 --> 00:44:25,680 tests through coding assistant, right? 953 00:44:25,880 --> 00:44:28,360 So I'm actually interested in the one thing that you mentioned 954 00:44:28,360 --> 00:44:32,120 about testing API that is going to be used by the LLM or the AI 955 00:44:32,400 --> 00:44:34,760 agents, right? These days people talk about the 956 00:44:34,760 --> 00:44:37,680 genetic AI, you know, agent that can collaborate with each other 957 00:44:37,680 --> 00:44:40,720 and solve a particular task. And these days there are also so 958 00:44:40,720 --> 00:44:42,960 many new tools for doing deep research, right? 959 00:44:42,960 --> 00:44:47,200 Gemini, ChatGPT, Open AI. Also, maybe I don't know whether 960 00:44:47,200 --> 00:44:50,320 you have experience or not, how do you typically see this kind 961 00:44:50,320 --> 00:44:53,600 of API mocking that we need to do in order for us to simulate 962 00:44:53,600 --> 00:44:55,480 an LLM agent actually using our API? 963 00:44:55,480 --> 00:44:58,360 Is there such thing or is this something that we have to kind 964 00:44:58,360 --> 00:45:00,080 of like still figure it out along the way? 965 00:45:00,840 --> 00:45:03,680 I'm not aware of anything built and mature and in the public 966 00:45:03,680 --> 00:45:06,440 domain that's doing this yet. It is something that we're 967 00:45:06,440 --> 00:45:08,440 looking at as a company and trying to figure out. 968 00:45:08,520 --> 00:45:10,960 I feel like I'm not yet in a position to make any strong 969 00:45:10,960 --> 00:45:13,120 statements about what this is or how it works. 970 00:45:13,320 --> 00:45:14,640 You're right, it is possible to get. 971 00:45:14,640 --> 00:45:18,080 So I suppose back to my earlier comment about why I'm not having 972 00:45:18,080 --> 00:45:20,200 a kind of externalized data format. 973 00:45:20,880 --> 00:45:23,880 One of the big advantages of that, and because it's been 974 00:45:23,880 --> 00:45:26,480 around for a long time and the internet's full of examples of 975 00:45:26,600 --> 00:45:29,360 how to create this data, LLMS are actually quite good at 976 00:45:29,360 --> 00:45:31,680 producing Wymot mocks. You know, you can ask for 977 00:45:31,680 --> 00:45:34,880 something in Wymot Jason format, and in my experience, it will 978 00:45:34,880 --> 00:45:36,760 produce something pretty good, pretty useful. 979 00:45:37,200 --> 00:45:39,800 So one of the things we're looking at is this idea that we 980 00:45:39,800 --> 00:45:44,160 should be asking our AI coding assistance to generate the APIs 981 00:45:44,160 --> 00:45:46,160 that they want. So if you're using an AI coding 982 00:45:46,160 --> 00:45:50,120 assistant in order to build an agent for something, then we 983 00:45:50,120 --> 00:45:53,400 should be sort of asking the LLM for an API design and then 984 00:45:53,400 --> 00:45:55,760 expressing it in what I'm not. So then we can go in and 985 00:45:55,760 --> 00:45:58,360 immediately test it in our Magentic workflow. 986 00:45:58,960 --> 00:46:01,760 This is an idea we're exploring. Whether it will take us anywhere 987 00:46:01,760 --> 00:46:03,880 or prove to be viable, I guess time will tell. 988 00:46:03,880 --> 00:46:07,640 But being able to use mocking to remove non determinism when 989 00:46:07,640 --> 00:46:10,240 you're testing these flows is a valuable use case for it as 990 00:46:10,240 --> 00:46:13,520 well. So where you have a whole load 991 00:46:13,520 --> 00:46:17,600 of workflow steps and some of them involve calling an LLM and 992 00:46:17,600 --> 00:46:20,640 some of them involve calling out to fetch data or perform 993 00:46:20,640 --> 00:46:24,520 operations in external systems, our APIs, you have a difficult 994 00:46:24,520 --> 00:46:26,440 enough problem with non determinism anyway with the 995 00:46:26,440 --> 00:46:29,400 LLMS. And if you're also integrating 996 00:46:29,400 --> 00:46:31,640 with a bunch of sandboxes whose data maybe isn't completely 997 00:46:31,640 --> 00:46:34,560 stable and so on like that, then you're sort of multiplying the 998 00:46:34,560 --> 00:46:37,360 problem of non determinism and how you can sort of repeatedly 999 00:46:37,360 --> 00:46:38,640 test. So I think there's sort of a 1000 00:46:38,640 --> 00:46:42,000 more mundane use case there just in terms of limiting the scope 1001 00:46:42,000 --> 00:46:44,200 of the things that can change between one test and the next. 1002 00:46:45,080 --> 00:46:47,560 Yeah, I think what you mentioned is kind of like a cool use case, 1003 00:46:47,560 --> 00:46:49,840 right? So using AI LLM to actually 1004 00:46:49,840 --> 00:46:52,880 produce this more compliant, you know, basically creating a lot 1005 00:46:52,880 --> 00:46:55,760 of APM mocks that you can test, simulate since the very 1006 00:46:55,760 --> 00:46:57,520 beginning. It also aids in terms of, you 1007 00:46:57,520 --> 00:47:00,480 know, this API first design that we just talked about earlier. 1008 00:47:00,840 --> 00:47:03,600 So I think a really good use case for people who probably 1009 00:47:03,600 --> 00:47:06,800 want to build a more robust API development experience within 1010 00:47:06,800 --> 00:47:09,600 your team, right? Please also try using this 1011 00:47:09,600 --> 00:47:12,160 AILLM. So I think AI LM for me also is 1012 00:47:12,240 --> 00:47:15,400 has been my go to thing as well. Like sometimes I feel addicted 1013 00:47:15,400 --> 00:47:18,080 these days. So I'm sure like once you 1014 00:47:18,160 --> 00:47:20,960 generate a lot of things using AI and maybe one day you kind of 1015 00:47:20,960 --> 00:47:23,440 like make it more natural in terms of the workflow, right? 1016 00:47:23,440 --> 00:47:26,440 It's not like something that you have to think about South Tom, I 1017 00:47:26,440 --> 00:47:28,720 have one last question for you before we wrap up our 1018 00:47:28,720 --> 00:47:30,760 conversation. Normally I ask my guests to 1019 00:47:30,760 --> 00:47:32,920 actually share this thing called the three technical leadership 1020 00:47:32,920 --> 00:47:34,480 with them. You can think of it just like 1021 00:47:34,480 --> 00:47:35,800 advice that you want to give to us. 1022 00:47:36,000 --> 00:47:38,760 So maybe if you can share your version to us? 1023 00:47:39,720 --> 00:47:40,400 Sure. OK. 1024 00:47:40,440 --> 00:47:44,200 So I did a bit of thinking about this before and I hope these 1025 00:47:44,200 --> 00:47:45,760 don't turn out to be completely trite. 1026 00:47:45,880 --> 00:47:47,960 The first one I was going to talk about, it's not really 1027 00:47:48,240 --> 00:47:50,640 directly related to the things that we've talked about already, 1028 00:47:50,640 --> 00:47:54,520 but an observation about kind of hiring engineers for a team, 1029 00:47:54,600 --> 00:47:57,520 particularly in a startup. My bit of wisdom I wanted to 1030 00:47:57,520 --> 00:47:59,560 share was to sort of challenge a bit of conventional wisdom, I 1031 00:47:59,560 --> 00:48:02,240 guess, which is that if you're building a startup that you 1032 00:48:02,240 --> 00:48:06,640 should look for these kind of scrappy, very customer focused, 1033 00:48:06,640 --> 00:48:10,280 very business focused engineers who will kind of move fast and 1034 00:48:10,280 --> 00:48:12,600 break things. I suppose if that's not too much 1035 00:48:12,600 --> 00:48:14,040 of A sort of tainted way of putting it. 1036 00:48:14,400 --> 00:48:16,200 You know, while there are developers out there who can be 1037 00:48:16,200 --> 00:48:19,560 both scrappy and great engineers, my experience of 1038 00:48:19,560 --> 00:48:22,240 hiring is that they there tends to be a bit of a spectrum of 1039 00:48:22,240 --> 00:48:25,600 people where you have people who are a great engineers who are 1040 00:48:25,600 --> 00:48:27,000 very rigorous and so on like that. 1041 00:48:27,000 --> 00:48:30,880 But it may be not sort of business and customer oriented 1042 00:48:30,880 --> 00:48:32,560 in the way that the the people at the other end are. 1043 00:48:32,560 --> 00:48:35,640 And then the people at the other end have more of those focuses, 1044 00:48:35,640 --> 00:48:39,200 but maybe don't produce such great quality code or tend to 1045 00:48:39,200 --> 00:48:41,680 introduce technical debt at a high rate when they build 1046 00:48:41,680 --> 00:48:43,800 things. The point I, I want to make is 1047 00:48:43,800 --> 00:48:47,880 that I think you can hire the rigorous engineers and then you 1048 00:48:47,880 --> 00:48:51,040 can teach them sort of how, I guess, help them to, to expand 1049 00:48:51,040 --> 00:48:54,160 their comfort zone to, to do the kinds of things that are needed 1050 00:48:54,160 --> 00:48:57,520 to make a start up work. So adopting more of a commercial 1051 00:48:57,520 --> 00:49:01,400 focus and more of a user and customer focus, but also that 1052 00:49:01,400 --> 00:49:04,520 kind of flexibility around things like quality and use of 1053 00:49:04,520 --> 00:49:06,920 technical debt strategically and all of that kind of stuff. 1054 00:49:07,000 --> 00:49:09,680 And I would argue that actually it's easier to hire people who 1055 00:49:09,680 --> 00:49:12,600 are, are great engineers and then show them how to do that 1056 00:49:12,600 --> 00:49:15,520 stuff rather than hire people which are scrappy and terrible 1057 00:49:15,520 --> 00:49:17,840 engineers and then try to make them good engineers. 1058 00:49:18,200 --> 00:49:19,840 It's harder to move in that direction. 1059 00:49:20,760 --> 00:49:23,520 So that's number one. The second one I think is I've 1060 00:49:23,520 --> 00:49:26,160 probably mostly covered it already, but I, I guess I wanted 1061 00:49:26,160 --> 00:49:30,320 to say the making an, an open source project successful. 1062 00:49:30,680 --> 00:49:32,840 It's almost a sort of product management cliche really, but 1063 00:49:32,840 --> 00:49:36,840 it's kind of about making your own users successful and making 1064 00:49:36,840 --> 00:49:38,200 them look good amongst their peers. 1065 00:49:38,680 --> 00:49:42,480 And I think a large part of that is if they are going to kind of 1066 00:49:42,480 --> 00:49:45,440 stake their reputation on introducing the tool that you've 1067 00:49:45,440 --> 00:49:48,760 built into their organization, then you need to show that 1068 00:49:48,760 --> 00:49:51,160 you're behind it and that you're serious about it. 1069 00:49:51,160 --> 00:49:53,120 And that this isn't some developers whim. 1070 00:49:53,120 --> 00:49:55,920 It's a serious project that you're going to document and 1071 00:49:55,920 --> 00:49:58,560 support and stand by and like I said earlier, kind of do all the 1072 00:49:58,560 --> 00:50:01,680 boring work in order to make a success out of in the long term. 1073 00:50:02,080 --> 00:50:04,120 So I think that's number two. And I guess the third one kind 1074 00:50:04,120 --> 00:50:06,080 of relates to some of the things we talked about in terms of 1075 00:50:06,080 --> 00:50:09,560 working in larger engineering orgs, being productive in 1076 00:50:09,720 --> 00:50:12,720 organisations that have multiple teams and many services. 1077 00:50:12,720 --> 00:50:15,880 And all that kind of thing is about a couple of key things in 1078 00:50:15,880 --> 00:50:20,560 my opinion. 1 is decoupling seems to some extent individuals 1079 00:50:20,560 --> 00:50:23,880 from the sort of broader context of the technology enough that 1080 00:50:23,880 --> 00:50:25,920 they're, you know, their own sort of working set their 1081 00:50:25,920 --> 00:50:30,360 context is at a manageable size. And then secondly, kind of as I 1082 00:50:30,360 --> 00:50:33,360 lead you to earlier as well, look for as many opportunities 1083 00:50:33,360 --> 00:50:35,960 as you can to sort of shift feedback left, you know, to get 1084 00:50:35,960 --> 00:50:38,840 meaningful feedback about the quality and fitness for purpose 1085 00:50:38,840 --> 00:50:41,200 of your code to try and make that happen as early as 1086 00:50:41,200 --> 00:50:44,440 possible, even if actually that means doing a bit more design 1087 00:50:44,440 --> 00:50:46,840 and planning around things like API's and interfaces. 1088 00:50:47,640 --> 00:50:49,560 Well, so thanks for sharing. I think it's pretty unique. 1089 00:50:49,560 --> 00:50:52,000 I would say the last one, right? And especially also the hiring. 1090 00:50:52,000 --> 00:50:55,600 Actually this is my first time hearing about hiring the maybe 1091 00:50:55,600 --> 00:50:57,720 more good quality engineer, right? 1092 00:50:57,720 --> 00:51:00,440 But try to train them to be a little bit more scrappy, right? 1093 00:51:00,440 --> 00:51:03,440 A little bit more fast in terms of producing, maybe not so much 1094 00:51:03,480 --> 00:51:06,880 up to the quality standard that he aspires, but at least you 1095 00:51:06,880 --> 00:51:09,880 produce business outcome and generate value faster. 1096 00:51:10,240 --> 00:51:13,120 So Tom, for people who want to connect with you or learn more 1097 00:51:13,240 --> 00:51:16,600 things related to Wyomop and API mocking in general, is there a 1098 00:51:16,600 --> 00:51:18,080 place where they can find you online? 1099 00:51:18,640 --> 00:51:22,400 Yeah, so I mean, LinkedIn is my main watering hole these days, 1100 00:51:22,400 --> 00:51:25,640 so you can find me there. And yeah, if you want to drop me 1101 00:51:25,640 --> 00:51:27,920 an e-mail at any point, I'm Tom at wyomop.org. 1102 00:51:28,520 --> 00:51:30,440 Thanks for that. I'll put it in the show notes. 1103 00:51:30,440 --> 00:51:33,200 So thank you so much, Tom, for sharing this conversation today. 1104 00:51:33,200 --> 00:51:36,160 I think we all learn a lot about API mocking and best practices 1105 00:51:36,200 --> 00:51:38,400 on doing that. Thank you very much for having 1106 00:51:38,400 --> 00:51:40,000 me as well, it's been great fun.