As we continue to learn from the XP book, Extreme Programming Explained, today we discuss what it means for software systems to go sour and how to prevent this from happening. We talk about what happens when the cost of making changes or defects rises so much that the system must be replaced and how XP creates and maintains a comprehensive suite of tests to counteract this risk. Tune in to learn more about how pair programming can help prevent the system from going sour, what to do when you are writing legacy code, the types of tests you should write and focus on, and so much more!
Key Points From This Episode:
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez, and today, we’ll be talking about when the application is no longer juicy. Prevent your systems from going sour.
[INTERVIEW]
[0:00:16.9] MN: Yeah. So I mean, I’m going to be honest, I did not come up with the title entirely on my own. This is me trying to incorporate ChatGPT into my life in which, yeah, I think it’s been an enhancement more than a replacement, I hope! But then I had to you know, come up with something better than that was given to me.
I’m going to talk about what it means to be, or rather, what it means for your systems to go sour using the XP book, Extreme Programming Explained as we’re still going through that first chapter with the list of risks and how do we aim to solve it using XP.
Let’s begin, I’ll start by reading the bullet point and the example of the risk that talks about systems going sour.
So here’s a risk for a system going sour, “The software is successfully put into production but after a couple of years, the cost of making changes or the defect rises so much that the system must be replaced."
[0:01:20.1] I think I’ve heard a phrase, something along the lines of, you know, as soon as you’re writing the code that you’re writing, it’s becoming legacy code, which is kind of crazy to think about because you – one does not ever think that that is the case but over time, there could be some you know, patterns that exist within the system that makes it very, very, very difficult to update.
I think that there are ways to prevent that from happening and spoiler alert, it’s a test when you make sure you have all your bases covered with the different types of tests that exist. That is definitely one way to address the system from going sour because you have an idea on you know, how the application is built, what are some things that you may need to do to extend it, and have a clear understanding of how to extend it.
The way XP addresses that particular risk according to the book, “XP creates and maintains a comprehensive suite of tests which are run and rerun after every change several times a day to ensure a quality baseline. XP always keeps the system in prime condition. Cruft is not allowed to accumulate.”
I don’t know if I mentioned this before but think this is one of the really interesting things that differentiates XP to other Agile methodologies because Agile or you have your Scrum or your Lean or your Kanban, you know it talks about the day-to-day stuff. You have the day to stand up, you have your retro every sprint, you have iteration planning meetings, your refinement meetings, that kind of stuff.
[0:03:03.7] Once all those meetings are done, the developer has their nine-to-five, if you want to call it, that doing and building the features that are being asked, during those other meetings, but then it’s just like left to your own device, right? There’s no enforcement or prescription of writing your test cases and XP ensures that that is something that you're doing constantly.
You know, you are always going to have to write green refractor, every given unit test. You make sure that when it comes time to write that integration test from one particular class that communicates to another. You make sure that that test exists and then you dive down deeper and deeper into the changes that you need to make.
And then many different tools that exist depending on the language that you’re on, I’d like to say that you know right now, I’m writing some Java code, which is great. I think I had been telling people I enjoy it because it is the evil that I know or the insanity that I’m familiar with, which I think is different than Stockholm syndrome because the Stockholm implies that, “Oh, this is hard but I love it and it’s great and roses” and, no-no-no. I know, Java can be a little verbose for folks and myself included.
[0:04:23.2] But it’s kind of like the rhythm of you know, having to write the test in J unit and making that test pass, what is the Java way of writing that thing and it just make sure that my code is up to snuff if you will.
I think one of the things that this particular bullet doesn’t call out that I think should be called out, it’s in one of the other bullets actually but I think pair programming definitely helps the system from going sour too because you have a person who is invested in the work that you’re doing together as supposed to waiting for a PR to happen and then Bobby could write a couple of comments. You can address them but then Bobby doesn’t have the opportunity to look at it again for another two hours because Bobby’s busy doing something else, that kind of stuff. But when you have a pair, you’re getting that feedback in real time. Less likely to introduce cruft because the other person is there sitting alongside you and building the given feature.
But I think that system going sour is definitely something that we as developers experience from time to time. You know if you ever feel like you are writing legacy code from the start, see what you can do to prevent that, right?
[0:05:41.9] Ensure that you have a unit test that’s written before you go and write implementation code. You know, one of the antipatterns of TDD is you write the implementation first and you go and you write the code again which can lead to you know, feeling like you’re writing the code twice and you kind of are.
So try not to do that and I think I mentioned before, so this is probably a good opportunity to talk about the test impairment. You know, if you have a triangle where the base of the triangle is the fastest way of running your test and you’ll have a lot more of those kind of tests in the base. That will be a unit test and as a triangle, I am going to use an equilateral triangle, as the triangle goes up in its shape, the middle section will be your integration test, and then at the very top you have your end-to-end test, right? So you’re not going to write more end-to-end test than you are a unit test, right?
You want to make sure the unit-test test and every little thing so that if there is a failure, the unit test can call out exactly where the failure happened and then you can address it and you have your integration test to make sure that they can, the components will communicate with each other, which is great.
[0:06:52.9] And then your end-to-end test is like testing the whole system may be in real-time, ensuring that things are working as expected. And then that’s one of the many ways to prevent inter systems from going sour.
I would say, you know if you had to do what I call the TDD waltz, remember that. You want red, you want green, you want refactor. You could do red, green, commit, refactor, that’s another way. I don’t know the four steps of that’s Dominican dance styling of Bachata, right? That’s four steps or you can do, I’m not a hundred percent sure, probably a Salsa or somewhere in there. I’m not a hundred percent sure of Salsa. I can’t dance Salsa, I’m sorry but either way, you are doing that red, green, refactor, red, green, commit, refactor, you know, cycling through your code, making sure it’s up to snuff as I would say.
Yeah, so if you are out there writing code and you feel like you’re writing a legacy code, take a step back and figure out how you can prevent yourself from writing that. I’m sure future you will thank you for taking that time.
[END OF INTERVIEW]
[0:07:53.2] 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 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.
[END]
Links and Resources:
Extreme Programming Explained: Embrace Change
