Today on The Rabbit Hole we are talking about extreme programming and to help us with this we welcome our very own Kevin Thomas. Kevin is a consultant at Stride and a strong proponent of extreme programming! During the conversation we’ll cover the values that typify XP and unpack the importance of each of these after looking briefly at a definition for the term. These values include communication, simplicity, feedback and respect and Kevin shows just how these pieces fit together to form a clear picture of extreme programming. We then go on to look at the programming techniques that build on these values and the team’s experiences within this framework. The discussion also asks the questions of what exactly can be considered XP and what cannot. It is clear that there is some overlap or common ground between practices such as pair programming and TDD that are not always conducted in a XP context but fit into the paradigm nicely. The conversation ends on evaluating the pros and cons of the system and how to navigate potential issues of the territory. So if you want to get extreme with us and learn a thing or two, tune in as we go down the Rabbit Hole!
Key Points From This Episode:
Transcript for Episode 65. Extreme Programming (XP) with Kevin Thomas
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today -
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer -
[0:00:12.0] WJ: William Jeffries.
[0:00:12.7] MN: Today, we’ll be talking about extreme programming. We have a special guest. I’d like to introduce Kevin Thomas. How’s it going, Kevin?
[0:00:19.0] KT: Hi, how are you doing?
[0:00:20.2] MN: Doing all right. Kevin is a consultant here at Stride who loves extreme programming.
[0:00:27.2] DA: He looks like a pretty extreme guy.
[0:00:28.8] MN: Yeah. Kevin’s pretty extreme when it comes to extreme programming.
[0:00:32.8] DA: What’s the most extreme thing that you’ve done?
[0:00:35.8] KT: The most extreme thing I’ve ever done is to accidentally broke into a strip club. When I was very young, it was like, we were drinking on a rooftop and got like pretty drunk and my friends that never been to a strip club so we like, suddenly had a mission. We hiked like a mile away to find a place -
[0:00:52.9] WJ: This doesn’t sound accidental, this sounds very on purpose.
[0:00:56.2] KT: When we got there, it was only like one AM or something but it was closed, I guess because it was like Fourth of July weekend. One of my buddies like grab the doors of the place and was like, kind of jokingly and go like “no”, really upset.
It just came open like the dead bolt was sticking out six inches.
[0:01:12.0] WJ: Man.
[0:01:13.2] KT: So we wondered into this dark room kind of confused and my friend in the strip club was like fondling the stripper poles because he was just like, just a weird moment.
Pretending. My tiniest friend like jumped over the counter, grabbed the first bottle of liquor he could find and like ran for it and we’re like yeah, we just committed a bunch of crimes.
[0:01:31.7] WJ: What?
[0:01:32.2] KT: We got to get out of here. We all ran for it.
[0:01:35.7] WJ: Let me make this breaking and entering a little more extreme by adding some robbery.
[0:01:41.2] DA: Petty theft.
[0:01:42.6] KT: It’s not robbery unless you’re threatening somebody.
[0:01:44.2] DA: I was for sure that you were just going to say programming, like extreme programming. You know, this is more extreme.
[0:01:50.9] KT: I lead a real life.
[0:01:53.4] MN: Extreme programming is not breaking and entering - I mean, extreme.
[0:02:00.6] KT: I want to say, it’s called extreme programming but it’s not really that extreme. I think it’s called that, it’s kind of a marketing tool but it’s good because it actually takes a lot to buy in to work and once you call it extreme, people know that like, they really have to commit to it.
That’s why it’s called extreme programming in my opinion.
[0:02:17.1] DA: Awesome.
[0:02:17.8] MN: Yeah, I mean, like, that you want the commitment of everyone, every player was going to buy in to this thing so you load it with an extreme word like extreme.
[0:02:30.1] KT: We’re all in this together, it’s exactly like when you break into a strip club.
[0:02:35.4] DA: It does sound like more exciting than just regular programming too. If you're going to sell it to someone it’s like, you just program? I do it extremely.
It’s good for the sense of one-upmanship that can often happen and when you’re having conversation with other programmers.
[0:02:55.2] KT: I think XP comes like naturally out of the AGILE manifesto, there’s also AGILE principles that go into more detail but the XP values are pretty compatible with the AGILE values.
Like, the most important thing for us is to like see is communication, that’s the first value. It’s like to see software development as like inherently communication problem, it’s like, we always work on pretty big teams with ambitious goals and the choke point is always like, how well you can communicate, how well does your code communicate, could it be maintained, how low can you had it off to the next person?
It’s always a communication limited.
[0:03:31.2] MN: Yeah, I think like that goes back to like natural practices where people for process, what you want to talk to individuals rather than chuck work over some Jira board and stuff like that. I just feel like when communication is healthy, things can get done a lot quicker.
Do you have any other values you wanted to dive in to?
[0:03:52.7] KT: The next one is simplicity.
[0:03:54.7] DA: that’s also like the old process, like keeping it simple.
[0:03:58.3] KT: I think just keeping things like sensible, if you build the minimal thing, the simplest thing, that’s a thing that can go in the most directions afterwards. Think about being extensible because if you predict what’s going to happen and like start down certain paths then you’re actually making it less extensible which is not simple enough.
[0:04:14.7] DA: Even in your coding, not just in your process, making the MVP?
[0:04:19.6] KT: Yeah, I mean, specific matters the process too, if you have too much process which is easy to do if everything’s top down, you don’t get as much done, XP is more bottom up.
The third thing is feedback, a lot of these techniques are there to create immediate fast feedback loops like right there with your pair, they can tell you if like you’re doing something wrong, if they have different ideas.
You want to go to the customer and the user as soon as possible to like get real feedback and like have someone to like orchestrate everything.
[0:04:46.3] DA: Kind of like the customer collaboration aspect of the AGILE manifesto. Actually, talking to people rather than just assuming.
[0:04:54.6] KT: Yeah. The fourth value is courage which in this case like really means that you lean towards doing things versus not doing things because it’s better to like do the wrong thing, learn that that’s the wrong thing if you thought it was right at the time and then move on versus like, doing a thought experiment, you try to figure out what the right way is and then you’re still wrong once you commit to it.
[0:05:17.1] DA: That’s kind of speaking to like the responding to change bar of the manifesto where you may not have an entire plan but it’s okay, it’s going to be all right.
[0:05:27.6] KT: Yeah. Makes your change actionable instead of just being an idea.
The last thing is respect, it’s like, understanding you’re not really going to get that far if the team doesn’t all want to succeed and get along with each other and you really need to like keep him human nature in mind when choosing how to do something well. Respect your team.
[0:05:49.1] DA: Like just understand the human process I guess. Making sure that you’re treating people as other fallible and real human beings?
[0:05:59.0] KT: Have you guys done XP? Like, at a client?
[0:06:02.0] WJ: Yeah, I think, you know, the degree of success is debatable but definitely done it.
[0:06:08.8] MN: Yeah, I think I have some level of, I mean, I know it’s either you're doing extreme programming or you’re not, that’s usually like the – whether you fall into or not but I feel like there was a client that I worked in that had all these things that you mentioned in the five values and the communication was tight, the thing we’re building was very simple, the feedback loop was there including pairing and one on ones.
I was able to have the courage to speak up whenever necessary and as well as have respect for my peers as well. I think all of those elements were there in this team and it’s great.
[0:06:45.1] DA: Yeah, I guess like that core element of the spirit of XP seems easier to capture than like the larger idea of it because I know there’s a lot of practices that are associated with XP as well and sometimes it seems like okay, well, we’re doing 2D the some of the time and not all the item and you know, if we’re not doing it all the time then we’re not really doing it.
[0:06:45.1] KT: Yeah, I mean, if you list out the values, no one’s going to say no to that. But XP is more prescriptive than the other AGILE frameworks and you get the practices, people do just immediately bristle. It is really hard.
I mean, you can see it like we work at an AGILE consultancy but very few of our clients do. Do XP. They mostly do some version of like they do a lot of like planning and process and SCRUM, that’s like not as courageous as XP.
Yeah, I think if you’re really committed to XP, it is the best way to do things, I really do believe in it. XP is hard because you don’t always know where you’re going, you don’t have an upfront design, can you think of a time that big upfront design blew up in your face?
[0:07:46.9] DA: Yeah, I’ve worked on various different clients, in life and one of the most challenging ones was a validated application where we had to have traceability and process driving everything. It’s basically the opposite of XP in every possible way, very waterfall.
You know, often, a desire to have a plan upfront, to mitigate the risk and do the safe thing. With really big projects like getting SAP online, there’s a very big upfront design, a very big plan and that plan often needs to change a lot and despite like people’s aspirations to mitigate risk, you still need to adapt to change.
Yeah, that was kind of like an interesting experience.
[0:08:35.6] KT: Because you don’t have the big upfront design abut you’re writing software from the start, you’re going to be doing the wrong thing and you have to be willing to like, refactor and do things all the time.
Do you guys love refactoring?
[0:08:45.6] WJ: Yes.
[0:08:45.9] DA: I actually really do.
[0:08:47.8] MN: Yeah. I think knowing that you can make something better is always good but I feel like knowing that you had to introduce bad practices to get things out and then having to refactor that is probably more painful.
[0:09:04.3] WJ: Yeah, I think that refactoring when there isn’t any time pressure and you’re just doing it to make the code more beautiful, that’s a wonderful experience. Refactoring because you were under the gone and cut a lot of corners and you kind of have to pay out some tech up, really have enough time to pay down your tech debt? That’s miserable.
[0:09:20.5] KT: I mean, that’s the beauty of XP, it’s like, it frees you to actually spend the time refactoring. Because you have to be able to do it all the time, the idea is, if you want to keep your code changeable, keep doing changing it. It’s like, if you let things get complicated then don’t touch things for a while, they calcify, they can rot, they stop making sense. –
[0:09:37.6] DA: The more afraid you are to change something, the more you probably should poke at it.
[0:09:41.3] KT: The more practice changing it, the better you’ll be at it.
It means, you actually also need, need to have like really unit test because when you’re rewriting everything, you might lose a functionality or like introduce bugs. So they need like every corner of the logic to be explored as much as possible with again, unit tests, doing test driven or test first development as much as possible.
Also because if you're building the right thing, you don’t have like a specific plan that’s been vetted than anyone before you start, you need someone to represent the interest of the client or customer like on site, make sure everything’s working.
[0:10:13.6] DA: Then it’s like also to engage them very frequently. Not to waste their presence but to do frequent dust checks and clarify assumptions as soon as they come up.
[0:10:24.5] KT: Yeah. If a person does stand in for the spec and also they can reach out to other stake holders to make sure you’re meeting their needs. It’s actually really important to have someone on the team who is not responsible for just building the thing, who is responsible for figuring out what should be built.
The testing and architectural process is also supported by a pair programming.
[0:10:41.9] DA: Yeah, we’ve definitely talked about programming quite a few times.
[0:10:45.8] MN: Love it, it’s great. Great way to get work done.
[0:10:50.1] KT: Why do you love it? Do you find it extreme?
[0:10:52.2] DA: No, I don’t think it’s extreme, I just think it’s like really – I find that when I pair program at a client like, it just, you end up writing nicer code. Which ends up in a pole request, less likely that there’s comments because everyone is working together to keep the code clean and two heads are always better than one when it comes to solving problems.
[0:11:17.7] DA: Yeah, I do feel like it is extreme in a way because like, it is – you keep each other focused, I mean, it’s like a more focused kind of work when you're doing it right.
[0:11:26.3] KT: It’s really good because it cuts down on bugs or like doing the wrong thing because you’ll have more knowledge about when it should be done, you could double check each other’s work.
Bugs are going to be way more expensive than people think they are and I think the only two things that are really extreme about it is pair programming all the time is exhausting, I think that’s – it takes a lot of energy.
[0:11:44.8] MN: Yeah, I feel like if you’re exhausted after eight hours of pairing, you’re doing it right. Because it should be really exhausting.
[0:11:52.7] KT: And, test driven development is extreme in a way because you have to imagine what you're going to build before building it and like work backwards and that be really hard for people to get used to.
[0:12:00.8] MN: Yeah, especially if you’ve never built it before and then trying to imagine the thing that’s never existed.
[0:12:06.5] DA: Oh I guess we’re always building something that’s never existed before otherwise it would just be open source.
[0:12:10.8] KT: Yeah you need this practices to support each other. I found a quote online by Matt Stephens at softwarereality.com it was like, they had a big article claiming that XP is the wrong approach. He says that XP is like a ring of poisonous snakes. Daisy chained together. All it takes is for one to lose and you’ve got a very angry poisonous snake heading your way.
[0:12:31.1] MN: Oh geez. Oh man.
[0:12:34.5] DA: I really like that quote. It makes it sound more extreme actually. It’s very dangerous but I am not dissuaded. It sounds cool.
[0:12:45.4] MN: But I do think like going with that quote, if you spend less effort or energy in any of the things that we discussed before then chances are it is just going to break apart, right?
Like you aren’t test driving things, you are not test driving any of your features and if you do that, if you introduce that kind of behavior then the whole thing falls apart because you don’t have any test, so then you are afraid to refactor, so then your code is not changeable and then you can’t implement change in your code.
Once you start, once that snake of not testing becomes lose then the whole thing breaks apart.
[0:13:30.0] KT: Yeah, if you don’t pair your own cohesion across your team, people are doing different things like going their own way, you have those big fights too late, feedback loops are too loose, it falls apart.
You don’t have an outside customer to validate what you are doing you are still going to build the wrong thing. You need to have a really energized team that loves each other.
You need not everything but you need most of the pieces to fit together to do XP well and it feels really good when you are doing it right.
[0:13:52.7] DA: So is there any opinions that run counter to this poisonous snake ring theory for XP?
[0:13:58.4] KT: Okay, so I think people are scared of XP practice because it’s hard. It’s doing it the right way which is doing it the hard way.
But the real reason to do it I think are XP builds trust like you really trust your team. You get more out of them, it builds morale. You treat them like adults. If you really do this right thing from the start your life is way easier because people are always complaining that, “Oh we did this terrible thing in the past and we weren’t sure about it at the time and we decided never to fix it. We just paid that -” You pay that cost in the long term.
So if you pay the cost of bad decisions once by fixing it then doing the right thing to start it just like the way to actually keep things cheap and simple and changeable, then you really have to work with human nature like you have to work with your team, understand how people react to things and not just like belittle them for acting the way the way humans do. Having imperfections that humans do.
[0:14:46.4] DA: Right or try to work the process around how humans actually behave to stuff than from doing things.
[0:14:52.4] KT: Yeah, you can’t force them with process to not be who they are. It is actually better to trust them and give them some freedom, which is definitely different from SCRUM that we do with most of our clients and for the most part, they are separate like SCRUM doesn’t prescribe as many practices as XP and you could do a lot of XP practices but the things that are different are how you trust your team to get work done. With SCRUM you have to promise everything ahead of time, you have lots of little deadlines but then deadlines will sometimes make you do the wrong thing. You’re going to make compromises.
[0:15:22.0] MN: Right.
[0:15:22.3] KT: Or not have time to refactor if there’s not enough slot time.
[0:15:25.8] MN: Right like the fact that you are estimating, “Oh, we plan to make X amount of points because that’s our average velocity,” definitely changes the idea that you will continue, that you will refactor because you already have an average velocity that you want to hit every week. So because of that, you are straying away from XP practices that allows you to refactor at – that allows you to refactor throughout the course of the application because you want to make it extensible and better without time limits.
[0:15:58.1] KT: So with XP you will probably look at the last two or three weeks of work that you have done and get an average of how fast you think you’re going. You can still retrospect, you can still improve your process but you don’t have to feel bad that you made a particular promise to do a thing and didn’t live up to it.
And XP is more compatible with Kanban compared to SCRUM but it has a different focus like you still really want to prevent defects with good practice with XP just like Kanban but Kanban is like that chunk of leg. It’s important to stop the presses, figure out what the choke points are and XP is a more holistic experience. It is only AGILE framework that really tries to do all of AGILE, all the principles and do it all at once together, comprehensive.
[0:16:39.8] DA: How would you handle producing an MVP with XP without a deadline or without any promise to deliver a certain time?
[0:16:50.9] KT: You can still know how much time you have and you can still make a burn up that shows how far you’ll think you’ll go in a certain amount of time but the way around that is really to figure out what your most important features are and just do those first and do to the dependencies of those also first.
So you just have to make some sense of your timeline but you are not going to do better than delivering the most important features as efficiently as possible even if you did make that plan.
[0:17:18.9] DA: So the mean way to do it is to discover what scope can be shed? Or what is nice to have versus a must have?
[0:17:26.6] KT: Yeah, like you are going to probably shed all the things that are low importance and some of the things that are medium importance and hopefully you can do all the things that are high importance.
But if you do more traditional approach, some of those high importance must have things and towards the end of the schedule because you’re scared of them, I mean XP tries to solve that problem by using that strategy of high risk, high important things are first.
So you can have clarity about like you can increase the clarity of how well you’re progressing by keeping lower risk smaller task later.
What are your favorite XP practices?
[0:18:00.1] WJ: Pair programming.
[0:18:01.2] MN: I think test driven development is a discipline that I’ve learned to appreciate and will enact whenever I can.
[0:18:11.6] DA: I really like sitting together in the same space. I don’t like Slack and I like email even less so if I can just holler at somebody then I am pretty happy.
[0:18:23.9] KT: That’s my favorite one, efficient communication because if you’re pairing you are communicating all the time. It is more obvious to someone else whether they should interrupt you or not based on whether you are in the zone because you’re with somebody else.
And the other thing I really enjoyed about it is like emergent design and emergent architecture. That’s hard to do if somebody is telling you what to do or giving you implementation details when they give you a task.
[0:18:45.8] DA: Yeah that’s true. Like stressing that it’s not frozen in time. This is not the final pattern that it will but this is a pattern that works right now and we’re happy with it.
[0:18:57.8] MN: One thing I do wish I saw more often is the customer involvement.
I think being there with the customer to tell you the plus and minuses of the new features that are coming out or that are currently released like always cool to have. But I know not every place has or spends time on that which is really dope to have that.
[0:19:21.7] WJ: I feel like it’s super rare.
[0:19:23.2] KT: Yeah that is the courage piece of XP. People get scared of showing it to somebody so they want to wait until it is ready. Really you would make better decisions if you just did that first. You would be told it wasn’t ready but you will also be told what direction to go.
[0:19:35.7] WJ: And it is also hard to get customers on site like that could be a logistical challenge depending on what customer you have.
[0:19:43.1] DA: Yeah. And I guess if you are more distributed you can’t get an immediate response from your stakeholder then you are forced to make assumptions and I can’t speak for most people but I often find that assumptions are things that will lead me astray and I’ll have to rework what I finally do get feedback from the people.
[0:20:06.1] WJ: And not all customers agree anyway so if you just have the one customer, you’re going to get a very biased perspective.
[0:20:12.6] DA: Right, if you make an assumption then you have to end up selling that assumption to the customer say, “Oh this is why it is really good like this is why we should change it please”.
[0:20:21.8] KT: Yeah, it takes a lot of buy in. It is not for everyone. You also have to hire and fire for people who have the skills like programs you actually want to pair all the time who can write the test first. Can you guys imagine scenarios where XP is a bad idea?
[0:20:34.9] DA: Maybe if you are sending a rocket into space.
[0:20:36.3] MN: I always think about that like you got to do it right once or like a satellite or something, right?
[0:20:44.1] KT: The stakes of failure are really high. For something like medical applications of things, you might want a more careful approach. If you are building an operating system things have to be really correct and carefully designed, XP is probably not the right approach and it can be hard on – this could be harder on teams of people have very different skill sets, it is a way to teach very quickly but that could also be exhausting and if some of your team members don’t feel empowered to speak.
And especially for minorities of women that could be a challenge, XP might be harder for them and I’ve heard people say, “You shouldn’t pair to XP if it’s just really, really easy.” I don’t actually agree with that because bugs are so expensive and it is easier to make bugs when you are doing something that is kind of tedious. I think the opposite might be true. Sometimes you need laser focus on something, it may be better to have one person focused on the problem if it’s really, really challenging and novel.
[0:21:29.5] WJ: I think that if nobody has any idea how to solve the problem and you are just going to be reading documentation, you need to split up for that. You don’t want to fight over the scroll bar.
[0:21:39.3] MN: Yeah.
[0:21:40.4] DA: Yeah then you’re just finding context switching all over the place and yeah, thrashing on what the thing is it you’re looking at.
[0:21:50.4] WJ: Yeah, once you have a general sense coming together and experimenting makes sense.
[0:21:55.5] DA: So where else can people find out about extreme programming? What are some good resources?
[0:22:01.4] KT: The guy who invented the idea is Kent Beck. He wrote Extreme Programming Explained. It is pretty concise and covers things really well. I also really like The Art of Agile that explains why it’s useful to a team and tells the story of how the transformation happens.
[0:22:19.1] DA: Yeah, I’ve read The Art of Agile. I have a copy, it’s pretty great. I like how they talk about the paths that you can take to getting to a more extreme place.
[0:22:30.5] WJ: Extreme!
[0:22:32.5] DA: Also they doesn’t really use the word extreme I guess too often in that book.
[0:22:37.2] KT: Yeah, it is not extreme, XP specific but they talk about AGILE and XP is the complete AGILE as far as I can tell.
[0:22:44.8] MN: Follow us now @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez. Thanks for listening to The Rabbit Hole.
Links and Resources:
