In today’s episode, we explore the crucial concept of courage in programming. It may be a far cry from slaying dragons, but courage in programming is not for the faint of heart. You need to be able to make bold decisions, such as discarding flawed code and initiating architectural changes, even if you and your team have spent weeks working on it. Using an anecdote from Kent Beck's XP Explained, we examine a team's bravery in recognizing a fundamental flaw and rebuilding their work. Tuning in you’ll learn about the importance of creating a safe space within teams for open communication about necessary changes, the challenges of maintaining team morale while prioritizing code quality, and the delicate balance of risks and benefits. Join us for an insightful discussion on the diverse aspects of courage in software development!
[0:00:01] MN: Hello, and welcome to The Rabbit Hole, the definitive developer's podcast, living large in New York. I'm your host, Michael Nunez. Today, we'll be talking about the XP value, courage, and mastering the art of brave programming.
In the last couple of episodes, we spoke about other XP values. We spoke about communication, simplicity, and feedback. With those three, the last value in the Extreme Programming Explained, version one is courage, where you have to take those first three and move forward with courage. I'll talk more about what does it mean to be courageous in programming, right? It's not like we're slaying dragons, or in armor, or anything like that. We're pushing keys all the time.
But there are some things that we can keep an eye out and be able to call out. A lot of the times that can be the bravest thing to do is to call out certain things. If I were to go on the internet right now and I were to define courage, I would say, according to Google, it's the ability to do something that frightens one, or strength in the face of pain, or grief. Let's click more just to get a sense of the meaning. Courage is the quality of mind, or spirit that enables a person to face difficult danger, pain without fear.
This can surface in many different ways in a tech team in which I will try to use some of the anecdotes that are provided in the XP Explained book written by Kent Beck. I'll read this block of text, just to talk about what was courageous about it and then dive more into that. Here's a story of courage and action. In the middle of iteration 8 of a 10-iteration engineering schedule of the first release of the first large XP project, the team discovered a fundamental flaw in the architecture. The functional test scores have been rising nicely, but then have flattened out far below where they needed to be. Fixing one defect calls another. The problem was an architectural flaw.
I guess, they dive into the idea that in looking at the current architecture, they realize, “Hey, we have to do a lot of rewriting. All that work that we've done from week 0 to week 8 needs to change, because we know what we know right now. It appears that the architecture is not extensible for us to be able to add new features without a lot of pain.” What the team did was they tried to change the implementation, which tore up all the tests that were written for the previous implementation. Then went back to the drawing board to write things out in TDD.
I'm going to be honest and say that there are times where I'm not as courageous as mentioned in the book, because one of the more courageous things that you can do is throw away code, right? If you're working on a piece of code and it's almost the end of the day and your tests aren't passing, you've done a lot of research and you spike something out, Kent Beck says, you should just command A and backspace, control A, backspace. Delete all that code and then try again tomorrow with a fresh brain.
I've tried to do that many a times. I think what I've done in the past is try to save that piece of work in a scratch file, or a text file that it's really hard to get to, so that I don't put all of my research energy into waste, because then I could just reference that, but I try really hard not to, to see if I further understand the implementation, or the spike that I did. But it takes a lot of courage, right? You have to be comfortable with communicating with your product manager, with your product manager, with your team to talk about these implementation changes.
I know that a lot of the times, a developer will use tech debt as a thing to justify stuff that needs to change and I'm okay with that. I think we do have an episode of stop using the word tech debt. That sends product managers and project managers in a frenzy, but this particular call out in the reading definitely is not a tech debt. It's rework that needs to get done and you have to rip it apart to then put it together even better, so that you can extend that in the future.
It's difficult to look at something that you worked on for the past eight iterations, right? Let's say, if they're two weeks, that's 16 weeks of something that you were building to go and say, “Man, we built this incorrectly and we have to go back and do it.” There is the idea of sunk cost fallacy, right? We spent 16 weeks working on this. Why do we need to throw it out? We should just extend it to the best of our ability, even if it's difficult to deal with. Versus, hey, we promised that we were going to deliver this iteration, and we need to do this change. We're going to do it.
It takes a lot of risk in admitting your mistake, a lot of risk taking and believing that the change that needs to be implemented will affect the code positively and the architecture, so that teams beyond you and future you will thank you for those architectural changes that were necessary. It requires feedback and seeing that, hey, I'm getting a lot of failing tests. This is getting really difficult for us to extend. We need to do something about it.
Again, going back to the simplicity value, the ability to look at something, okay, we built this thing. It's gotten quite large. Hard to extend. What is the simplest thing we can do? Always make sure you fall back to that. You don't want to build and re-architect something and then make it even more complicated, because what if it doesn't work in the end, then you spend a lot more time trying to change it to then have to go back and change it again. In order to do this, one might need to feel psychologically safe to call these things out, right? If you're on a team that's just crunching all the time and everyone's pressured to get this deliverable done, you may not feel safe to mention that this needs to change for the better, but requires a lot of time and energy to rebuild.
If you don't feel psychologically safe to do that, then you're probably not going to speak up. That's definitely very, very important in the realm of courage as of value. I've been in teams before where I've worked on a particular feature, a particular application and realized like, “Oh, this is actually going to be a little bit more difficult than we anticipated.” But sometimes you are put in a position. I think the term is not by your hands, but on your lap and you just got to get up and run, literally, have to do a sprint it may feel like, just to ensure that the things that you say you can do and then you will achieve the goals of the sprint, or the iteration and what not.
It's hard, because you may think that it is difficult to go back and make those changes and that's going to affect a lot of things. I think, one of the things that I understand is morale can play a huge role in your team having that courage to step up and take that risk. That's always on my mind when it comes to rallying up the team together to want to make this change as well and to ensure that we don't compromise code quality just to get these stories out of the way. Again, it's difficult. I understand that not everyone may feel they have the ability to step up, or take courage to call things out. I think it starts with you feeling comfortable in your team to be able to then have these callouts.
I always find it interesting when in teams that I've been on, if we're now recently gotten feedback from someone about a particular design, or architecture and people who have been pleasantly surprised that I take it positively. I think that for me, I need to make sure that they feel comfortable enough to tell me those things, so that I can then apply it and make those changes if necessary.
There's a lot of onus on oneself to make sure, “Hey, I can admit mistakes and I'm willing to take the criticism, or feedback to be able to do better next time.” It's courage in both directions, and you being able to share that there is a particular issue, or something that requires change and you yourself, whenever that gets brought up to you in some way, shape, or form, that you have the ability to analyze it and then try to figure out best ways to address those changes.
That's courage and that is the four XP values. I think that with these four, I'd love to be able to explore these values more, maybe come up with stories specifically in these values. Look forward to hearing what are some ways that courage affects you and your team in the product that you're building, whatever it is that you're building.
[END OF EPISODE]
[0:09:18] MN: Follow us now on Twitter @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. 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.
[END]
Episode 310: XP Values - Communication
Episode 311: XP Values - Simplicity
