In conversation with Alex: Paul Hammond explains his approach to quality software
In-depth discussion on the principles of quality software development
I’ve had the exquisite pleasure today of spending an hour chatting with Paul Hammond, one of the top software professionals. Paul and I have never met in person, nor have we ever worked together, but I’ve been following Paul’s postings on social media and have become duly impressed with his incisive insights.
I knew I had to eventually get in touch with such a smart leader in our profession, and when I suggested to Paul that we hop on a podcast and when he accepted, I knew it was going to be a remarkably high-quality episode.
So, without further ado, ladies and gentlemen, I give you Paul Hammond!
Quick summary
During this meeting, Paul and I discussed various software development practices, focusing on Extreme Programming (XP), Test-Driven Development (TDD), front-end TDD challenges, feedback-driven development, mutation testing, and the integration of AI tools in testing. We shared personal experiences, debated common industry misconceptions, and explored methods to improve feedback cycles and software quality. We also ended up planning potential future discussions, including a collaborative session involving Uncle Bob (Robert Martin) to debate front-end TDD practices.
Action items for Paul
Prepare and possibly demonstrate front-end Test-Driven Development techniques for the upcoming joint call with Alex and Uncle Bob Martin.
Experiment further with mutation testing, particularly in incremental mode, to increase confidence in code quality and identify gaps.
Document and develop content for the feedbackdriven.dev website, including writing technical blogs and newsletter material to share XP and TDD insights.
Continue refining the use of AI-assisted coding and mutation testing, possibly integrating stricter incremental mutation test runs during review processes.
Be available for future meetings with Alex and assist in organizing the debate session with Uncle Bob Martin.
Action items for Alex
Coordinate and schedule a follow-up meeting with Paul to continue the discussion on software development practices.
Reach out to Uncle Bob Martin to arrange a joint call for debating front-end TDD practices.
Share relevant resources and references about feedback-driven development and mutation testing with Paul.
Consider inviting Paul to appear on the “Coding Interviews with Alex” channel for a technical demonstration on front-end TDD.
Full Transcript
Alex Bunardzic
Hey Paul, this is Alex in Vancouver here in Canada. Mid August. It's a bit cloudy and pleasant, about 19 degrees Celsius. Where are you calling from?
Paul Hammond
I'm in a place called Knutsford which is near Manchester in the UK and so just a few miles away from Manchester but it's been very hot over here recently although it's not so bad today. It's normal kind of gray weather today which is what I'm used to.
Alex Bunardzic
Yeah, I got that about nine years ago or no eight years ago. I almost made it to relocate to Sheffield. I had a job offering and didn't come out because I didn't know what Canadian visa status was needed and all that. And they, the HR over there, didn't want to step in and I just kind of bailed, but it would have been interesting if it happened, I guess.
Paul Hammond
Yeah.
Alex Bunardzic
It's pretty close to Manchester, right?
Paul Hammond
Yeah, it's not too far away actually. It's probably about an hour in the car, something like that. So not too far. Yeah.
Alex Bunardzic
Okay, so hey I've been on and off trying to run this channel which I call “Software Breakthroughs for the 21st Century”. Because I felt that we are kind of, as you mentioned earlier, I think in one of your posts recently, we've made breakthroughs back, in the 20th century. Thanks to Kent back. Primarily and to this day, it's languishing. It's not going anywhere, other than individuals such as yourself, who are, you know, running with the banner and all that, but it just doesn't seem to gain an attraction and I think we should keep pushing. And these things should make a difference.
Paul Hammond
Yeah, yeah. It is quite surreal actually, it's funny because yeah, you mentioned that I've literally got the book on my desk right now. As it happens, the extreme programming book. And it's it's a funny thing for me because like I've been in the industry now just about 20 years in total and for probably about the last 13 or 14 years. I've been exposed to many of the techniques, if not all the techniques in, in this book, right? But the way that I came to know extreme programming is kind of funny because I wasn't exposed to it as extreme programming, right? So what happened for me was in about 2013. I joined the BBC, I was working at BBC Sports and um, there were certain practices that they were doing at the time. Nobody ever told me, Oh, you know, this comes from XP or anything, but test driven development was one of them, pair programming was another. We we moved towards continuous integration, they weren't doing that properly at the point where I started, but we had a big push towards that and continues delivery as well.
But at the same time, it was all, it was all kind of scrum as well, right? So it was like, we were doing the two weeks sprint. We were doing everything. Was, you know, in JIRA, there was the whole, you know, tracking velocity and all of this kind of stuff and also taking things like story points. What I thought very literally, you know, and one of the very first planning meetings, I was in, there's like, a 10 minute debate on whether they could, you know, fit 32 points instead of 33 or something like that. And I remember thinking, What am I, what am I joining? What is this? You know, but it's a funny thing for me because I was exposed to quite a lot of stuff all in one go. So this kind of so called agile, you know, there's this room stuff as well. And I had people telling me, literally telling me that agile development came from project managers. So remember, being told that at one point as in didn't come from software engineers and I believed it initially because I was kind of new to it, you know.
And the funny thing for me, was that over time, I started to develop a perspective and kind of opinions on which things were working and actually worked and which things had a lot less value if that makes sense. And it was things for me that there was the technical side of things. I always felt was very important, right? Because things like Test Driven Development, if you do it properly, it gives you this high level of confidence to make changes over time, right? And if you've got a high level of confidence and the fear of change is low, then that means that that opens up a whole kind of business opportunities, right? Because you can experiment, you can try things out and the you don't have this fear of, you know, “Oh if we change this thing, you know everything's going to explode and it'll take us forever to fix”, you know that goes away.
And it wasn't until probably four or five years ago that I saw it. People talking about XP again. And I was like, Oh I've heard of this thing, I've heard of it, you know, kind of through the grapevine. But then I bought myself a copy of this sometime ago, actually, just timely, that happened to mention it on LinkedIn today. And I started reading through it and I was like, Oh my God, it's like everything that I think works really well. And that I found for myself works really well, is in this, you know what I mean? And then it's like, you know, I can skip to almost any part of this book, and I just find myself nodding along and it's like and then I'll look at it and I'm like, well, Why is it that, you know, the industry is full of, you know, it's, it's we do two weeks sprints, you know, we track everything in JIRA, we, we define success, by whether we hit a sprint goal, and, you know, I don't really care about that. For me, I want to build the best possible products for customers. I want customers to be really happy with it and ultimately, I want to help businesses to actually make more money because the logical thing for me is that if you're building things that customers actually want and need, you will increase the chances of success in the marketplace, right? And so, and again, but this book is it's got all this in it as well. And it talks about involving the customer and do, you know what I mean? So, so I went on quite a bit of a run you very early on, but it's, I think that the interesting thing for me though, is that as I say it wasn't introduced to me necessarily as XP, I was introduced to all of these practices kind of a lot of them at once and I started developing a perspective and kind of opinions on what works and what doesn't and it just so happens to be that.
For me, the stuff that's we, we would label as XP. That you would recognize as XP. That's all the stuff that I I've seen working and not just once or twice, and I'm a contractor. So now, so I move about for, you know, the fair amount and I see it working in so many places. And, you know, I've seen it in different environments and CI/CD for me is an absolute no-brainer. I, you know, I do TDD everywhere I go, you know, yeah, I could probably carry on talking about it. I feel like I'm just just, it'll just be me talking.
Alex Bunardzic
Yeah, no. That's all Everything you said so far is really bang on nailing it, right? I would just add because I'm a bit longer in tooth than you are. My first paid software job was 35 years ago.
Paul Hammond
Yeah.
Alex Bunardzic
It started in August 1990. And so I've been through some experiences that you've, you know, because it happened back in the 90s and, you know, one thing I would add, I would add to what you're saying. Back then things were simpler in a sense that we did not have cloud computing. We did not have it, it was a different world and the XP made sense back then. Because for example, one of my, one of my first jobs, I was working for the Government Health Bureau cutting paychecks for the hospital, local hospitals, in British Columbia as well as patient admission and discharge etc. So I just think back then we were using Midrange Computers IBM, AS/400, which, which was like a business machine.
So, basically Paul, we just go and cut the tape, I go in I make the change to the, to the system, or to the product, I cut the tape, I hop my car, and I drive to the hospital, I then install it, I then train the personnel on the spot, so you could not avoid working with customers.
Paul Hammond
Yep.
Alex Bunardzic
It was very, very ‘skin in the game’ where I would sit down with a customers
Paul Hammond
Yep.
Alex Bunardzic
with hospital administrators and I would see their frustrations right there and how upset they are, how astonished they are that it works not the way they expected to work. So I think that experience really precipitated the possibility of XP or Kent Beck’s experience saying, look, daily interaction with customers giving them options rather than we'll go away and come back six months later and then shove it down their throat. So it was in my opinion, it was easier back then to formulate XP. Rather than today where you're just broadcasting out in the ether and, you know, it's all in the cloud and you have no idea what people who are experiencing a product or going through it and nobody's getting a chance to drive over there and sit down with them etc. I would just, I'd like to, you know, put in a context that contrast between how we used to deliver software 30 years ago, versus how we're doing it now, and I don't know if that helps frame the conversation,
Paul Hammond
It does. But then I still think like, I still think it's possible for this still ways that we can speak to customers, you know what I mean? And and whether it's speaking to them directly, however, it's, you know, even just recording customer behavior in software, which I don't think is quite the same but like, is at least something for me. And, you know, before I started in that job that I just mentioned, I was in a previous job, a place called Chilingo and I was, I was quite lucky in that I was building internal software. I was building software that was kind of being used by, it's a company that just been bought out by Electronic Arts. They made computer video games, they made the very first, well, produced the first version of angry birds that was their big kind of hit, you know, at the time and in cut the rope. So I was, I was kind of working on software that helped the, the kind of producers and so on, in the background and what was interesting for me at the time, was that because the people my consumers, if you like were sat a desk, it's away from me. So I could just talk to them, you know, to me. And I, I got used to that and when I, when I did move to the BBC, it was a bit of a shock then, you know. Okay. Obviously, it's a massive scale and all of that, but I did think that they'd be more of, that, that side of things happening. And to be fair, during the time that I was there, they did see things improve quite heavily and they, they got to a point where they were doing lots of it was quite cool. Actually, we had the, you know, the, you know, we see in like a detective like Murder Mystery, you see the double-sided mirror, they had that. And they so they had like they'd have like, people come in and they try like a prototype version of, like the app, you know. And something that somebody like a designer will just mock together in kind of something like similar to Figma. I don't think Figma was really much of a thing, but then, but, you know, that kind of thing. And we'd all be sat kind of watching them through the double-sided glass, which I always thought was really quite quite cool, you know. But it was really interesting to see that, and, but then, I worked at a place, a contracted at a place called Equal Experts who I've got a great deal of time for an equal experts. I think that they've got a really kind of, my experiences were really positive and the way that they kind of work they would bring in entire teams into an organization like an equal experts team, but we would interact with other teams on the ground floor and so on. And one of the products that I worked on there, it was a big law firm, and I don't know if I can say that law from now. I'm not sure, but a big law firm anyway.
And they were one of the big top five law firms. And we were building a product that was to help lawyers with their workflow, but I'm not a lawyer, nobody on my team is a lawyer, you know. We had a brilliant UX person but again, doesn't have all this context. And so, one of the things we were based in the office of this law firm.
And one of the things experts did was they they managed to get a lawyer embedded on our team which literally just sat with us, it's Pre-covid. So like we're all set together and that was amazing. And then we also had there was a UX person on our team was only ever a couple of weeks ahead of the engineer is by design. And what he would do is he would, we would build something like a new feature and then he would go to. There was an office in London, and he would sit there with a small team of lawyers, who were using our software that we just, we were building and he would get feedback from them. And then he'd come back to the office and he tells us all the stuff that he'd learned and what was working, what wasn't? And then, we might be in the middle of doing something.
But if he came back and said, Oh no, that feature we released last week. It's, it's confusing for people. Actually, they said, If we move this over here and move this to that page, it's better. And we'd have a quick discussion amongst ourselves and then based on priorities, we could say. Okay. Yeah, we'll do that. We'll just do that. Now and very quickly, you didn't take very long, it was, it was clearly becoming a very useful product that people really starting to enjoy using. I do appreciate what you're saying though, that.
Like not everybody has the benefit of that kind of level of you know, interaction with with customers. but it's, it's something that I do think that should be prioritized more. Let's put it that way. I think that in a lot of circumstances companies would have the opportunity, you know, and where I'm working right now. I'm working in a, it's fintech financial services and I'm working on like, helping on the acquisition side of things. So that we're building like this. This multi-branded application for different credit card brands, and for people to apply for credit cards and loans and that kind of thing. And one of the things that I kind of mentioned the company, for example, has a call center, right for people to call up and make payments and whatever, you know. And I've mentioned, why can't we as engineers, not just engineers, but the whole team. Why why do we have no direct contact with people in the call center? Could we arrange that because they speak to customers every day? Right. And you see what I mean? There are these opportunities, sometimes you just kind of maybe have to look For them.
I think.
Alex Bunardzic
To me, you know, it looks like a lot of organizations feel it's more, efficient or more bang for the buck or get more return on investment if they segregate.
Paul Hammond
Yep.
Alex Bunardzic
And, you know, I consult also and you walk into larger organization and first thing they tell you is “over there, there are people who are paid to think and over there are people who do what these thinking, people tell them to do”. Which again, did as you described it, is, there's a disconnect.
Paul Hammond
Yep. Yep.
Alex Bunardzic
That the resulting delivery is kind of underwhelming or sometimes disappointing, like, Okay, all this effort and all this work and all these geniuses at work and we deliver this and the customer kind of like Yeah, you know. So we have to understand why this almost contains, what's the word, propensity? The spontaneously just drift apart like continents and then we, you know, and it's and that's why, you know, I appreciate your your handle, on your YouTube channel is ‘feedback driven developer or ‘development’. I forgot. Which, yeah, what you describing is — You need feedback.
Paul Hammond
Yeah.
Alex Bunardzic
Sometimes delayed feedback is desirable but often most of the time immediate feedback is better. I think.
Paul Hammond
Yeah, the thing for me, I guess so because because I was thinking about this for some time and I was like I want to at some point. I want to write like a Kind of blog or a technical. You know, from my own perspective. One of the specialties I guess I have is he's not just test driven development but test driven development on the front end and it's very rarely done on the front end in the industry. But I've been doing it for over a decade and it works really well. And yeah, I go to form one place to another and almost nobody knows how to do it or they're all the training, but they're doing it badly and I have to kind of show them. And the amount of times to see these eureka moments where people where it clicks with people and so just a good book to the, the feedback driven thing. It's the reason that I kind of came up with that, was I I was trying to think, Well, if I, if I'm gonna buy a domain name and stuff, because I do have the domain, like, I can tell it's feedback, driven Dot Dev.
The, at the moment is only this literally one page on there and and just a form for a newsletter. But I'm, I need to, I want to sit down and focus and write some of this stuff down, you know, but my thinking behind it was I was looking at, you know, should I have TDD in the, in the, in the name of the domain and I was like, that feels kind of alright, but like, it's not quite, there's more to it, you know? I mean, yeah, TDD is a big part of it for me, but it's not the only thing and I started thinking about it and I'm like, well, what, what kind of Actually, the thing that I actually care about the most and to me all comes back to feedback, you know, it's you have technical feedback, so TDD it's excellent example of technical feedback, you get feedback in seconds, You know, I, I create bugs all the time but I spot them within, it's not even me, but my process spots them seconds after I've done created one, you know. So it's so rare for software that I've written to end up with a bug in production or even to go, you know, pre-production. I don't really like pre-prod but, you know, in some organizations you made to do it.
But yeah. The whole, the whole mentality to me is It's about yes you got your technical feedback like that and then you've got non-technical feedback which is is information from customers or stakeholders as well. It's why I like internally, I'm a big fan of demoing software early and often as soon as we've got something to show, we should demo it and like I don't mind demoing work in progress or if it's we haven't made much progress that week or whatever. We can just demo that just keep it open, you know, it's the same with, you know, the non-technical side of it. And so I'm just trying to govern my thoughts but the the key to it for me though is that if you're doing the wrong thing like say where We might have the best code in the world. But if we're building the wrong products or something, that isn't going to be a hit with customers, Do you really want a risk, you know, waiting six months or a year or 18 months to find that out? Do you know what I mean? And so I would much rather my kind of thinking with it is, you know, Get something out that people can use build it with it in a way where the technical foundation is really strong so that you can change things easily over time or with very low stress. So very, very low fear. I should say in high confidence. Which is perfectly possible to do. and then, Yeah, based on the feedback. And adapt, right? And I think a lot of companies that the way that I kind of see this, this kind of friction, because I think there is a friction with people at the top who come in. And, you know, I've got Two million pounds to invest in this, in this products. You know, I wish I did.
Oh, I'd love to, I'd love to be able to, but you know what I mean? I come in there and a person at the top with the money, right? And I want to ensure that my investment you know isn't isn't wasted. So I I need people to then come up with and tell me exactly what they're going to do and what they're going to deliver and all of this, you know what I mean, and how much is it going to cost me? And I can understand that mentality. But the problem is there's a deep kind of irony in that that kind of top level command driven mentality. In my opinion, actually increases your your risk significantly because if you took a different approach and just accept the reality that people can't tell you exactly if it's going to be a hit they can't tell you if you might not get exact dates and stuff but if you have a process where you can find out as quickly as possible that this idea you've got actually isn't quite right or maybe it's nearly there but you're missing something or you you just you could pivot you know to mean a certain point the quicker, you get that feedback and act on it, the quicker you move into the right direction and that's that increases. Your chances of making more money. That's to me, it's a, there's a kind of irony that it's often the people at the top who, you know, have this kind of, Oh I don't want problems, I want solutions kind of, you know, attitude.
It almost, you know, puts their money at greater risk than if they worked with people who you could gather feedback quickly and push the products in it in a better direction based on feedback. Do you see what I mean?
Alex Bunardzic
Yes. Yeah, I have three comments if you would allow.
Paul Hammond
Yeah. Sure.
Alex Bunardzic
The first comment is — I'm delighted to hear that you are doing TDD on a front end because this is the most neglected area.
Paul Hammond
Yep.
Alex Bunardzic
Have you heard of Robert. Martin (Uncle Bob)?
Paul Hammond
Yep. Yeah, yeah. Yeah.
Alex Bunardzic
I had cut the video with him. And we, I have another channel called “Coding interviews with Alex”, where we take talented people such as yourself who volunteer and we pretend you're applying for a job and then we have a panel this time with me and Bob (Uncle Bob) we are the interviewers and we throw a challenge at you and you share your screen and you walk us through your your line of reasoning and how you tackle the problem. And it's not about solving, offering the solution. But for people who are watching to learn how top-notch, you know, the developers operate and think and to remove the mystique. And to to see how we like to say, we all create bugs all all day long but how do we roll with the punches? So to cut the long story short, what I'm trying to bring to the light here is Uncle Bob is one of those people who is adamant that TDD is not applicable in the front end and that may be doing the damage. So maybe you and I should drag him
Paul Hammond
He's wrong.
Alex Bunardzic
on the call sometime and you show him that he's wrong because he's quite,
Paul Hammond
Yeah.
Alex Bunardzic
you know. Okay, he's a stubborn man. He's a brilliant man, but he's a stubborn man and he's digging his heels in. He's like, no, I would never do it in the front end. If you could kind of arm-wrestle with him and show him,
Paul Hammond
Oh, I'll show him. Yeah. Bring bring it on. Yeah, let's do it. Honestly do it. I'll show you.
Alex Bunardzic
He's so, so adamant and I didn't have ammunition to push back, right? And I'm like, okay,
Paul Hammond
No, I
Alex Bunardzic
whatever.
Paul Hammond
I can push back. Honestly, I've been doing to give you an idea. I mean, I've been doing TDD on the front end since about probably twenty, thirteen something like that and I do it every day. I've been
Alex Bunardzic
Wow.
Paul Hammond
doing it. You know, I've done it in every organization. Not only is it possible, it works beautifully. It's it's a really really good but the the interesting thing there, when you say that, you know, Uncle Bob might I know, of course, I know who he's I've got some of his books and
Alex Bunardzic
Yeah.
Paul Hammond
Yeah, but I've always disagreed with him.
Alex Bunardzic
Okay. That's sorry. Some of our colleagues don't know who he is, which is like,
Paul Hammond
No, no. But I, yeah, I'm fully fully aware fully aware, but in
Alex Bunardzic
come on.
Paul Hammond
yeah, the interesting thing for me is that a lot of people who over the years have even not just push for TDD, but who and we're involved in I don't know, actually coming up with the idea or popularizing it and writing books on it. Most of them came from, if not, all of them came from the back end perspective, do you know what I mean? And, and that's where You know, most of the. So it's interesting because what most people it
Alex Bunardzic
And then the green screen.
Paul Hammond
Yeah.
Alex Bunardzic
Before the GUI, right?
Paul Hammond
Oh yeah. Oh well, yeah, yeah. I mean I still love the um, I still love the terminal to be there. I love it, you know. But now it's yeah, I can I can show you and it's the funny thing is though when I see the advice that most these people give. I I almost went well just always end up disagreeing with how they, how they suggest to do it. So yeah, I can, what would be ideal for me, is because the way that I tend to do it, I break it down into phases. I actually do have a talk on. You can see on YouTube. It's not on my main channel, Actually. It was. Um, do you know when tech excellence the
Alex Bunardzic
Yeah.
Paul Hammond
Valentina. Yeah.
Alex Bunardzic
I I had one of my talks on that channel. Yeah.
Paul Hammond
Oh yeah, so I I did a presentation that no you it does cover CD on the front end but it wasn't. I covered a lot of ground in that talk so it wasn't just about that. It was about kind of so much like a covered a lot of ground but I gave a small demo of it and I do talk about the process and what I would say is if you wanted to do it I'd be absolutely like I'd love to do it because honestly, if you argue against it, I'll be fun. It will be a lot of fun that call. But what
Alex Bunardzic
Yeah.
Paul Hammond
I will say though, is that the way that I kind of I typically designed it, go with TDD on the front end, is it? So at the very beginning, you've got a few concerns on the front end, right? So you've got the look and feel and then you've got the the behavior, right? So the look and feel like the CSS and stuff. I don't test CSS in that way, and but when it's behavior, I do, right? And but, and there's an exception to CSS because if there is a business behavior associated with it. So I don't know user performs, some kind of action and then an element disappears or appears on the page that to me is a behavior. So I would test that. But what I'm getting at is
Alex Bunardzic
Yeah.
Paul Hammond
The best way to do it would be, if you could. Like I understand that like you want to set it as a as a kind of technical test. I shouldn't know what's coming which I'm fine with. But the only issue I would say is that to really kind of show it that the process that I have is that I always like I normally start with styling kind of first and a style so I know the markup and the style beforehand and because I've got the look and feel, right? And then but then I kind of recreate the whole thing with the behavior going test first. Does that make sense? So I wouldn't want to be right in CSS on the
Alex Bunardzic
Yeah.
Paul Hammond
call is what I'm getting at, you know, I mean, but if you want to, if you want, if you want to do it, if you could tell me, maybe in advance, like here's what it's gonna, you don't have to tell me the behaviors. But here's the his what it looks like. And I can have some styling ready because that's how I would normally do it. And what I typically do is I use tools like storybook right, so I don't know if you're familiar with storybook. Yeah. So typically what I would do is if we've got like a new front
Alex Bunardzic
Yep.
Paul Hammond
end component coming up. I I usually get this styling in first and then I'll show that to like Ux or whatever first and they can see it and they can say, yes it looks right in all these various, you know, viewport sizes and so on and then we're good. And then we come to do the actual behavior and that's where I I almost take it as if I've not written any of that code and then I kind of redo it. But with the behavior this time, do you see what I mean? And So yeah, I'd absolutely love to do it though honestly. It'd be so much fun.
Alex Bunardzic
Yeah, that would be awesome. I think his principal argument against TDD on the front end is, he feels that there's a lot of arbitrarily finicky feedback from the users. Oh, yeah. Not not necessarily the look and feel, but the user journey and like, Oh, no, now show this. No, when I click, and he feels, that's much back and forth, but which he feels. It's a maybe a bit frivolous frivolous as compared to your business rules on the back end, which are way more reasoned about and more rational; front end can invokes some emotional charges.
I think that's where he's coming from. Maybe. I don't want to put words in his mouth but it would be awesome to get you two together and butt heads and see where we get and
Paul Hammond
Yeah, yeah, we we can do honestly and just one of
Alex Bunardzic
Because, you know, he's
Paul Hammond
Yeah. Yeah.
Alex Bunardzic
a smart man, he has strong arguments and I would like, love to see you, convince him otherwise. Okay, so we can talk offline and we can get if Uncle Bob is available.
Paul Hammond
Yeah. No, that would be, that would be good. Yeah.
Alex Bunardzic
Another feedback. What was it? Oh yeah. I recently had some discussions online with regards to usually people say Well, TDD is not about testing. It's about design, but I'm in the camp saying TDD is not about design, TDD is about feedback.
Paul Hammond
Yep.
Alex Bunardzic
Primarily. That's the purpose. I'm doing. TDD is like, you say, I crave instant feedback. Because text is unfortunately not a good in my opinion, not a good technology but this is what we have. So I can go and make, arbitrarily make changes to the text and the paper takes anything as the saying goes. So, I'm not comfortable when I go and make a change. And then I hear crickets
Paul Hammond
Yep. Yep.
Alex Bunardzic
from the system, you just see it idling like okay, whatever dude, I want the system to immediately spring into action and tell me
Paul Hammond
Yep.
Alex Bunardzic
Oh, I hit the barrier here. I hit the wall or, Oh, everything is smooth sailing. And that's where I see TDD really helping me. Push back or go green, go red, whatever. That to me is
Paul Hammond
Yeah. Yeah.
Alex Bunardzic
the primarily. So I would, I would turn the tables and I would say that TDD… Good design is necessary for quick feedback. Not the other way around.
Paul Hammond
the thing for me is I So it's interesting. I think I think I pretty much agree with what you're saying, really. I mean, I do the way that I've always described it is, I don't use TDD primarily as a design mechanism, but I listen to my tests and I will adapt according. So if something could what I like and about what there's many things I like about it, but in terms of design, you it forces you to be a consumer to your own API, right? At the very beginning, whether you're doing it, front and back and whatever you have to be, you create some form of API and you have to be consumer straight away. So you instantly get a feel for what it's like as a consumer of that API and sometimes I'll be working. Usually like if I'm going to do a piece of work I usually I don't think there's anything wrong with a little bit of planning, like I don't like big up front planning but like drawing a few boxes or Here's what I think I'm gonna do, you know, that kind of thing, but then I'll start and as soon as I something just feels wrong, you know we talk about cold cold smells, right? But this is like kind of
Alex Bunardzic
Yeah.
Paul Hammond
Of a design smell or something, you know, I it I'll adapt then. So to meet some
Alex Bunardzic
Yeah.
Paul Hammond
TDD plays a role in the design but it's more. It is based on like the feedback that I get it. Does this thing feel right as I'm working on it. Do you know what I mean? And because I'm exposed to it. Very early, what tends to be? The case is, like, when I. So, we did a big piece of work recently in the place that I'm at now. And one of the big things that we did.
It's a multi-branded application as I say it said before, right? So I think we've got 9 or 10 brands now and it's about a journey and acquisition journey that takes you through applying for a loan or maybe a credit card and The thing is though the the branding is quite it's complicated, right? Because you've got visual looking feel, it's different, you've got some on some, some
Alex Bunardzic
Yeah. Right.
Paul Hammond
pages, elements look different sometimes for different brands elements appear. And don't, sometimes you have different texts on in certain areas and but also the journey logic itself can be slightly different between brands. So you can be redirected to a different page in a different order depending on whether you're coming from one brand or another and that gets complicated quickly when you've got hundred well. So like I say we've got 9 to 10 brands but there's so many variations, right? And it was getting out of hand for us and getting really complicated. So I work with somebody else. A paired with somebody to Create a kind of API for how this would work and we had there were these kind of big debates going on like people wanting to plan everything. Go up front, You know, No, we need to know exactly how this is. All gonna, you know, and my, I kept saying to everybody just kind of calm down a bit, We'll have a good idea what we're doing, we'll sketch out some ideas, We'll start test driving it and as soon as we find out that something doesn't work, we'll just adapt because the test will make it easy for us with apps and change, right? And that's what happened. We ended up delivering it very successfully. But not only that people who've come into the code base since that I satisfying moment recently, where one of the guys on our team was pairing with somebody new, this is only a week or two ago, somebody new joined the team and he was pairing and he was explaining bits and he messaged me afterwards to say Just so you know, when I was showing this bit of the code, I was so proud of like how neat it is and stuff because it ends up looking like it was really well designed and it kind of was, it wasn't just organically, didn't just come magically out of doing TDD, but
Alex Bunardzic
oh,
Paul Hammond
We but I knew I didn't need to know all the answers necessarily upfront. I had to have an idea where I'm going and factor that in but I also feel comfortable enough to not have to be not have to implement more than we actually need right now. And To know that he's going to be alright I can change the API, the cost of changes lower so they're that's how it helps me with designed. You know what I mean?
Alex Bunardzic
Yeah.
Paul Hammond
It's I don't expect I'm just going to come up with a magically beautiful design if I don't think at all. But I I it's a combination of thinking about what you do in having you know, bringing your experience and stuff and And knowing that the cost of change remains low. Do you see what I mean? You get
Alex Bunardzic
Yeah.
Paul Hammond
that feedback. Yeah.
Alex Bunardzic
Yeah, totally agree with you. I would add that I'm big on what they call Interruptability and a lot of people frown upon that, I think one of the virtues of a good software developer engineer is eagerness to be interrupted. Most people go No, no. Don't interrupt me. I'm in my zone. I'm always delighted
Paul Hammond
Yep. Yep.
Alex Bunardzic
when I get interrupted.
Paul Hammond
Yep.
Alex Bunardzic
It's more frequently, the better.
I myself, I'm a lousy designer. I'm pretty bad at design. But thanks to TDD and the process you're described, I end up with a pretty acceptable, tolerable design because TDD keeps interrupting me. The process keeps really kicking me in the nuts, you know. And like, oh and without TDD I
Paul Hammond
Yep.
Alex Bunardzic
would go and then build some house of cards and I would think everything is okay. And then later to discover that it's just a building on a quicksand
Paul Hammond
Yep. Yep.
Alex Bunardzic
but TDD every step of the way is kicking me really hard. It's saying, Look, you’re just painting yourself in the corner. What you just propose here is not testable at all. Do you realize that otherwise, I wouldn't realize if I was
Paul Hammond
Yep.
Alex Bunardzic
not test first-minded.
Paul Hammond
Yep.
Alex Bunardzic
I would think of the beautiful edifice. It makes perfect sense. This API is great, but the TDD is going, No, it's not testable. You're just going in the wrong
Paul Hammond
Yep. Yep.
Alex Bunardzic
direction. All of a sudden, your tests are going to start, really being sluggish and slow. Anytime, anytime I test suite starts slowing down I know I'm in trouble. I know something is terribly wrong with the design. I don't know what it is. Like I say the cost of changes minimal, the feedback is
Paul Hammond
Yep.
Alex Bunardzic
frequent, all the good things but we need to place ourselves in the position where we are interruptible. No, I'm gonna be
Paul Hammond
Yep.
Alex Bunardzic
banging the code for this afternoon and don't anybody interrupting me right?
Paul Hammond
Yeah, it it's a funny thing that when you say that as well, because I remember I remember some time ago years ago actually having the the perspective of somebody who Didn't like being interrupted and I am in the Zone. And I remember arguing against people who said, Oh no, you should embrace that, but I've come definitely the complete opposite now, and but that happened over time and One of one of the things that, so we're talking there about like TDD doing that, you know, it's a technical form of interruption, but I am as you also said, you know, being interrupted by people as well.
Alex Bunardzic
Yeah.
Paul Hammond
for me, I I enjoy it now and the reason I do again, it's one of the things for me is I feel like over the years, I became a lot more rounded as a developer. I the early years in my career I was focused almost exclusively on the tech side of things and, you know, I I was this. I was that guy for a while who put my headphones on and I want to be in a dark corner and I just want to bash it out. Do you know what I mean? That's that's how it was.
Alex Bunardzic
Yeah.
Paul Hammond
But over years, I was looking enough to work with some really strong people and pair with them as well. I love pair programming, you know and You see how some of these people work and how they would have, the they would be given a technical problem to solve. And instead of just going into it, they're going to speak to people. And but why why? Exactly explain again, why you need this thing? You know, and they start breaking it down and having these conversations and all sudden the amount of times I saw out of just a conversation. We don't need all of this stuff actually. And actually we only need this smaller thing and that's that's perfect. That's oh and the business people are like no, that's all we ever wanted. And it's, it's something that I actually to me it's like a source of pride. If I can if I have a conversation with somebody and it turns out, we don't need to write that code at all. I actually feel quite, you know, really good about that, you know.
But yeah, as you say it's why I'm quite happy with a the feedback driven kind of, you know, domain and stuff. It's it's I think it does kind of capture the, you know, what is to me is very important, it's technical and non-technical forms of feedback, you know.
Alex Bunardzic
Yeah. Yeah, I tell you my first promotion on the job happened when I was working at that Government Bureau for Healthcare, My boss called me to her office and she said, she said, Alex, I was, I was kind of monitoring or observing and looking at how you work and I'm blown away and I like that you can spend days just
Paul Hammond
Yep.
Alex Bunardzic
coding and you never even stopped to see if you can compile; it just shows such level of mastery. It was the exactly she thought that's that prowess, but I was stupid, completely green, you know, wet behind ears. We all thought Machoism was like, Hey man, I can keep banging the code, it was cool back then, you know, all day long, never having to stop to compile, because I'm so good at it. So we were
Paul Hammond
Yep.
Alex Bunardzic
avoiding feedback. We enjoyed working in secrecy, we're anti social
Paul Hammond
Yep.
Alex Bunardzic
and all the bad things that we are still suffering under to this day where most people valuing working in secrecy, every now and then, they surface with the PR
Paul Hammond
Yep.
Alex Bunardzic
And they replace collaboration with communication. Communication is very low bandwidth, compared to collaboration. Which I know we're gonna have to agree
Paul Hammond
Yep.
Alex Bunardzic
on that. And another thing I want to just mention quickly, the entire XP
Paul Hammond
Yep.
Alex Bunardzic
philosophies, It's all about Interruptability.
Paul Hammond
Yep.
Alex Bunardzic
XP Philosophy brings options to the clients meaning at the end of every business day, you you have the choice as a business. We want to continue tomorrow. Are you? Are you good? No hard feelings. We give you what you paid for, the system is always up and running. In the, you know, like you say it's an incremental it at this point in time. We
Paul Hammond
Yep.
Alex Bunardzic
have these options, these features are but they're up and running and you can walk away. Say, thank you very much. This was brilliant. We don't intend to
Paul Hammond
Yep.
Alex Bunardzic
continue anymore, maybe later. That's the beauty of XP. That's the promise to the business. If we, at a point in time, every day you have something working.
Paul Hammond
Yep.
Alex Bunardzic
It's not maybe nothing to write home about, but it works and you got
Paul Hammond
Yep.
Alex Bunardzic
your money's worth and therefore we are as team. We are interruptible.
Paul Hammond
Yep. Yep. Yep.
Alex Bunardzic
And that's a promise to the business, right? That's our value and unlike the
Paul Hammond
Yep.
Alex Bunardzic
waterfall, where in 18 months will come back and you.
Paul Hammond
Yeah, yeah, yeah.
Alex Bunardzic
so,
Paul Hammond
Now, I mean, it's Talking about it like this. It's just, it's just so bizarre that it to me anyway, that it, it hasn't taken of the industry. It's It is such a bizarre thing because it's These are my perspective, it just works so well. You know, to me and it's like you say, if you're the person with the with the chat book, would you not rather be in that position where the the team are delivering something is working and they say, Okay, you know you if you want to call it a day that's fine or we continue. Is that not surely that's far lower risk than you know give me a big
Alex Bunardzic
Yeah.
Paul Hammond
give me a gunshot with like you know, 18 months on it, you know?
Alex Bunardzic
We are professionals we show concern and consideration for our employers and
Paul Hammond
Yeah.
Alex Bunardzic
I value your, I I am delighted that you want to invest the money, pay me something, but I would be very careful with your money every day. I will give you some value every time you want to continue or not. This is a professional behavior and I think it's ethics, you know? And so the problem I
Paul Hammond
Yeah.
Alex Bunardzic
would from my perspective. Maybe you disagree. The biggest problem is optimizing for utilization. So like you say, if you're a guy with two million pounds and now you’re assembling a team of genius developers. Each hour is now costing you 5,000 pounds. You want to see something for that money and you make the mistake veering towards “Let's make sure everybody's busy all the time”.
You got to make sure that everybody's plate is full at all times. I don't want people idling because we're paying big bucks. And that and I'm also like Look instead have you considered instead of optimize for utilization? Because that's foolish because fully optimized highway becomes a parking lot. You know, it kind of defeats the purpose. So purpose, why don't we focus, more shift, focus on optimizing for value delivery.
But that's much harder because it's much easier to track utilization, but what
Paul Hammond
Yep.
Alex Bunardzic
is value, how do we track how it being delivered? It takes brain power, it takes hard work, people go for the low hanging fruit. You know, like you said JIRA
Paul Hammond
Yep.
Alex Bunardzic
tickets the burndown charts blah blah, that's vanity metric that doesn't help anyone but masks that dysfunctional process. And then
Paul Hammond
Yep. Yeah, that's Yeah that's exactly. It's no it's no no. We see exactly how I see it. You know
Alex Bunardzic
So, you
Paul Hammond
that's Yeah, I don't disagree that at all, you know, I I am. Well, you know, I know some, I, I thought about this myself in the, in the past, right? And I am, if I had like a big word of cash to invest on a product to build, I am lucky enough to work with some extremely talented engineers, right? And and most of the best ones that I know in my opinion. All of them is some really good engineers, actually, but most of the best ones that I I know, in my opinion, a contract is now in in the UK. So, you know, you you the whole thing with
Alex Bunardzic
Yeah.
Paul Hammond
contract, says, they cost a lot more in the short term but you know, you you can, you can just replace or whatever. Any point in time, I was thinking about this and I, I just kind of daydream to the past like if I was an assembling a team and I could just pick it people that I know have worked within the past. See what I pick right now. I'm not gonna name any names or anything, but there was one person in particular who I work with on a few gigs, a few geeks together because I've introduced him into places as well before, because he's so good.
And I thought to myself, but I know for a fact that I wouldn't, I pay his money if I had it, you know, if I, if I could do it and I know he's expensive but I pay it. But I wouldn't care if the guy was busy at the time. I just care that he's delivering what he should be and and that because I like who cares, whether he's like if you, if you have a team who are always busy and they get the, the JIRA charts look amazing. Every single every two weeks, what I hate scrum, so much but it, you know, and if they If they, you know, they all looks amazing. Every two weeks, you know, you've got like your little velocity chart and everything looks good. And you've got some spreadsheets somewhere and you know this team is their numbers are really high and so on. What does it matter if like that, that what they're doing brings in no money or doesn't help customers in any way? Like What does that matter? You could have a team of people who You know, barely barely write any code, barely do anything, but they produce 80% of the business's money, are they not more? Valuable like, Who cares? I Actually it's not about busy work, right? It's it's and, and having some slack as well.
Not only does it help. It not only does it help in terms of unexpected, things coming up and being able to handle those things. That's kind of an obvious thing, but it gives people a bit of thinking space as well. And when you've got really talented people who like you say are professional and actually care about what they're doing. You give them a little bit of thinking space and good things. Almost certainly going to happen. Do you know to mean that you're gonna new ideas will come up? And I don't know, they're just think of ways to improve things. You know what I mean? And this is. Yeah.
Alex Bunardzic
That, I mean, the success, the so called “success theater” that you described sometimes is called the Watermelon effect. Have you heard of that?
Paul Hammond
No, I've not heard of that.
Alex Bunardzic
So basically, every two weeks we get together, the watermelon is getting bigger and bigger, it's nice and green. Everything is in green, until such time when you open it up and everything is suddenly red!
Paul Hammond
Yeah, there you go. Yeah, that's it. That's yeah.
Alex Bunardzic
Okay, so in the interest of time, I don't want to take too much of your time and let's
Paul Hammond
Yeah.
Alex Bunardzic
switch gears. If you don't mind. I I really enjoyed your recent video on mutation testing. I'm a staunch
Paul Hammond
Yep.
Alex Bunardzic
proponent of mutation testing. I've been doing this for like 10 years. I often get hired. They bring me in as a best practices guy. So the guy who's gonna kind of introduce the change, and a lot of teams really hate my guts because I also push mutation testing. And and it really is a cold shower. When you have a team with like 100% test coverage, everything's beautiful and then the suddenly see like the army of surviving mutants and they're like, Oh but yes blah. So I really appreciate it. Your video. I think
Paul Hammond
Yep.
Alex Bunardzic
it's really good. Everybody should watch it because you, you bring really good
Paul Hammond
Thank you.
Alex Bunardzic
points and it's an illustrative thing where you have all your columns are like in green, that's the watermelon, right? And then, you run Stryker and all of sudden
Paul Hammond
Yep.
Alex Bunardzic
and Oops.
Paul Hammond
Yep.
Alex Bunardzic
Now. That you know that on a side we don't want to hear necessarily pump the mutation which I think is a brilliant thing and you brought a lot of good points but I want to just apply to the AI and to the right coding and
Paul Hammond
Yep. Yep.
Alex Bunardzic
Because I think it is indispensable.
Paul Hammond
Yep.
Alex Bunardzic
A lot of people complaining when they're doing AI-assisted coding that yeah everything works but actually I don't know what amount of code may have been written that I'm not aware of and I think this thing is a perfect mechanism.
Paul Hammond
Yep.
Alex Bunardzic
To simply say Well what about this? Junk over here? What's this all about? Right? And like say we are delighted when we
Paul Hammond
Yep. Yep.
Alex Bunardzic
We delete chunks of code, this gives you great feeling, we love deleting code.
Paul Hammond
Yep.
Alex Bunardzic
so you can talk a little bit more about your experiences, what your philosophy on Stryker is
Paul Hammond
Yeah so so there's a few things to cover there I guess from the AI perspective I mean well just quickly on this the stryker thing so I haven't so I do say in the video as well but I haven't really used StrYker professionally before this is
Alex Bunardzic
Yeah.
Paul Hammond
kind of new new to me. I say it's new to me. I I didn't know that there was even a name for this so that you could also make it until maybe 18 months or so ago. Maybe two years ago. Why, what I've done for years though is kind of a Maybe a less less like a more manual version of what you do when you join a team, right?
Alex Bunardzic
You describes new video? Yeah.
Paul Hammond
So yeah, yeah. Okay, yeah. So again, maybe for people people who haven't seen
Alex Bunardzic
It's a good.
Paul Hammond
that, so if, if I'm reviewing somebody's PR whole discussion in themself, but if I'm reviewing somebody's PR, I have a habit of pulling down the code. I'll run the tests almost there way to expect to see them pass because it's a PR, you know, and the should pass and then I'll go in and I'll just look at the code and you know, you've got a greater than this, You know, if age is greater than 18 do this. So then I'll change it to great less than and run the test and the amount of times you see the test pass when they should fail. So I I have done that for a long time, the automated way of doing it. I did try to bring it in into a previous place, but I didn't have a huge amount of time to to spend Trying it. And the problem that I had at the time was that it was very slow, right? And I just didn't have enough time to really investigate it much more, but my thinking, on this now is my understanding is that there's an incremental mode to it which allows you to kind of test the, you know, to only mutate things that have changed. So I need to experiment with that more.
To go into the the whole ai side of things. So I don't know if you, are you aware of the kind of cloud MD file, that I wrote some time ago. So you might not be aware of this. So if I give you this, can I give you in the chat if you want to just, I don't know if you're so I I wrote This call a keyboard isn't, that's weird. So my keyboard's not working. Let me just No. No, that's really strange. My keyboard isn't isn't working so I can't, I can't type. But if you go to If you go to my github, which is City Paul and you, look at my dot files, I've got a dot files there. And there's a, There's a Claude folder there with a Claude MD in it.
Alex Bunardzic
Yep.
Paul Hammond
And the the it's probably can the chord MD file there and it stresses the importance of going test. First I've got a whole it's a really big file and some people have criticize it for being a bit too big. And it probably is, I think it's probably fair but I've got a ton of rules in there and loads of examples. So I go into quite a lot of detail because I was finding that Claude was not when I first started trying to use it it was running away doing way too much stuff, right? And and I couldn't In the scope of what it was doing. I didn't have confidence that it was it was testing things properly. I was throwing away most of what it was doing. This is on a personal project of mine.
So I created this Claude MD file which has a load of like what I consider to be kind of rules that I follow some of which I think just kind of objectively better, right. So test first for example and I've really emphasized a test first in it but then these other things that are just like maybe a bit personal to me, my kind of coding style and stuff like that. I I felt so I made a video that if you go on on again, if you go to my YouTube it's a much longer video. It's like an hour long. It's the first one I ever did. So now we're in a bit long and it's me showing how I was getting claw to use this, kind of TDD and XP kind of approach.
I managed to get it to a point where it's it's far more effective. Let's put it that way. It's not perfect, but it's far more effective. So by making it go test first. I should be careful with this sorry and it's not test driven development in the way that we me, and you would understand because it doesn't quite do it, that way, it doesn't go one test and then what it tends to do, even though I tell it in the instructions, go want us at a time and do you know what I mean? Then make it past and then you know, Refactor, if you, if you see a reason to it, tends to go multiple tests at once writes a few a chunk of them and then make some pass and so on. But I'm kind of alright with that at the moment because I've been experimenting with to see how it goes, and does it work for the LLM and it seems to work quite well, because What seems to happen is it will going to first first of all, constrains the scope of what it's going to work on, right? So because it has instructions your job here. So, to right, these tests, then make them pass and then you commit right or do refacts. And then commit We should commit Pre-factor. Then commit, you know, And that that seems to work really well. I should emphasize that also in it, didn't it. This is a code base that I'd started myself. My normal waste. My tests are all basin behavior, not implementation details. And I force it to follow that approach and so on. So, I've had quite a lot of success with that.
So the Actually, the talk that I gave the YouTube video, where I talk about mutation testing is in the context of that repository, because I'd gotten it to the point where I have 100% coverage. And what I had been doing all along was Trying to get it to work in smaller chunks, going in this kind of test for style and then it will create a PR. And I kind of review the PR myself. Again, It's a whole other discussion because I'm not a big PR fan, but it works well for this flow, of course it's, you know, you're not dealing with humans, right? So I want to check it. It's appropriate. I think and then Yeah. See you Yes. So I'd review the code and then I do my kind of thing where manually trying mutate things, right. And I've been doing that and and I had this niggling doubt though and at one point I was thinking, Well, I'm almost going to quickly through this and I must have gaps. I was reading for it. I'm like I know that that okay coverage is 100% but I've just got this feeling that there were gaps in there, so that's when I thought, you know what mutation testing, I'll take the time to try and run that free Striker, so that's what I have done. So the the video that you've seen there that you saw there was was exactly that it was done on the same day that had got that working.
And as it happens because it's a spare time project and I've got young kids and, you know, a very busy, I tend to just work on a Sunday evening on it because I want to spend time with my kids, so I don't, I don't do it all the time. It's
Alex Bunardzic
Yeah.
Paul Hammond
usually Sunday evenings. I work on it, but my thinking on it now is that the next thing that I want to do on that is is exactly what you said. Because I think it's it's exactly the kind of thing you need, especially when you do using an LLM, I mean, you should do it anyway, you know, but but my thinking now is
Alex Bunardzic
Yeah.
Paul Hammond
it's going to go test first. It's going to constrain the scope of what it's doing. So it's smaller chunks. And then as part of the review process, or even before that, it's going to, I'm going to force it to always run the mutation test in incremental mode is my thinking, so it should just check and any surviving mutants. It either has to plug the whole or understand why? It's okay because maybe there's a reason. I mean, you know, there might be the odd reason, you know for that. But that's my thinking, is to really kind of push it with. But what I will say though is that by going in this way, this kind of test first manner, I I found that it suddenly the, the tooling has gone from being Like a novelty like a bit of a party trick but couldn't really use it to actually, I'm saving myself weeks of time here. You know, like, really, I mean, on a Sunday, I can do probably a week's worth of working about five or six hours, but I say that. But to me that's not it's we're not really there yet
Alex Bunardzic
Yeah.
Paul Hammond
because I don't truly have the confidence that I should have because we've seen that through mutation testing right. So I don't see it is. Until my next thing is to do what I've just said but then I need to take the time out to plug those holes first as well. And I want to go through them one at a time.
Alex Bunardzic
Exactly. And the teams are encourage the teams to sit down and collaborate on
Paul Hammond
I want to get either complete confidence in mutation, testing us in like no meetings at all. Or if there are mutants, there has to be a good reason as to what. So, an example that I remember given an example in the video, there is some CSS styling at one point that isn't associated with a behavior. It, I just happen to be using, like a function, a JavaScript function to determine. I can't remember exactly the context on it. But it was, it isn't a behavior that I would consider like a business behavior. And so, to me, it's like, that's, that's an example of why I'd at least I mean what I'm being very deliberate. About what I'm leaving. And do you see what I mean? Yeah.
Alex Bunardzic
calibrating. The mutation testing tool to safely, You know, ignore these things,
Paul Hammond
Yeah.
Alex Bunardzic
keep over that, Don't worry about that. We are all cool with that, but that's a thing, right? And then, whatever else is left. I gather I I advise you need to kill those mutants. Because the wheather it’s human or AI-assisted, we all tend to produce bloat but bloat is the Nemesis of our profession somehow things just mushroom. You know, I don't, I can't explain why. So I think we are on the hour now. I don't want to keep you any longer, I really appreciate you blazing, the trail. I would like to ask if we
Paul Hammond
No worries.
Alex Bunardzic
can maybe continue later. I don't think we've exhausted, not even nearly, the topic. There’s more to talk about.
Paul Hammond
Yeah. Yeah, sure.
Alex Bunardzic
So, let's plan maybe for later. When you have some time either. I’ll be dragging
Paul Hammond
Yeah.
Alex Bunardzic
Uncle Bob, and I can continue with this discussion.
Paul Hammond
I'm happy with with either or even both like he's fine with me. And yeah, that's
Alex Bunardzic
Oh excellent.
Paul Hammond
that's fine with me and definitely if you can reach out to Uncle, Bob to, you know, honestly, because I I I'll be so much fun honestly, especially especially
Alex Bunardzic
Oh yeah. He's gonna come to the challenge because he's he's committed. He's gonna trample
Paul Hammond
if he's really against it because honestly, I'll show him but like it's good, it's good. It'll be fun.
Alex Bunardzic
his convinced. He's gonna trample all over anyone who tries to convince him, otherwise, so he's gonna be fun match, right? But put on your best, boxing
Paul Hammond
Yeah. Yeah.
Alex Bunardzic
gloves, but
Paul Hammond
It's gonna be amazing. I love it.
Alex Bunardzic
Yeah.
Paul Hammond
Yeah.
Alex Bunardzic
but, Aside from that. I think what we’ve tackled here is just scratching the surface. I
Paul Hammond
No worries.
Alex Bunardzic
think you and I have a lot of other things to talk about and my brain is just buzzing as you're talking but we don't want to just you know, spend too much time. So thank you so much for this for your hour. It's been enjoyable and great to meet you in person virtually and if you ever come to
Paul Hammond
Yep. yep, you think
Alex Bunardzic
travel to Vancouver, give me a shout, we can get together for a beer.
Paul Hammond
Yep. Same if you're ever in the UK, especially in the Manchester area. But yeah, no. It's it was fun. I enjoyed it. And yeah, happy to do another call or
Alex Bunardzic
Thank you very much, Paul. So we will talk soon. Okay. Cheers.
Paul Hammond
multiple in the future. Yeah. Yep. Awesome. Thanks a lot. Thank you. Bye.