 Namaste. I'm Johannes Broadwell and I'm here from Agile, India with Corey Haines. Hello. Hello. It's great to finally meet you. I've been doing some of the stuff that you've been teaching for a few years, so it's good. Yeah, I see your name all over the place, so it's good to meet you and more than just like a little tiny picture, so. Yeah. So, you gave two talks at the conference today. Yes. One of them was sort of just thoughts and lessons I've learned over the last ten years of practicing XP. I got introduced to it in 2004, and so this is sort of ten years on, and so it was just kind of just sort of some ideas and thoughts and lessons I've had around some of the technical practices and some of the team practices and just things I've seen that I've taken into myself and work. The second talk was a much more code heavy. It was about the four rules of simple design and some of the lessons I've learned in applying those at code retreats, working with the people, the participants, and making comments about them and doing very small, subtle design decisions. Right. All right, so let's start with, there's two things there that I don't think everybody knows. So what's the four rules of simple design? So the four rules of simple design, they were codified by Kent Beck in the late 90s, and the first is that your tests pass, which doesn't really matter how good your design is if you can't prove it works. The second is that it expresses intent or really good names. Really pay attention to what the code, how the code reads. The third is no duplication or the dry principle a lot of people have heard about the don't repeat yourself principle, and that one is a really about duplication of knowledge rather than sort of the mechanical duplication that we oftentimes think of, oh well here's two pieces of code that look the same, let me eliminate duplication, but really looking at the knowledge points of your system. So what would be an example of knowledge duplication? So for example, one of the ones that I gave was in Conway's Game of Life, which is the sort of domain that I was giving examples in, oftentimes you'll see, because the problem is on a two-dimensional grid, you'll often see people passing around X, Y to a bunch of methods. This is really the knowledge of the topology, and so eliminating that duplication as soon as you see it causes you to think about what are those X, Y represent, so you reify it into something like a location object or something, and so that's really knowledge as opposed to this mechanical, there's two things that look similar. So as a sort of, if you think ahead a lot, which I don't know if we're supposed to do, then if you put it into location, then you can add a third coordinate without changing your code. It's very good. The whole goal of simple design, the point of design in general, is to make it easy to change, but you can't know what needs to change, so you're not building systems that are ultimately configurable. That's right. Do that, but by really extracting out these knowledge centers, you get the right classes, you get the right abstractions, and it's happenstance that you end up finding that, oh, well, making a change to the dimensionality is there. Another benefit that comes out of it is you get what I call behavior attractors, which is when it comes time to add a new method, say, you need to find the neighbors of a certain cell, oftentimes you'll have a method that's like neighbors of something, and there's that question of where do you put these methods, and usually... Oh, that's a static method, isn't it? Yeah, it's a static method, of course. And so oftentimes we will just like, well, I'm in this file right now, so I'm just going to put it here and wait, but if we extract knowledge into domain objects, then they tend to be natural places for behavior. So a location object, which you created by extracting this duplication, is a natural place to find a method that has to do with the topology, such as give me the neighbors for a location, and so you sort of accidentally have these domain objects, which naturally attract the behaviors that you're trying to build. Someone here at the conference mentioned the word serendipitous design, I think. Yeah, that's a great way to talk about it. It's just like, oh, hey, I already have a location. That makes sense to put it there. So there, the fourth one real quick. Yes, yes. The fourth one is small, which is once you've done your refactorings with two and three, make sure that you don't have anything there that you don't need. So that would be pencil the test, good names, no duplication, and small. Yep. Good. And that's the goal of talking about the four rules for me is that I've over the years come to sort of think of them as the sort of the generators of all the other design guidelines that we have. So just by applying these, you end up with things that abide by the solid principles, you find sort of design patterns come out, and so you find a lot, a lot of demeanor just sort of falls out oftentimes. Yeah. And so just over the years, I've gotten to where I pretty much just use the four rules, and I use the others as more of a descriptive form. So if you take a step back here, just when you talk about the sign, what's the process of the sign like when you work with code? There's a couple different layers of design. So there's always like the sort of the system design and the upfront thinking about how might I put together my system. I like to do that on a whiteboard, drawing pictures and things. I like to say that it's great to do upfront design, but it should remain where it belongs, which is on the whiteboard. And then you go in and let that be a guide for you as you write your code. And so I tend to use test driven development as my design methodology. And so I'll go in, you know, you write your test, write enough code, and then refactor. And I refactor according to the four rules, really the middle two. So the example where you have the index, int y, and you extract the location, that would be a refactoring happen. Yes. So why not do it right the first time? I'm not a very good developer. That's, I mean, honestly, that's what it comes down to is the majority of the experience I have in the design I have or the design experience has shown me that if I think very hard, I can come up with a reasonable design. If I think very hard and let refactoring guide me, then I come up with something better. And just to reiterate, the whole goal that I have for design is being able to change it easily in the future, regardless of what the change is. And so because I've found that I can do better if I think hard and use my test to guide me, that's the way I like to do it. And so just let it fall out, things come out as they come out. And you also, it might not be the location, extracting this was the best thing. And so you can move it back and forth. And I mean, it's over time design should change as you get more knowledge about the domain. I've found that often pair programming is an interesting tool in that sense. When I was less experienced and I pair program, if I would pair program something with someone that I had done before, I would very quickly try and force the design down the path I've done before. Yeah, I tend to, Ron Jeffries, I believe, told me one time a great anecdote that I were saying that I like to remember. And he said that when he first started pairing, he would always fight for his design. And over time, he got to the point where when there was a disagreement about what design path to go down, he would always yield to the other person. Knowing that if he was, if he was, if the other person was right, he would learn something. And if the other person was wrong, the he was a good enough developer and his techniques were good enough so that they would find out soon enough to shift the design over and to fix it. And so trusting your skills, trusting your techniques that you use to fix any problems that you have. Hey, it's encouraged one of the Core XP values. So I think that kind of comes down to seeing that in your behavior and trying new things. So the other word that you touched on in the beginning is a code retreat. So what's a code retreat? So a code retreat is a day long workshop that is entirely focused on practice, really low level kind of design practice and technique practice. We came up with the idea of me and three other guys, Patrick Welch and I, and Hydro Alola and Gary Bernhardt, about five years ago now. And over the years, really evolved and settled on the format. And so it's a day long workshop. We work on pretty much Conway's Game of Life. And you work for 45 minutes, paired up. And every 45 minutes, you delete all the code and swap pairs and start again. And then every session, the facilitator introduces a new set of constraints for you to sort of investigate the problem with. So things like no if statements or no primitives across method boundaries or no return values or these methods less than three lines. And so you introduce constraints that sort of jolt the developer out of how they would normally do it. Because like you said earlier, you tend to have this idea of how to develop it or how to build it. And so it's really hard to break out of that. You think, this is how I'm going to do it, this is how I'm going to do it. But by introducing constraints that keep the person from doing it that way, they have to come up with new ideas. And so it's a day of really like just really low level practicing coding techniques. So why would someone want to go to a code retreat for a whole day? Well, some of the stuff that I've heard people say at the end of it is it, you know, it really opens up your mind to alternate ways to solve problems, alternate ways to look at building software. Because we force you out of your comfort zone, you have to look at different things. And the other great thing about it is because we delete the code every 45 minutes, it's a safe place to experiment. Because I tell people that no matter how bad it is, on average, 22 and a half minutes later, it will disappear into the ether. And it doesn't matter. And so you get this opportunity to try new things. A lot of people come and they've never paired before. And so it's a day of safely learning about pairing or safely learning about TED. And since we don't show the code to anybody, we don't go and present it on a monitor, it's okay to make mistakes. It's okay to struggle. It's okay honestly to write no code. Like to struggle so hard that you can't write that test. I sometimes I tell people that write, you know, take a session and focus so hard on the tests. So hard that maybe you only write one or two, but they're the right ones. And having that practice means that when you go back to your work, and when you go back to the grind of deadlines and having to keep your code and all of that, you've practiced a little bit. So it's a little bit easier to do it in your day to day job. And it's a fun day. Like anytime you get developers together to code, you've got a good day. I'll have first time facilitators contact me and, you know, be nervous about I don't think I'm a great developer or I don't know if I have anything to offer as a facilitator. And I tell them that if you just kind of go by the format and you just get people together to code. And the format is freely available on the net at coderetreat.org. Coderetreat.org, the format's there. We have some sample constraints that people have. It's not the best organized site, but it's up there. Jim Hearn and Audie Balboaca, they are really kind of leading the global community now. They're sort of stepping up into these, well, have stepped up into very much leadership role in sort of the global community around Coderetreat. So I can definitely say that Coderetreat's changed my life. That's a great thing to say. That's I like hearing that. All right. Are you ready for the lightning round? Absolutely. So during the lightning round, I'll ask a question and you should answer it as quickly as possible. Okay. And then you will ring the bell so you can test it out. Okay. That's good enough. That's good enough. Is that when I answer the question? That's when you answer the question completely. Okay. All right. So what is your favorite programming language? I would say Ruby. And what's your favorite coding cartoon? My favorite coding cata. Lately, I've really enjoyed the Roman numeral cata, the converting numbers to Roman numerals. It's so simple and it's just a really fun one to do. And you said you have learned from thousand examples of game of life. What's the most important thing that you've learned? Um, write code. A lot of people will spend a lot of time discussing. And there's a thing I say that I'll find people who have been talking for 20 minutes and I'll come over and I'll say, you know, I'm not a I'm not a linguist or, you know, language historian, but I don't think English was intended to talk about software design. And you're sitting in front of a language that was explicitly built to talk about software design. So along with the conversation, if you have an idea, write some pseudocode or write some code and that way there can be no confusion about what you're thinking about. And I've learned that. So would you like to repeat the short answer? Oh, the short answer. Write code. Great. Communicate through code. I talk a lot. Thank you very much, Corey. Thank you very much. Thanks a lot.