In this episode, we delve into the world of feedback in software development. We explore how feedback, in the context of Extreme Programming (XP) values, goes beyond traditional human communication. We uncover the various sources of feedback, from pair programming to CI/CD pipelines, and how it plays a pivotal role in improving code quality and project management. Discover the importance of simplicity and clear communication for effective feedback, how user feedback is crucial for assessing the success of software, and much more. Tune in and join us as we unpack the multifaceted nature of feedback in the software development process!
[INTRODUCTION]
[0:00:02] MN: Hello and welcome to The Rabbit Hole, the definitive developers’ podcast. Living large in New York. I'm your host, Michael Nunez. Today, we'll be talking about the third XP value, feedback, from both humans and non-humans alike. Every time I read this chapter and I go over the values of XP, I always have to remind myself that feedback in this context is different than feedback that first comes into mind. I want to talk about separating the two and see how we can get better at using feedback to our advantage.
If you're listening to this and my voice sounds a little weird, it is because I am not feeling too well. It's getting to that season where everyone is sick. But I'm getting over whatever this is, which is great. I hope everyone is out there healthy and living their best lives. Yeah, so we're going to talk about feedback today. Every time I read this, again, I mentioned before, I think of feedback of like, giving someone a coaching suggestion, or some form of appreciation, or something critical that a person may need to work on, or this piece of code base and whatnot.
I think that if you heard of feedback and thought of that context, stuff like, “Oh, I need to give and receive feedback to my peers, so that we can get better as we move forward in this project,” that is good. You should keep doing that. But the feedback in the particular book, in XP Explained, talks about feedback that the different mechanisms and tools that we use on a day-to-day is trying to give us information. We can cut it down from the second all the way up to the inception of the project, or the iteration of the project.
I wanted to get a visual for me, but I’ll do my best to explain what this visual is, and we're going to cut down right to the seconds. Every second in XP, you’re pair programming with another developer, you are writing tests and ensuring that they're passing, or if they're failing that you address said specs. The idea of the machine telling you, “Hey, you did this thing. You made this change. You should go ahead and fix it.” Or, “Hey, we have this test. You need to make sure that it's doing what you want it to do,” is a good way of getting feedback. You get that by the seconds, by the minutes and even going dive in deeper, every second you're talking to your pair, you're talking about how to implement this one thing.
[0:02:38]
It's been that feedback, one's another. It’s not like, you're giving that person, “Hey, you need to try and optimize this function faster,” whatever, right? It's just back and forth. You send feedback to someone, someone sends feedback to you, and continuing on that. On a day-to-day, it has to do with where the story is and how far have you gotten. That feedback that comes in the form of — during stand-up, like it's a good indicator of a pulse on the story that you and your pair were working on.
Stand-up comes and goes, happens once a day. Very rarely, you have a stand-up and a stand-down, maybe, but that happens on a day-to-day basis. Every time you're ready to deploy, you have your CI/CD pipeline. That is also valuable feedback that you're getting from a system, telling you the health of your application. Always think of feedback or information that can be utilized to better yourself, or the team, not specifically things that you do on a day-to-day, but the status of the application.
Every two weeks, or every week, depending on your sprint timeline, that feedback is good for the product manager and the project manager and folks who are looking at the Jira board and wondering, “Are we going to hit this week's goal, or this sprints goal, or are we going to complete this story? If we complete this story, how do we prioritize to ensure that we get this out before the other team who needs this piece of work?” All that feedback, all that conversation is more on a higher level of how you want to improve the project.
The best way, it is very interestingly enough, as we go through the values here, there will be times where some values will overlap with the others. We spoke about communication and simplicity, and feedback requires that the communication is there, that you have a pulse, whether it's a failing test that you can find that out immediately, or the CI/CD pipeline breaks for whatever reason, you can find out exactly where it broke. What's the status of the particular story? Communication is important.
The best way to have that really informative piece of feedback is to make it as simple as possible. “Hey, this test failed here.” You have a clear message on what is the name of the test that caused this code change to make that test fail. When we go to the CI/CD pipeline, we're looking at something and know exactly where it is, as opposed to just council logs that exist and we may not be able to trace it in some way, shape, or form.
[0:05:05]
This feedback definitely leans in on both simplicity and communication, which we have discussed before. But just know that feedback isn't always a human telling you tips and tricks, or things that you've done successfully, things that you need to work on.
Lastly, feedback comes from the user, right? When you go and you deploy this piece of code and the user uses it, the ability to know whether it is successful or not is important, is valuable feedback to know whether the features that you're building are right for your users. You can have different user analytics to determine, “Hey, we added this new feature, how many people actually use it, who presses the button and how often,” and whatnot. Valuable, valuable feedback in knowing the product that you're currently building right now.
I hope that you use this feedback to look at your surroundings and figure out what is trying to get your attention or something that's giving you feedback, you get a chance to look around and see, is this piece of information is something that I could use for the future? Also, always remember, feedback can be both done by a human helping you be your best self, or by non-humans that are giving you pieces of information for you to better the system.
[END OF EPISODE]
[0:06: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]
