WEBVTT 00:00:00.000 --> 00:00:02.000 Hedgehog is not an out. 00:00:02.000 --> 00:00:04.000 It's not a thing you do. 00:00:04.000 --> 00:00:06.000 It's a way that you do something. 00:00:06.000 --> 00:00:07.000 It's agility. 00:00:07.000 --> 00:00:09.000 And so you do things in an agile way. 00:00:09.000 --> 00:00:14.000 It's a really difficult problem because everybody wants to be told what to do. 00:00:14.000 --> 00:00:21.000 When it's scary, when it's unknown, people are looking around for that figure that says, don't worry, I've got it covered. 00:00:21.000 --> 00:00:23.000 Do it this way. It'll be fine. 00:00:26.000 --> 00:00:31.000 Hello and welcome to episode 44 of the Metacast Behind the Scene Podcast. 00:00:31.000 --> 00:00:35.000 This is Arnab and with me, I have my co-host, Ilya. 00:00:35.000 --> 00:00:38.000 We are the founders of Metacast. 00:00:38.000 --> 00:00:48.000 And today, we have an amazing guest with us, perhaps the biggest influence in my life as a software engineer 00:00:48.000 --> 00:00:51.000 so far. And say hello, Dave Thomas. 00:00:51.000 --> 00:00:53.000 Hello, Dave Thomas. 00:00:53.000 --> 00:00:55.000 What was the kind of you to say? 00:00:55.000 --> 00:01:09.000 I'll let you introduce yourself in a little bit, but I just want to start with, like I said, the influence that you have had in my life and career, back when I started at Amazon as an SD, like an entry-level engineer. 00:01:09.000 --> 00:01:15.000 One of the engineers in my team suggested that I read this book, the pragmatic programmer. 00:01:15.000 --> 00:01:22.000 You've done so many renowned things, but this is the thing that, like, immediately, I think, connect with you. 00:01:22.000 --> 00:01:38.000 And this book, aside from all the best practices and the teachings from it, I think it fundamentally changed the way I approach software development in that I always need to be a craftsman. 00:01:38.000 --> 00:01:40.000 I always need to be practicing. 00:01:40.000 --> 00:01:53.000 I think some of that goes into us creating this company, Ilya and me, because after getting promoted and promoted and promoted, you get away from actually doing the craftsman things, right? 00:01:53.000 --> 00:01:58.000 And after I think getting into that habit, I was not happy with that eventually. 00:01:58.000 --> 00:02:01.000 And so, Ilya and I decided, let's go build something else. 00:02:01.000 --> 00:02:17.000 So that's kind of like the foundational things that you have had in me, but your book also helped me evangelize unit testing, CI, CD infrastructure, all of these best practices early on at Amazon and elsewhere too now. 00:02:17.000 --> 00:02:19.000 So thank you for it. 00:02:19.000 --> 00:02:21.000 I have the book right here with me. 00:02:21.000 --> 00:02:27.000 This is a 2009, I looked it up, and that's kind of like when I read it the first time, so it makes sense, yeah. 00:02:27.000 --> 00:02:31.000 Cool. Of course, that makes me feel very, very old. 00:02:31.000 --> 00:02:33.000 But apart from that, that's cool. 00:02:33.000 --> 00:02:37.000 Yeah, so please introduce yourself to our listeners. 00:02:37.000 --> 00:02:39.000 Well, my name is Dave Thomas. 00:02:39.000 --> 00:02:44.000 I'm English, but I've been living in the US now for 30-something years. 00:02:44.000 --> 00:02:45.000 My wife is American. 00:02:45.000 --> 00:02:52.000 I started off programming 1972, I think. 00:02:52.000 --> 00:02:56.000 And I have probably programmed just about every day since then. 00:02:56.000 --> 00:02:58.000 Fundamentally, I enjoy it. 00:02:58.000 --> 00:03:05.000 It's kind of like my happy place is writing code and discovering things along the way. 00:03:05.000 --> 00:03:08.000 So I had a pretty standard kind of career. 00:03:08.000 --> 00:03:12.000 I did computer science at university in London. 00:03:12.000 --> 00:03:18.000 I was doing a PhD program and I got recruited away by what nowadays would be called a startup. 00:03:18.000 --> 00:03:20.000 Back then we called them sweatshops. 00:03:20.000 --> 00:03:28.000 It was the best experience because this was a company that was formed to write custom software for people. 00:03:28.000 --> 00:03:36.000 And because of the fact they were small and they were just starting to grow, they said yes to everything. 00:03:36.000 --> 00:03:44.000 The range of different industries and project types and people that I got exposed to was phenomenal. 00:03:44.000 --> 00:03:47.000 And the assumption was yes, we can do it. 00:03:47.000 --> 00:03:50.000 That kind of left me in this position where I really didn't have any excuses. 00:03:50.000 --> 00:03:54.000 I couldn't say well, you can't really do that because we'd committed to do it. 00:03:54.000 --> 00:03:58.000 I learned how to basically get things done in code. 00:03:58.000 --> 00:04:00.000 And that was just absolutely fantastic. 00:04:00.000 --> 00:04:06.000 And I stayed with them for a while. I moved across briefly to what was at the time. 00:04:06.000 --> 00:04:10.000 I think the United Kingdom's only surviving computer manufacturer. 00:04:10.000 --> 00:04:13.000 And I joined their kind of research place. 00:04:13.000 --> 00:04:17.000 It was called CTL or ITL depending on the year. 00:04:17.000 --> 00:04:23.000 And they produced a media computer, which was quite an old fashioned architecture. 00:04:23.000 --> 00:04:32.000 But it was cheap and it was made in the UK, which meant that for various government contracts and defense contracts and everything else it was important. 00:04:32.000 --> 00:04:36.000 But it also meant we got some pretty weird stuff we're asked to do. 00:04:36.000 --> 00:04:52.000 One of my most fondly remembered projects was we got a job with the European Space Agency writing or supplying the system to do the on the ground checkout for the Geotosatellite that went to see Halley's comet. 00:04:52.000 --> 00:04:59.000 That involved some bespoke hardware, a very, very wide, very high speed parallel interface. 00:04:59.000 --> 00:05:07.000 There could suck data off all of the various test points and record it, which meant changes to obviously the hardware, but also to the operating system. 00:05:07.000 --> 00:05:11.000 And we had to write some really pretty cool code to intercept it. 00:05:11.000 --> 00:05:15.000 And there was micro code running on the actual controller itself. 00:05:15.000 --> 00:05:25.000 And the high spot obviously is we got to go across to Holland and get our stuff working in the test lab, which is where everybody wears the bunny suits and it's all white. 00:05:25.000 --> 00:05:29.000 And you have this sort of golden thing in the middle, which is the satellite. 00:05:29.000 --> 00:05:31.000 That was good fun. That was very good fun. 00:05:31.000 --> 00:05:32.000 What's here was it? 00:05:32.000 --> 00:05:34.000 Oh, now you're asking. 00:05:34.000 --> 00:05:46.000 I can't remember early ish 80s, I think, but I'm sure Google will prove me wrong. Don't ask me dates. I have no idea about dates. 00:05:46.000 --> 00:05:53.000 But did that for a while? Then I formed my own company in the UK. Well, actually, that's not quite true. 00:05:53.000 --> 00:06:01.000 A friend from this company that we just talked about and I as a side project developed a terminal emulator. 00:06:01.000 --> 00:06:04.000 Like as an open source project or. 00:06:04.000 --> 00:06:10.000 Now, I mean, the idea of a public internet was still five years away. 00:06:10.000 --> 00:06:15.000 Opera existed and there were universities that talked onto universities. 00:06:15.000 --> 00:06:23.000 But we downloaded software using dial-up modems and we were connected services like Compuserve. 00:06:23.000 --> 00:06:25.000 Look it up folks. Look it up. 00:06:25.000 --> 00:06:27.000 So no, I'll open source. 00:06:27.000 --> 00:06:35.000 But no, this is a product and it's claimed to fame. It ran on digital equipment, microse and it also run on IBM PCs. 00:06:35.000 --> 00:06:44.000 And it's claimed to fame was you could actually connect to multiple computers at the same time and multiplex them onto one screen. 00:06:44.000 --> 00:06:50.000 That found quite a big market in the financial marketplace where real estate is really, really tough. 00:06:50.000 --> 00:06:57.000 So this got to the point where it actually became viable. So we formed a company and we sold that. 00:06:57.000 --> 00:07:01.000 And then we started writing software for people. That was really good fun. 00:07:01.000 --> 00:07:08.000 Again, we were in that lean hungry stage. So we would say yes to everything. And so we got to do some pretty wild things. 00:07:08.000 --> 00:07:16.000 Along the way accumulated like basically experience working on all sorts of different projects and styles. 00:07:16.000 --> 00:07:20.000 Absolutely, absolutely. Also kind of like learning what not to do. 00:07:20.000 --> 00:07:27.000 It's a lot easier to see things go wrong when it directly affects your bottom line. 00:07:27.000 --> 00:07:33.000 And so we got very good rapid feedback when we were doing things wrong. And that was that was useful. 00:07:33.000 --> 00:07:41.000 So at some point we became the UK point of contact for a US computer manufacturer called Stratus. 00:07:41.000 --> 00:07:47.000 And what they had was a large mini computer that was fault tolerant. 00:07:47.000 --> 00:07:53.000 Everything was duplicated. Everything ran in parallel. And you could go up to it and like pull boards out. 00:07:53.000 --> 00:07:56.000 They would carry on running with that interruption, which is kind of cool. 00:07:56.000 --> 00:08:01.000 And so we started doing work with that again, a big market in the city of London. 00:08:01.000 --> 00:08:05.000 And they sent across their a sale support person to help us. 00:08:05.000 --> 00:08:08.000 And this sale support at some point went back to the States. 00:08:08.000 --> 00:08:12.000 And a few years later I'd also left the company at this point. 00:08:12.000 --> 00:08:19.000 And I was doing independent consulting. And he phoned me up and said, Hey, look, I'm now working at a financial company. 00:08:19.000 --> 00:08:22.000 We're doing switching of debit cards, credit cards. 00:08:22.000 --> 00:08:26.000 And I promised them that we would rewrite all of that switch software in a camera. 00:08:26.000 --> 00:08:29.000 It was like six months or eight months or something. 00:08:29.000 --> 00:08:32.000 And I said, yes, he said to me. So I said, of course we can do that. 00:08:32.000 --> 00:08:35.000 And then I said, then I had to call you to make it happen. 00:08:35.000 --> 00:08:38.000 So I flew across and we had a look at it. 00:08:38.000 --> 00:08:40.000 And I said, I'm going to need some help. 00:08:40.000 --> 00:08:44.000 And he said, well, I had a friend from college who's independent too. 00:08:44.000 --> 00:08:46.000 And that's when I met Andy Hunt. 00:08:46.000 --> 00:08:50.000 So Andy and I spent probably in the end about 10 months. 00:08:50.000 --> 00:08:55.000 The office they gave us was a converted closet, no windows, no air conditioning. 00:08:55.000 --> 00:08:58.000 We were working in Atlanta at the time. 00:08:58.000 --> 00:09:01.000 So it was a very close experience. 00:09:01.000 --> 00:09:03.000 But we did it. We got the switch working. 00:09:03.000 --> 00:09:05.000 And we kind of enjoyed working together. 00:09:05.000 --> 00:09:07.000 And so we kept doing it. 00:09:07.000 --> 00:09:11.000 And for the next five, six years, we did that. 00:09:11.000 --> 00:09:16.000 One of the things we noticed that all of our clients tended to make the same mistakes. 00:09:16.000 --> 00:09:19.000 So they were not testing this offer before they shipped it. 00:09:19.000 --> 00:09:21.000 They weren't doing version control. 00:09:21.000 --> 00:09:23.000 They didn't have any automation. All of these kind of things. 00:09:23.000 --> 00:09:25.000 So we started jotting down some notes. 00:09:25.000 --> 00:09:34.000 And the idea was that when we went to a new client, we were to give them these notes as kind of like a baseline and say, if you look at this, that's kind of what we're going to be talking about. 00:09:34.000 --> 00:09:39.000 And as things tend to do, it started out as being, it'll be like five pages. 00:09:39.000 --> 00:09:41.000 And then we got to 50 pages. 00:09:41.000 --> 00:09:45.000 And my wife said, maybe you should turn this into something. 00:09:45.000 --> 00:09:48.000 And we were like, nah, and she was she insisted. 00:09:48.000 --> 00:09:52.000 So we thought we'd never done anything like write a book before. 00:09:52.000 --> 00:09:54.000 And we had no idea what it meant. 00:09:54.000 --> 00:09:57.000 So we came up with a really clever plan. 00:09:57.000 --> 00:10:01.000 We would take what we had and we would send it to the publisher. 00:10:01.000 --> 00:10:08.000 We thought was the best technical book publisher in software, which at the time was Addison Wesley. 00:10:08.000 --> 00:10:10.000 And we said, okay, we'll send this to them. 00:10:10.000 --> 00:10:16.000 And they will say no. But as a professional company, they will tell us what's wrong with it. 00:10:16.000 --> 00:10:18.000 And then we can fix it. 00:10:18.000 --> 00:10:19.000 And they foiled us. 00:10:19.000 --> 00:10:22.000 You know, they totally ruined our plan because they said yes. 00:10:22.000 --> 00:10:26.000 And so we ended up writing a pragmatic programmer for them. 00:10:26.000 --> 00:10:31.000 At the time, we had already created like some tools to help us write something in book format. 00:10:31.000 --> 00:10:35.000 And so they reluctantly agreed to let us use our own tools. 00:10:35.000 --> 00:10:41.000 And so we do all the typesetting and layout and the indexing of the first edition that one that you showed. 00:10:41.000 --> 00:10:46.000 And from that point on, we kind of got the idea that, hey, writing books is kind of fun. 00:10:46.000 --> 00:10:47.000 And we already had tools to do it. 00:10:47.000 --> 00:10:51.000 And so after a gap of about a year, we did the Ruby book. 00:10:51.000 --> 00:10:53.000 Or I did the Ruby book. 00:10:53.000 --> 00:10:56.000 We brought in Mike Clark to write a book on automation. 00:10:56.000 --> 00:10:58.000 And we suddenly realized we had a company. 00:10:58.000 --> 00:11:03.000 And at the time, the consultancy business was pretty dire. 00:11:03.000 --> 00:11:07.000 It was just after the Y2K thing. 00:11:07.000 --> 00:11:09.000 And people didn't have budget. 00:11:09.000 --> 00:11:12.000 And so there wasn't that much work going around. 00:11:12.000 --> 00:11:15.000 So we decided to focus more on the books for a while. 00:11:15.000 --> 00:11:17.000 And that just went from strength to strength. 00:11:17.000 --> 00:11:24.000 For a long time, the only place I would like go to to look for technical books was pragmatic programmers. 00:11:24.000 --> 00:11:29.000 Because I knew that I don't have to like read reviews of this stuff. 00:11:29.000 --> 00:11:31.000 Whatever is on here is golden. 00:11:31.000 --> 00:11:33.000 Oh, that's kind of you. 00:11:33.000 --> 00:11:34.000 It was fun. 00:11:34.000 --> 00:11:35.000 It really was fun. 00:11:35.000 --> 00:11:41.000 And I was lucky because I had a fair amount of contacts from doing conferences and this kind of stuff. 00:11:41.000 --> 00:11:45.000 You know, if I saw someone speak at a conference and I thought, oh, that's interesting. 00:11:45.000 --> 00:11:48.000 I would typically go and say, hey, do you want to write a book? 00:11:48.000 --> 00:11:52.000 And a number of them were silly enough to say yes. 00:11:52.000 --> 00:11:57.000 And so we actually got some really good authors and some really good titles out of that. 00:11:57.000 --> 00:12:03.000 I was in one of your, I think it was the Ruby Conf in Australia. 00:12:03.000 --> 00:12:07.000 Maybe 2013 or 2014. I was in one of your elixir. 00:12:07.000 --> 00:12:11.000 I think at that time you were teaching elixir and you were writing the elixir book. 00:12:11.000 --> 00:12:14.000 So I was in one of those classes, yeah. 00:12:14.000 --> 00:12:17.000 Oh, okay. Cool. Cool. That was always good fun. 00:12:17.000 --> 00:12:24.000 So this book, 24 years later, we look back at this book as one of the seminal works in the software industry, right? 00:12:24.000 --> 00:12:31.000 Because a lot of the things that you talked about, like you said, believe it or not, people were not writing tests. 00:12:31.000 --> 00:12:36.000 There was no definition of what a unit test is versus what an integration test is. 00:12:36.000 --> 00:12:38.000 What should different things look at? 00:12:38.000 --> 00:12:43.000 Automation, observability, and those things have become like standards now. 00:12:43.000 --> 00:12:47.000 You don't have to influence anybody to go do these things anymore. 00:12:47.000 --> 00:12:48.000 You're still consulting. 00:12:48.000 --> 00:12:56.000 What are the new things that you're seeing that, okay, I need to again repeatedly go back to my clients and tell them to do this or do that. 00:12:56.000 --> 00:12:59.000 What are those new things that you're seeing now? 00:12:59.000 --> 00:13:05.000 So I got to tell you first of all, just in fairness, that I'm not actually being paid to consult. 00:13:05.000 --> 00:13:10.000 I'm kind of busy right now with the bookshelf, but I am talking to a lot of people, many, many people. 00:13:10.000 --> 00:13:13.000 And little bit of history, if you don't mind. 00:13:13.000 --> 00:13:19.000 Back in 2000, software was in a really, really, really bad state. 00:13:19.000 --> 00:13:22.000 The vast majority of projects never completed. 00:13:22.000 --> 00:13:27.000 Even fewer projects completed successfully and actually delivered what they said they would. 00:13:27.000 --> 00:13:32.000 And when I say the vast majority, I mean, it's like more than I think 60-something percent failed. 00:13:32.000 --> 00:13:38.000 This was using 1990s technology, which was nowhere near as complicated as it launched today. 00:13:38.000 --> 00:13:45.000 So people were responding to that by creating systems frameworks in which you could develop software. 00:13:45.000 --> 00:13:50.000 I don't mean like software frameworks, but like structural project frameworks. 00:13:50.000 --> 00:13:55.000 And everybody in their dog had its own framework that you were supposed to use. 00:13:55.000 --> 00:13:57.000 And none of them worked. 00:13:57.000 --> 00:14:02.000 And the reason that none of them worked is that they made a very, very faulty assumption. 00:14:02.000 --> 00:14:05.000 And that is that people know what they want. 00:14:05.000 --> 00:14:08.000 And people don't know what they want. 00:14:08.000 --> 00:14:09.000 Nobody knows what they want. 00:14:09.000 --> 00:14:11.000 They may think they know what they want. 00:14:11.000 --> 00:14:16.000 But you give it to them and they'll go, oh yeah, but that wasn't quite what I meant. 00:14:16.000 --> 00:14:23.000 And when you're talking about software that takes a year to write, that's a big investment to discover that you actually didn't quite want what you said. 00:14:23.000 --> 00:14:31.000 So the motivation behind the manifesto of fragile software development was to try to find a way to break that logger. 00:14:31.000 --> 00:14:40.000 The realization is that the only way to make any progress when you are not sure of what you're doing is to use feedback. 00:14:40.000 --> 00:14:42.000 That's the only way you can do it. 00:14:42.000 --> 00:14:43.000 Literally, it doesn't matter. 00:14:43.000 --> 00:14:52.000 I don't care if you are walking across a desert or whether you are flying an airplane or whether you are writing a brand new podcast application. 00:14:52.000 --> 00:14:58.000 The only way to do it is to collect feedback and to collect feedback at every single level. 00:14:58.000 --> 00:15:04.000 All the way down from the lines of code, all the way up to the how are we doing as a business? 00:15:04.000 --> 00:15:06.000 I can very small increments. 00:15:06.000 --> 00:15:08.000 That's really flies into that right. 00:15:08.000 --> 00:15:15.000 So if you're going to collect feedback, the longer you leave it to collect the feedback, the more the error potentially. 00:15:15.000 --> 00:15:19.000 And the bigger the correction and a correction is a cost. 00:15:19.000 --> 00:15:24.000 So the more you can get feedback rapidly, it's a better. 00:15:24.000 --> 00:15:27.000 Now, this obvious time scales for different kinds of feedback. 00:15:27.000 --> 00:15:38.000 So feedback to do with, say, lines of code, you can get pretty much instantaneously, if you want right-align a code or two, and then try running it against the test. 00:15:38.000 --> 00:15:40.000 And you can get feedback pretty quickly. 00:15:40.000 --> 00:15:45.000 Some feedback, like going to the client and saying, is this what you meant? 00:15:45.000 --> 00:15:46.000 Well, that might take a day or two. 00:15:46.000 --> 00:15:48.000 So that's kind of like on a different level. 00:15:48.000 --> 00:15:52.000 Some feedback on things like, how did we do as a project team? 00:15:52.000 --> 00:15:54.000 What would we do differently? 00:15:54.000 --> 00:15:55.000 What did what went well? 00:15:55.000 --> 00:15:58.000 Well, obviously that relies on the length of a project. 00:15:58.000 --> 00:16:01.000 So there's different scales of feedback. 00:16:01.000 --> 00:16:07.000 But the rule is, never start something until you know what feedback you're going to collect. 00:16:07.000 --> 00:16:11.000 Always try to minimize the time it takes to get that feedback. 00:16:11.000 --> 00:16:16.000 So basically, the feedback loop should be part of the structure of the project. 00:16:16.000 --> 00:16:19.000 Feedback loop is the structure of the project. 00:16:19.000 --> 00:16:28.000 In the ideal world, the entire project is structured purely as a feedback machine that just happens to deliver software at the end of it. 00:16:28.000 --> 00:16:29.000 But here's the thing. 00:16:29.000 --> 00:16:34.000 In a successfully orchestrated team, it doesn't even have to develop a software. 00:16:34.000 --> 00:16:41.000 A client can come to you and say, I have this need, and the team can say, oh, you know what, we can follow that. 00:16:41.000 --> 00:16:44.000 Without any software, we could just like say, what do you do this, this, and this? 00:16:44.000 --> 00:16:46.000 And the client go, oh yeah, that works. 00:16:46.000 --> 00:16:47.000 And they're successful. 00:16:47.000 --> 00:16:49.000 That's a successful project. 00:16:49.000 --> 00:16:53.000 So the feedback is what drives what you do. 00:16:53.000 --> 00:17:00.000 And one of the things that I am discovering back in 2000, the idea was you could write your requirements document. 00:17:00.000 --> 00:17:02.000 And that requirements document was then sacred. 00:17:02.000 --> 00:17:04.000 No one could change it. 00:17:04.000 --> 00:17:07.000 And that's what the team would develop to deliver against. 00:17:07.000 --> 00:17:10.000 And that's what the the manifesto said was not true. 00:17:10.000 --> 00:17:13.000 The manifesto said, people don't know what they want. 00:17:13.000 --> 00:17:17.000 So we have to develop incrementally, show them and get feedback from them and fix it. 00:17:17.000 --> 00:17:23.000 But now 20 years later, we are falling back into the same problem. 00:17:23.000 --> 00:17:31.000 We're talking about having, you know, liais on people, different people call them different things, product managers or whatever else, right? 00:17:31.000 --> 00:17:36.000 And these people are now the repository of what the client wants. 00:17:36.000 --> 00:17:42.000 And they will come down with documents that say, this is what's needed in this iteration. 00:17:42.000 --> 00:17:45.000 Or this is what the client wants in this iteration. 00:17:45.000 --> 00:17:52.000 And so we form back exactly into the same trap of thinking we understand the requirements we don't. 00:17:52.000 --> 00:17:59.000 In some ways, I think maybe without those people or those defined roles, but this has always been a problem. 00:17:59.000 --> 00:18:06.000 That the fact is that you can define the problem before starting to do anything about it. 00:18:06.000 --> 00:18:07.000 That's the falsehood. 00:18:07.000 --> 00:18:08.000 Absolutely. 00:18:08.000 --> 00:18:11.000 Well, it's based on two things, I think. 00:18:11.000 --> 00:18:23.000 First of all, in many facets of quote engineering, that is true to some degree in that I can go and I can find the properties materials and I can measure the distance. 00:18:23.000 --> 00:18:28.000 And based on that, I can slap together a standard design bridge. 00:18:28.000 --> 00:18:31.000 And I'm pretty sure that it won't fall down. 00:18:31.000 --> 00:18:38.000 The problems in classical engineering come when somebody says, yes, but can you do it cheaper? 00:18:38.000 --> 00:18:41.000 But that's it, the whole point actually of engineering. 00:18:41.000 --> 00:18:43.000 Anybody can build a bridge right? 00:18:43.000 --> 00:18:48.000 If I wanted to build a bridge across a river, I just dump dirt into it until you can drive across. 00:18:48.000 --> 00:18:50.000 Anyone can do that. 00:18:50.000 --> 00:18:58.000 But an engineer can do it cheaply and allow the water to flow and boats to go into the ether and the like and stuff. 00:18:58.000 --> 00:19:02.000 And so engineers can do it according to a template very, very simply. 00:19:02.000 --> 00:19:07.000 The assumption is that we can do the same thing in software because we call it software engineering. 00:19:07.000 --> 00:19:09.000 And we can't. 00:19:09.000 --> 00:19:14.000 There are no tables that you can look up to tell you anything to do a software engineering. 00:19:14.000 --> 00:19:16.000 Every project is different. 00:19:16.000 --> 00:19:17.000 Every environment is different. 00:19:17.000 --> 00:19:18.000 Every tool set is different. 00:19:18.000 --> 00:19:21.000 Every developer, bless them are different. 00:19:21.000 --> 00:19:25.000 And so we are not doing engineering, but the assumption was we were. 00:19:25.000 --> 00:19:27.000 So that's one problem. 00:19:27.000 --> 00:19:35.000 It's a problem, but it's also one of the beauties of software development because I am a civil engineer by education. 00:19:35.000 --> 00:19:44.000 And after a while, I figured out that I really enjoy the creative side of software development. 00:19:44.000 --> 00:19:45.000 Yeah, absolutely. 00:19:45.000 --> 00:19:47.000 But it comes at a price obviously. 00:19:47.000 --> 00:19:54.000 Because as software engineers, we have a very hard interface on one side, which is the computer. 00:19:54.000 --> 00:19:56.000 And by heart, I mean, unchanging. 00:19:56.000 --> 00:20:00.000 So, you know, we have to write something that eventually will run on this machine. 00:20:00.000 --> 00:20:04.000 And we have this very ill-defined thing that people want us to do. 00:20:04.000 --> 00:20:10.000 And our job is to sit in the middle and basically make intelligent guesses to make that happen. 00:20:10.000 --> 00:20:13.000 It's like juggling with jello or something. 00:20:13.000 --> 00:20:14.000 It's a mess. 00:20:14.000 --> 00:20:19.000 And the fact we can do it at all given our limited understanding is seriously impressive. 00:20:19.000 --> 00:20:33.000 But by doing some of the stuff in the Agile Manifesto, we can reduce some of the risk because if we reduce the time to get feedback, then we can more rapidly work out if we're doing it correctly or not. 00:20:33.000 --> 00:20:38.000 If we encourage proper prototyping and proper experimentation. 00:20:38.000 --> 00:20:42.000 And if we allow people to say, I made a mistake without punishing them. 00:20:42.000 --> 00:20:47.000 If we do all of those things, then we're in a better position to deal with this uncertain world. 00:20:47.000 --> 00:20:54.000 But many large companies do not have the flexibility to be, quote, agile all the way up. 00:20:54.000 --> 00:21:04.000 So at some level, and typically it's the middle management, if you talk to really senior management, they'd love the idea of agility. 00:21:04.000 --> 00:21:08.000 They'd love being able to say that you'll get stuff out there as fast as possible. 00:21:08.000 --> 00:21:11.000 They don't like the idea of two-year plans. 00:21:11.000 --> 00:21:15.000 But middle management lives and dies by their annual budget and their annual forecast. 00:21:15.000 --> 00:21:16.000 And what kind of stuff? 00:21:16.000 --> 00:21:22.000 And so middle management wants to impose that kind of engineering structure on their software team. 00:21:22.000 --> 00:21:34.000 Because of that, and because of that kind of impedance mismatch between the management and the best way of running the teams, a whole bunch of companies have said, hey, we have the solution. 00:21:34.000 --> 00:21:40.000 And we have techniques that will work that allow you to run agile in your company. 00:21:40.000 --> 00:21:44.000 And because it's a big company, guess what? They've got a lot of money. 00:21:44.000 --> 00:21:50.000 And so they'll give you $5, $10 million for the magic secret source that will turn your company agile. 00:21:50.000 --> 00:21:51.000 But does it work? 00:21:51.000 --> 00:21:53.000 No, of course not. 00:21:53.000 --> 00:22:02.000 And it can't work because by the definition of agility, what works for one person will not work for another person. 00:22:02.000 --> 00:22:14.000 If I went and I found the Olympic figure skater, and I recalled it every single movement that figure skater made, and wrote it into a book, and then gave it to somebody else and said, here, do this and you'll be an Olympic figure skater. 00:22:14.000 --> 00:22:15.000 Would it work? 00:22:15.000 --> 00:22:16.000 Obviously not. 00:22:16.000 --> 00:22:20.000 That's exactly what people are doing with all of these men. 00:22:20.000 --> 00:22:25.000 That's exactly what people are doing with all of these methodologies that are supposed to be agile. 00:22:25.000 --> 00:22:28.000 And unfortunately, people are believing it. 00:22:28.000 --> 00:22:36.000 And so nowadays, I got really depressed when I looked around and I saw they call it agile now. 00:22:36.000 --> 00:22:39.000 And I got to admit every now and then I fall into it. 00:22:39.000 --> 00:22:41.000 agile is not a noun. 00:22:41.000 --> 00:22:43.000 It's not a thing you do. 00:22:43.000 --> 00:22:45.000 It's a way that you do something. 00:22:45.000 --> 00:22:46.000 It's agility. 00:22:46.000 --> 00:22:50.000 And so you do things in an agile way, but these people aren't selling that. 00:22:50.000 --> 00:22:55.000 These people are selling, do this and you are agile, which is totally bogus. 00:22:55.000 --> 00:22:57.000 Yeah, there's something in methodology. 00:22:57.000 --> 00:22:58.000 Yeah, yeah. 00:22:58.000 --> 00:23:00.000 And there's lots of different levels of it too. 00:23:00.000 --> 00:23:05.000 It's a really difficult problem because everybody wants to be told what to do. 00:23:05.000 --> 00:23:12.000 When it's scary, when it's unknown, people are looking around for that figure that says, don't worry, I've got it covered. 00:23:12.000 --> 00:23:13.000 Do it this way. 00:23:13.000 --> 00:23:14.000 It'll be fine. 00:23:14.000 --> 00:23:20.000 But as human beings, we seek to create templates for things because they're predictable. 00:23:20.000 --> 00:23:22.000 And it's the predictability that we like. 00:23:22.000 --> 00:23:25.000 Liquid and illusion of predictability, rather. 00:23:25.000 --> 00:23:26.000 We are. 00:23:26.000 --> 00:23:31.000 But I mean, also it's the illusion that it's somebody else's responsibility now. 00:23:31.000 --> 00:23:33.000 It's kind of like the Nuremberg defense. 00:23:33.000 --> 00:23:38.000 I was just following orders and people look at that in a corporate setting. 00:23:38.000 --> 00:23:44.000 And a lot of these companies were people impose these frameworks on top of them. 00:23:44.000 --> 00:23:48.000 The project teams kind of like go, well, this isn't going to work. 00:23:48.000 --> 00:23:51.000 But that's okay because now it's not awful. 00:23:51.000 --> 00:23:54.000 In the past, people used to blame us. 00:23:54.000 --> 00:23:56.000 We've delivered what you asked for. 00:23:56.000 --> 00:23:59.000 The fact that it doesn't work is not our problem. 00:23:59.000 --> 00:24:03.000 Yeah. Yeah. I don't care if the whole Sony has three legs. 00:24:03.000 --> 00:24:04.000 That's what you asked for. 00:24:04.000 --> 00:24:06.000 So anyway, that got me really, really oppressed. 00:24:06.000 --> 00:24:14.000 And so I started going around recently, actually, to try and take the temperature of what people were actually doing. 00:24:14.000 --> 00:24:22.000 So I put out a call and I've had maybe a hundred people sign up to chat with me over Zoom. 00:24:22.000 --> 00:24:25.000 And I'm about halfway through that right now. 00:24:25.000 --> 00:24:28.000 And it has been absolutely fascinating. 00:24:28.000 --> 00:24:35.000 I would say maybe one in three of the calls were from people who were in a bad situation. 00:24:35.000 --> 00:24:38.000 Where they were suffering from some of the kind of things we've talked about. 00:24:38.000 --> 00:24:43.000 Or the classic bad manager or evil manager or whatever it might be. 00:24:43.000 --> 00:24:48.000 But the majority of people were doing what developers have always done. 00:24:48.000 --> 00:24:51.000 And that is they found ways to beat the system. 00:24:51.000 --> 00:24:54.000 And they found ways to get their job done. 00:24:54.000 --> 00:24:59.000 Even within the confines of some of these really bad practices. 00:24:59.000 --> 00:25:03.000 And what they're doing is really interesting. 00:25:03.000 --> 00:25:08.000 I'm still kind of at the early stages of picking it all apart. 00:25:08.000 --> 00:25:16.000 But there's a couple of threads that are coming out consistently that successful and happy teams are all doing. 00:25:16.000 --> 00:25:18.000 Do you want to know what they are? 00:25:18.000 --> 00:25:26.000 Yes. So one of the things they're doing is once a team gets to a certain size. 00:25:26.000 --> 00:25:30.000 And that's probably about six to eight people. 00:25:30.000 --> 00:25:35.000 Or once a team starts to have some teams or once a project starts to have some teams. 00:25:35.000 --> 00:25:51.000 One of the practices of successful teams is that they have at least one person, senior person, whose job is not to be on a team, but whose job is to basically float between all the teams. 00:25:51.000 --> 00:25:58.000 And just be chatty, be social to find out what people are doing, what problems they're having. 00:25:58.000 --> 00:26:06.000 Where people are duplicating effort between teams, where people are misunderstanding what other people are doing, all that kind of stuff. 00:26:06.000 --> 00:26:13.000 And this person's job is basically to act as a lubricant between all the different things that are going on. 00:26:13.000 --> 00:26:17.000 And to make sure that things are not rubbing up against each other the wrong way. 00:26:17.000 --> 00:26:24.000 They are looking at people who may be struggling and saying, what can we do to help these people? 00:26:24.000 --> 00:26:39.000 One of the guys I spoke to was kind of interesting. He instituted a cross team pairing program where for like a conference like one afternoon, or something, you had to pair with someone on a different team. 00:26:39.000 --> 00:26:45.000 He then tried to arrange things that say you had a developer that was struggling with racial databases. 00:26:45.000 --> 00:26:55.000 He would find somebody on another team that was absolutely nailing it and say, okay, I'd like you to go pair with Fred over there for an afternoon. 00:26:55.000 --> 00:26:59.000 And see if you can work out where his problems are and help him. 00:26:59.000 --> 00:27:07.000 And doing that, you got to know what other people were doing. And you actually helped what other people were up to. 00:27:07.000 --> 00:27:12.000 And Fred then knew that you can go and talk to Sylvia or whatever her name was. 00:27:12.000 --> 00:27:18.000 And ask questions in the future. So that kind of role. I think that is often misunderstood. 00:27:18.000 --> 00:27:22.000 People sometimes call that the project lead or the project manager. 00:27:22.000 --> 00:27:27.000 But those roles are telling people what to do in a way. 00:27:27.000 --> 00:27:32.000 And the role I'm talking about is asking people what needs to be done. 00:27:32.000 --> 00:27:35.000 I think that's in a way similar to the principle engineer role at Amazon. 00:27:35.000 --> 00:27:41.000 I think the thing with the principle engineer role at these big companies is that it's so many things. 00:27:41.000 --> 00:27:45.000 But this is definitely one of those things is you are talking to people. 00:27:45.000 --> 00:27:52.000 Maybe sometimes they're struggling or they're not at an individual level to different engineers and trying to figure out what's working. 00:27:52.000 --> 00:28:01.000 What's not and you're creating those bridges between teams or essentially you are the bridge between different teams. 00:28:01.000 --> 00:28:05.000 I think Apple has a role that's similar as well. 00:28:05.000 --> 00:28:12.000 I may misunderstand this, but I believe there's an Apple role called staff engineer that does the same kind of thing. 00:28:12.000 --> 00:28:16.000 And it's significant to me that companies that are successful have those roles. 00:28:16.000 --> 00:28:18.000 That's an important one, I think. 00:28:18.000 --> 00:28:29.000 The other thing that seemed to be important is giving the developers access not to what customers want, but to what customers need. 00:28:29.000 --> 00:28:36.000 It's kind of the difference between what you say and what you mean and different companies had different ways of doing it. 00:28:36.000 --> 00:28:44.000 One company had this thing where when you kick a project off, you always bring either the team to the customer or the customers of the team. 00:28:44.000 --> 00:28:56.000 Ideally you take the team to the customer and you actually don't just sit in the meeting room with their manager, but you actually go and talk to the people that this work is for because quite often the manager will have one idea. 00:28:56.000 --> 00:29:02.000 But the people I should do in the work will have a very different idea and you talk to them and you basically say, hey, good news. 00:29:02.000 --> 00:29:04.000 We've got like infinite amount of money to write stuff for you. 00:29:04.000 --> 00:29:06.000 What would you like? What would you need? 00:29:06.000 --> 00:29:12.000 And obviously you're guided by what the project is about, but you're not bound by that. 00:29:12.000 --> 00:29:24.000 I mean, I had an example of that once on a project where I went, one of my kind of prime sources from information was one of the people who was working on the help desk for these particular kind of transactions. 00:29:24.000 --> 00:29:28.000 Because every now and then I'd have to go ask, what does this mean and what does that mean? 00:29:28.000 --> 00:29:39.000 And one time I watched and she was sitting there and she had a pad of paper on the side and she'd be talking to a customer and she'd bring a screen up and she would write a 14 digit number down on her pad of paper. 00:29:39.000 --> 00:29:42.000 Then go to another screen and type this number in. 00:29:42.000 --> 00:29:51.000 One of the core ended I said, what are you doing? Why are you writing down this 14? Oh, because it's actually the same system, but these two screens don't talk to each other. 00:29:51.000 --> 00:29:58.000 And those are the kind of things that a manager might not notice, pick up on or whatever when they're specifying a system. 00:29:58.000 --> 00:30:05.000 So by having the developers out there and talking about need and not about requirements, I think is really, really important. 00:30:05.000 --> 00:30:11.000 Because the other thing you can do if you understand need is you can deliver against it. 00:30:11.000 --> 00:30:13.000 You can prioritize it. 00:30:13.000 --> 00:30:27.000 And so if you understand what the customers needs are and what the priorities are, you can deliver incomplete projects that actually will help iteratively and also kind of speculatively in that you can deliver it. 00:30:27.000 --> 00:30:32.000 And there have been times where I delivered something in that kind of vein. 00:30:32.000 --> 00:30:36.000 And the customer said, hey, that's good enough. That's what we needed. 00:30:36.000 --> 00:30:39.000 And all the rest were just kind of icing on the cake, but we don't need that. 00:30:39.000 --> 00:30:50.000 I was curious on your thoughts about, you know, once was in a project where the system was perfect, but once I spent the night with people in warehouse, I realized, well, they just don't want the new system. 00:30:50.000 --> 00:30:55.000 Because there's fear, this latent fear that managers don't recognize. 00:30:55.000 --> 00:31:02.000 Actually, in this particular case, the guy was the manager. And basically, the whole project was almost sabotaged by that fear. 00:31:02.000 --> 00:31:09.000 I'm curious if you have thoughts on how you do with that because it's all, I don't know what the right word to express. It's like latent fear. 00:31:09.000 --> 00:31:20.000 Is the fear there because they're being measured against some productivity or something like that and they left to learn a new way of doing this in a new system? What is the root of the fear? 00:31:20.000 --> 00:31:32.000 So the context here is logistics company. It's a customs clearance process. People have been doing the same thing over and over again, tens of times every night to clear customer shipments. 00:31:32.000 --> 00:31:37.000 And then you introduce, with the new system comes a slight change to the process too. 00:31:37.000 --> 00:31:44.000 And I think with people who just repeatedly do the same thing over and over, there is maybe just fear of new. 00:31:44.000 --> 00:31:52.000 But as a spectator could also be fear of job security because if you can do things more efficiently, maybe fewer people are needed to do it. 00:31:52.000 --> 00:32:00.000 The other thing I've personally found in those kind of systems is that as developers, we love looking for patterns. 00:32:00.000 --> 00:32:08.000 And so we look at a system like that and we go, okay, so we can have a look at, I don't know what the details are, but this number and this number. 00:32:08.000 --> 00:32:14.000 And that will tell us what bin it goes into and then this will tell us what form we need and what's kind of stuff, right? 00:32:14.000 --> 00:32:20.000 And we'll then design a system based on this really beautiful structure that we put in place. 00:32:20.000 --> 00:32:33.000 But the real world is never beautiful. And I bet you that the people on the ground handling all of those items, no 1000 special cases that they have to deal with every day. 00:32:33.000 --> 00:32:40.000 And one of their fears is that unless you work that job for five years, you won't know about that. 00:32:40.000 --> 00:32:47.000 And that we'll produce for them a system which basically doesn't work because of those edge cases. 00:32:47.000 --> 00:32:54.000 And fixing manually all of those edge cases is going to be way more work for them than they ever had before. 00:32:54.000 --> 00:33:09.000 And I've seen that happen quite a lot where we think things should be simple, we make things simple and we have this kind of arrogant clearly everything in the world has to be a hierarchy and everything has to follow rules and it doesn't, it just doesn't. 00:33:09.000 --> 00:33:15.000 I always think that the best example of that is the world's most popular software, which is the spreadsheet. 00:33:15.000 --> 00:33:19.000 The magic of the spreadsheet is it doesn't tell you what to do. 00:33:19.000 --> 00:33:29.000 True, that's very true. It's very flexible. You can run cache balances or you can do like like you were talking in the other podcast 2015. 00:33:29.000 --> 00:33:34.000 I think those book publishers they end up dating about books and spreadsheets. 00:33:34.000 --> 00:33:36.000 Yeah, there's limits. 00:33:36.000 --> 00:33:46.000 No, but I mean seriously, I mean what you're doing with that and with so many other devices is that you're enabling people to do things the way they want to do them. 00:33:46.000 --> 00:33:53.000 And I would like to see us as an industry working on ways we can do something like that. 00:33:53.000 --> 00:33:58.000 And I think actually to be fair, we're not doing too bad of a job right now. 00:33:58.000 --> 00:34:06.000 I mean, if you look at the fact that you can now do on your phone stuff that you used to have to have a PC and a screen and everything else. 00:34:06.000 --> 00:34:14.000 But nowadays you expect to be able to cut and paste something from here to there and have its format adjust automatically as you do it. 00:34:14.000 --> 00:34:20.000 So again, you're in control. You're telling it what to do and it's working out how to get it done. 00:34:20.000 --> 00:34:27.000 That is also something that I'm seeing. Is this move from specifying a requirement to meeting a need? 00:34:27.000 --> 00:34:36.000 Yeah, and AI probably also plays a role here because it well in theory and also I guess that later stages of evolution it can better predict as to what you want. 00:34:36.000 --> 00:34:44.000 And actually sometimes when I type an email in Gmail, I'm impressed how well it predicts simple phrases that I don't have to type anymore. 00:34:44.000 --> 00:34:46.000 I just press a tab and just complete it for me. 00:34:46.000 --> 00:34:53.000 Yeah, as an experiment, I tried to I was doing some layout work and I needed like three or four pages of sample text. 00:34:53.000 --> 00:35:00.000 So I actually went to kind of one of the AI's and I said, write me 2000 words about this. 00:35:00.000 --> 00:35:08.000 And I swear I could have published that and no one would have known. It was just scary, scary, good. 00:35:08.000 --> 00:35:14.000 I mean, there is a lot of content right now that is being published that way. 00:35:14.000 --> 00:35:22.000 I have a question about our startup. I'm almost a bit afraid to ask you this, but I'll do it still. 00:35:22.000 --> 00:35:35.000 So we are at a very early stage of our company. We have some early customers. We are validating our idea. We're seeing starting to see some validation that yes, these needs are there. 00:35:35.000 --> 00:35:42.000 And we're trying to figure out the way that we're trying to satisfy those needs is that a workable thing or not. 00:35:42.000 --> 00:35:59.000 What I'm trying to say is this is very early stage. So if you had told me that I would be writing like a persistent without integration tests and things like that from scratch, I would have laughed at like whoever said that are now is going to do this like five years later. 00:35:59.000 --> 00:36:00.000 But here we go. 00:36:00.000 --> 00:36:19.000 Yeah, we go because I was in a very structured environment in AWS inside Amazon with lots of resources, lots of resources. Yes. How do you decide to balance between like the pragmatic way that we're trying to do this. 00:36:19.000 --> 00:36:42.000 And at the same time be future proof. Oh, you can't be. It's impossible. Okay. There. First of all, the concept of future proof is about as crazy as the idea of perfection. How can you possibly be future proof unless you have some secret magic crystal ball that nobody else on the universe has. 00:36:42.000 --> 00:37:00.000 There is no such thing as future proof. All you can be is easier to change than the next guy. You cannot predict what is going to happen. All you can do is say think of some bad cases, bad scenarios and say, okay, what happens if that happened. 00:37:00.000 --> 00:37:18.000 Now am I going to structure my code so that that change is not going to put my company out of business. I watch people who will spend time putting in place three or four abstraction layers in their code just in case this happens just in case that happens. 00:37:18.000 --> 00:37:38.000 This is code that they're going to throw away. This is their first prototype. This is their get off the ground validate the ideas code. This is code whose entire job is to get out there, let people try things crash every now and then but give you the information you know to make the next one better. 00:37:38.000 --> 00:37:53.000 There is no point in future proofing that code as a startup, I can pretty much guarantee that you will be rewriting that code. The trick will be to make sure that you don't lose anything along the way. 00:37:53.000 --> 00:38:13.000 So you need to make sure that the data formats you're using are not proprietary to a particular technology. You need to make sure that if you had to switch persistence, for example, then you haven't architected yourself totally around a unique feature of one persistence layer that others don't have. 00:38:13.000 --> 00:38:30.000 But apart from that, I don't think you have to think about future proofing at this stage, at this stage, what you're thinking about is how do I get stuff out there? How do I start making money from it? And how do I learn what I have to do when I do it properly? 00:38:30.000 --> 00:38:37.000 If you think about it right now, when you say future proofing, that's exactly the same as saying, I know exactly what I want. 00:38:37.000 --> 00:38:45.000 Or what I'm going to want in a year. Well, what I'm going to want. Yeah, exactly. And I'm sorry to be the bearer of bad news. 00:38:45.000 --> 00:38:56.000 One of the interesting thing here is we've made a commitment to build our system on a no SQL database. But then it also means sometimes I'm like, can you just show this? 00:38:56.000 --> 00:39:07.000 But then it requires joining two tables, which you can't in no SQL, right? Instead, you have to make either multiple requests or you just don't do this feature at all because it's too expensive, right? 00:39:07.000 --> 00:39:19.000 But then if you would go with the latest relational database, we know that maybe we reach like 10,000,000 users and it will start to break. And then we'll have to shard it or we'll have to re-architect everything. 00:39:19.000 --> 00:39:28.000 And the most logical simplest way to build the thing if you were optimizing for speed only would be just use postgres my SQL and validate it. 00:39:28.000 --> 00:39:37.000 But then we would have to rewrite the whole thing. But the problem is relational doesn't translate the right into no SQL. So it's a kind of a decision you have to commit to. 00:39:37.000 --> 00:39:52.000 Or you commit to the rewrite and that rewrite will take the amount of time that it will take because it's going to be a significant rewrite or you choose the current simplest path, which probably is postgres, but I mean whatever. 00:39:52.000 --> 00:40:02.000 I don't care if you use no SQL or SQL database, you choose the path that seems easiest to you right now and that will get you up and running. 00:40:02.000 --> 00:40:10.000 Frankly, if you get to 100,000 users, then you should be happy that you have to make a change because of that. Not sad. 00:40:10.000 --> 00:40:20.000 You get something that's up and running, but you say to yourself, OK, I know that should we become really successful. This is going to be a bottleneck. 00:40:20.000 --> 00:40:32.000 But if your systems are anything like the systems I've worked on, the kind of queries that get you in trouble are a very small subset of the overall. 00:40:32.000 --> 00:40:42.000 Most of the system is straightforward, go and find the user record, go and find the podcast for this user. And those are things that you can do equally well, 00:40:42.000 --> 00:40:57.000 relationally or no SQL when you're doing the complex stuff, quite often it's in limited circumstances like reporting or you're setting up new accounts or something like that, you know, where you actually have to do the complex joins. 00:40:57.000 --> 00:41:09.000 So maybe that would say, OK, as I'm developing the code, I'm going to be cognizant of the fact that this is not going to work as I get bigger either way, whether it's on the no SQL SQL. 00:41:09.000 --> 00:41:23.000 And so I'm going to make sure that I keep this isolated or at least in its own little source tree or something and then come the place where suddenly you appear at the top of hack and news and you got a million subscribers. 00:41:23.000 --> 00:41:34.000 Then you get a very uncomfortable week when you transition that one piece of code to use some kind of cash, no SQL cash or SQL cat, whatever it might be. 00:41:34.000 --> 00:41:46.000 And then you move on, but I have that problem, I find myself constantly not starting projects because I'm spending all my time thinking about what could go wrong and how I could fix it. 00:41:46.000 --> 00:42:00.000 And I just I have to keep telling myself, stop it, get something working. I understand what you're saying. And I know it looks scary, but I think you can mitigate the risk without actually going over the top at this phase. 00:42:00.000 --> 00:42:09.000 So you're saying it's also it doesn't have to be binary choice. It's never a binary choice. The only people that will give you a binary choice is a sales person. 00:42:09.000 --> 00:42:17.000 Yes, right. There are no binary choices in the world. Any decision worth making is nuanced. 00:42:17.000 --> 00:42:33.000 So this has been super exciting. We are already like almost an hour into it. And I know Ilya, you wanted to go into the book and the identity that's tied to the book and that sort of side. Maybe this is a segue into that. 00:42:33.000 --> 00:42:42.000 Yeah, I actually want to ask a question. So yesterday on LinkedIn, yeah, my depose, I said, we are talking to Dave Thomas tomorrow. These are the things that we want to talk about. 00:42:42.000 --> 00:42:52.000 Does any of you have any questions that we want to ask? So our friend, Goaang, Hi, Goaang. He's a host of software, Mr. Adventure's podcast, which is a great podcast. 00:42:52.000 --> 00:43:03.000 So he asked, is there something in the book that you didn't expect to still be the case after 24 years, but it's still true today. I think you thought about this for a while. It's a very good question. 00:43:03.000 --> 00:43:12.000 The opposite question is easy. You know, other things now that don't apply. The answer is compared to the original. Yes, very much so. 00:43:12.000 --> 00:43:24.000 There's also interesting question where the stuff we had in the book has been misunderstood. I guess we didn't explain it well. And therefore people have tended to misunderstand things. 00:43:24.000 --> 00:43:35.000 The biggest example of that is the don't repeat yourself idea, dry to my absolute amazement, dry has become like a standard term in the industry. 00:43:35.000 --> 00:43:47.000 But people quite often apply it wrongly. They apply it to the idea of effectively copying and pasting something. Don't repeat yourself. Don't copy this code and put it over there. But really it doesn't mean that. 00:43:47.000 --> 00:43:56.000 It means that you should only ever have one implementation, particular concept, because that gives you one place to change when the world changes. 00:43:56.000 --> 00:44:12.000 A repository process or information. Well, now I wouldn't go that formal. I would just, it's something where if you discover or if you're writing code and you find yourself doing the same kinds of things, ask us or an abstraction that would make it easier. 00:44:12.000 --> 00:44:21.000 That was a surprise that we didn't get that right. And so the wording in the dry section in the new book is quite a bit different. 00:44:21.000 --> 00:44:29.000 Like something that you thought would not be future proof, but it ended up being future proof. 00:44:29.000 --> 00:44:38.000 There's a couple of things that people still aren't doing that are disappointed at. Nothing like major, nothing like headline. 00:44:38.000 --> 00:44:49.000 One practice that I believe in really, really strongly is the idea of the engineering daybook where you keep a physical book at your side. 00:44:49.000 --> 00:44:52.000 Yes, I remember reading the chapter. Yes. 00:44:52.000 --> 00:45:04.000 Yeah, it is to my mind. It's my life line. I get so much benefit out of doing that. And we still had to emphasize it. And people are still not doing it. 00:45:04.000 --> 00:45:13.000 In fact, people are doing it less. And people are doing things like, oh, it doesn't matter. I can stick it into notion or obsidian or whatever I'm using. 00:45:13.000 --> 00:45:23.000 And it's not the same. One of the bad things now is so many of the new programmers have never actually been taught how to write cursive. 00:45:23.000 --> 00:45:37.000 So, you know, it's really hard for them to take notes, but honestly getting a decent notebook with high quality paper and a nice pen makes you respect what you're doing so much more. 00:45:37.000 --> 00:45:46.000 It makes you think about it. And the act of writing it down, slowing down gives you this time to reflect on how that interacts with all the other things you've written down. 00:45:46.000 --> 00:45:58.000 And I don't know about you, but when I'm writing my daybook, I'll be writing notes. And then suddenly I'll draw a circle round of it and then a line that points up to like three or four items earlier on, which previously I'd made no connection. 00:45:58.000 --> 00:46:10.000 So I am a really big fan of daybooks. And I'm also really, I got this pen, which is really cool. It's a fountain pen that's retractable, but it's not this pilot made one, which is ridiculously expensive. 00:46:10.000 --> 00:46:20.000 It's like 150 bucks or something. And this one was like 30 bucks. And it uses the same nib. You know, it's the pilot uses. I love it. I keep this with me all the time. 00:46:20.000 --> 00:46:30.000 I'll have to insert a plug here too. So I used to have a pilot pen. I just still have it. I don't like it. But I have this carbon fiber pen. The fountain pen too. 00:46:30.000 --> 00:46:40.000 I mean, it's retractable. It's a regular pen. It's 15 bucks on Amazon. But because it's carbon fiber, it's very light, but also like it doesn't get cold, unlike metal pens. 00:46:40.000 --> 00:46:48.000 It feels like metal. I guess it doesn't feel like plastic. I tried the metal pen to but metal pen gets too cold in the room. 00:46:48.000 --> 00:46:57.000 Yeah. Yeah. This is just plastic, but it's fine. You know. Okay. So while we're geeking out on pens. Oh, I don't have it with me. 00:46:57.000 --> 00:47:07.000 There is a travel looking pen by a German company called Koweko. I think I saw us pronounced, which is about half the size of this pen is about that big. 00:47:07.000 --> 00:47:16.000 You unscrew it and then move the other end here. And it makes a full size pen. Absolutely fantastic. Nice. So I keep that in my pocket. 00:47:16.000 --> 00:47:32.000 Coming back to this, something from 24 years ago, I kind of see that a lot of the things that we talked about have become day to day practices. Like nobody would question you if you want to say, like I want to set up a integration testing mechanism in here. 00:47:32.000 --> 00:47:39.000 Everybody understands the value of it. The one thing I think we already talked about this, but I do want to reiterate. 00:47:39.000 --> 00:47:58.000 I think we still haven't fully embraced the agility of doing things because to this day, we are still going backwards from when do we need to deliver this project on and try to try to shoehorn in the process after that. 00:47:58.000 --> 00:48:16.000 And I don't have a good way like we struggle with it, Ilia at lots of places that you and I have worked at together separately, but this is a problem. And I don't have a good way of how to solve this because there is a definite need of projecting out when are you going to be able to release this thing. 00:48:16.000 --> 00:48:31.000 I agree 100% I think that that is one of the big unsolved areas of agility that it is very, very hard at the interface between the agile world and the non agile world. 00:48:31.000 --> 00:48:38.000 And I don't know anybody that's actually come up with a universal solution for that, which I did, but you're absolutely right. 00:48:38.000 --> 00:48:50.000 Okay, so let's differentiate, I guess the pragmatic stuff and the agile stuff, the agile manifesto never was intended to be a set of practices that you had to follow. 00:48:50.000 --> 00:49:11.000 All it really is is a set of values and you use those values to make decisions. Should I do this or should I do that exactly the same as every other value in your life you are raised and you learn and you develop your own values to help you make decisions. 00:49:11.000 --> 00:49:32.000 And that's all the manifesto is. So it's not a failing of the manifesto that that's happened. Well, no, that's not true. It probably is a failing, but it's a failing because it had high expectations that people could value these things, quote universally and people don't. 00:49:32.000 --> 00:49:53.000 They'll accept that as being a failing. I don't know what you do about it though, but there is the other side to that too. So for example, testing right in the first pragmatic program we went overboard with testing because people were not testing so many projects being written with zero tests. 00:49:53.000 --> 00:50:07.000 What tests there were tended to be if it outputs this string, then it's correct. So we went over the top with testing and I think combining that with the XP practices of testing and all the rest. 00:50:07.000 --> 00:50:26.000 People got religion and you know, around about the mid 2000s, it got to the point where people were shaming other people if they didn't have enough tests. I never write code unless there's a test blah, blah, blah. Well, that just makes you an idiot. 00:50:26.000 --> 00:50:45.000 Testing is a tool like every other tool and you use it when you need to use it. And if you think agile means I have to write tests, then you are by definition not being agile because the agile view would be let's see what happens if we don't write tests. 00:50:45.000 --> 00:51:00.000 You know, it kind of reminds me of when I and I and a few other folks we started a team at Amazon and basically we were free to set up our own processes as we wished. So we were like, let's do scrum the right way. 00:51:00.000 --> 00:51:15.000 And then we started with doing those points as you know points they shouldn't equal you know man hours or whatever mandates and they should be like abstract points and after a few weeks we were like, why are we doing this? It just doesn't make any sense. 00:51:15.000 --> 00:51:22.000 We figured out that we're spending more time in figuring out the points than the value that the points were giving us. 00:51:22.000 --> 00:51:43.000 It was pointless. Very good. Yeah, but that kind of ceremony. That's the kind of thing that I object to so much. I mean, there's nothing fundamentally wrong with scrum except people do it as opposed to using it as the basis for developing your own practices. 00:51:43.000 --> 00:52:04.000 I don't care if you go out and you kill a cat and do care about that, but in principle, I don't care if you go and kill a cat and read its entrails and use that to tell you how to write plough for as long as every day, every month, every year, you're looking at your processes and improving them based on your experience. 00:52:04.000 --> 00:52:31.000 Because if you do that, it doesn't matter where you start, you will eventually get to a better place. I think the thing is that we start to create these templates, then we start to quantify the output of these templates with metrics and then these metrics become the thing that we're driving towards rather than the actual improvement of the process that we were seeking. 00:52:31.000 --> 00:52:50.000 I mean, you're familiar with Taylorism. Yes, Frederick Taylor. Yeah. I'm not. Oh, Frederick Taylor was the original time and motion man. He went around companies and he measured with a stopwatch what people were doing and how they were being more effective or not effective. It's like 150 years ago. 00:52:50.000 --> 00:53:13.000 Yeah. And he then used that to produce metrics standards against which people had to work. And it basically heralded in the kind of more assembly line based way of looking at working where people were became units of production and resources and not people. 00:53:13.000 --> 00:53:29.000 Obviously, it worked, but it had limits. And that's when eventually the Japanese worked out as is a better way doing this. And we started to see Toyota come up with their techniques for managing production lines and stuff that worked better. 00:53:29.000 --> 00:53:40.000 But yeah, you're absolutely right. Because what happens is if I can't put it in a spreadsheet, it doesn't exist if I'm a middle manager. So give me your metrics. Maybe that's a product. Forget about the podcasting. 00:53:40.000 --> 00:53:50.000 What are products that just generates random number metrics that teams can give their managers and make up name make up names for the metrics. So no one actually knows what they are. 00:53:50.000 --> 00:53:55.000 If you were part of the company, we might as well have done it, but we have to feed our families. 00:53:55.000 --> 00:54:03.000 Oh, all right. No, we're running short on time and we just want to ask one final question. 00:54:03.000 --> 00:54:12.000 So they view are very well known for the book. I mean, you've done other things too, but this is the thing that is like the main thing that you are known for. 00:54:12.000 --> 00:54:23.000 It's been like quarter century. This was written. So how did that define your identity or do it? How much of it is a part of your identity? 00:54:23.000 --> 00:54:39.000 Oh, that's a dangerous question. So I don't think it defined my identity internally in that to a large extent, it was simply recounting what I was doing anyway. 00:54:39.000 --> 00:54:53.000 So in that way, it didn't change what I did. It, however, it gave me the ability to interact in circles that I previously didn't have any access to. 00:54:53.000 --> 00:55:02.000 So I got invited to speak to conferences and other speakers would talk to me and, you know, we could have conversations and everything else. 00:55:02.000 --> 00:55:12.000 So in that way, it dramatically broadened my access to cool new things and to people's opinions and to people's ideas. 00:55:12.000 --> 00:55:21.000 At the same time, we, we called our business, the pragmatic programmers, after the book. And we called it the pragmatic bookshelf. 00:55:21.000 --> 00:55:30.000 And my pretty much universal handle is priceless. So I guess you could say in that way, it is very much part of our identity. 00:55:30.000 --> 00:55:52.000 I don't know how significant that is. It certainly doesn't hurt. I know that some people have done stuff like, well, say the manifesto and have then effectively pivoted what they did to be based on that and built in some cases, ridiculously successful companies based on the manifesto stuff. 00:55:52.000 --> 00:56:01.000 And that was not of interest to me. It probably should have been because I probably worth considerably more than I am now. 00:56:01.000 --> 00:56:08.000 But that wasn't what I wanted to do because it didn't seem to be that exciting, just like taking what we already had and rehashing it. 00:56:08.000 --> 00:56:19.000 So in that way, I would say it probably has affected my density less than it has other people. I'm sure it has, but it's not a motivator in that way, not a driver. 00:56:19.000 --> 00:56:28.000 Yeah, I think one of the things like this can affect identity, right? Other things that you decided not to do because you are the pragmatic Dave. 00:56:28.000 --> 00:56:46.000 Oh, okay. Yeah, there is actually a really interesting little side effect. And that is whenever I'm doing something like writing code that's public back in my mind, I have to make sure I actually do it the way I said, said we should do it. 00:56:46.000 --> 00:56:52.000 So yeah, it does affect me that way. It keeps me honest, let's put it that way. Yeah, makes a lot of sense. 00:56:52.000 --> 00:57:02.000 So Dave, it has been a great pleasure to have you on the podcast. When you said yes, I think it took actually I had to work through your assistant or your marketing manager. 00:57:02.000 --> 00:57:12.000 It probably took a couple of months before actually we got a response and oh, sorry about that. No, I mean, it's all good. Like we don't get the response from most people at all. So we were super excited. 00:57:12.000 --> 00:57:29.000 This one was I told you, yeah, this is not like never coming back. So yeah, might as well ask you. No, I mean, honestly, I enjoy this kind of thing. I always learn because I always find that I'll come up with something that I haven't quite thought of that way before. 00:57:29.000 --> 00:57:39.000 And people ask questions that just make me think about things and it's enjoyable. And you're nice people and it's nice to talk to nice people. 00:57:39.000 --> 00:57:42.000 It was amazing. Yeah, thanks for coming.