If you find yourself listening to this, and you can relate to having some waste problems in your company, it’s going to be one of seven things. We have called them the seven wastes of software development. To find out more about those, please go back and listen to Episode 82. Today, however, you’ll find out how to solve for each of the seven wastes; more specifically, you’ll learn about creating a lean software toolkit. Task switching is something that you may experience often and there are some solutions that are introduced for both XP and the Trunk Based Development world, and your hosts discuss several of these solution options throughout today’s show. They touch on introducing defects, tools you can use to catch these defects, extra processing, and the values of extreme programming, so tune in as they tackle solution options for the seven wastes of software development!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 192. Creating a Lean Software Toolkit
[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. Our co-host to day.
[0:00:09.4] DA: Dave Anderson.
[0:00:10.6] MN: Today, we’ll be talking about creating a lean software toolkit.
[0:00:15.3] DA: Yeah, like sometimes you got a problem that you're facing and you’re not quite sure what to do but a lot of times, there’s already a tool out there as a software developer that people have thought about that you can steal that you just got to know how to label a problem and think about it.
[0:00:33.9] MN: We’re going to talk about, I’m pretty sure, if you’re listening to this and you got problems in the company, it’s going to be one of these seven things. We have called them the seven waste of software development. We didn’t create this. I didn’t create this at all.
I mean, but we do have an episode on it and we touch on it a little bit and I think we got to dive in more specifically on how you solve for each of the seven wastes.
[0:00:59.0] DA: Yeah, we talked about this back in episode 82 and it was one of my favorite episodes like one of our colleagues gave a talk on the seven wastes of software development, it sounds so intense.
You can go back and check it about to hear a little bit more about the specifics of each of those but the other day I was watching a talk from Kent Beck who made Extreme Programming and he had a realization at some point that all of the things that he collected together in his book, Extreme Programming and the people he was working with to develop that way of working, which you can hear about more in episode number 65.
It was actually just Lean all along. That was a realization for him at some point as he was evangelizing and working this way.
[0:01:56.6] MN: He thought that he had a thing with Extreme Programming but in reality, it was just Lean all along, it’s like Scooby Doo when they captured the villain and they grab it and it’s like man, “It’s you,” and then they pull out the mask and like, “It’s Lean, oh snap”
[0:02:14.4] DA: “It was Mary Poppindink under the hood the whole time, oh my god”
[0:02:19.7] MN: Exactly.
[0:02:20.1] DA: Same thing with Trunk Based Development, which we talked about in episode 30, Trunk Based Development is all about making small commits and sharing it with your teammates as quickly as possible and always having a build that’s ready to go, straight to production. What do you know, that’s also Lean.
People have these great toolkits of ways of approaching problems or smoothing over different challenges that you might have in your team. It’s kind of like an interesting exercise to think about a problem you have, what kind of Lean waste is that for software development?
Then, what kind of solutions might make that a little better. If there are solutions that already exist why don’t we steal them? It does it matter if they’re labeled XP or labeled Trunk Based Development or where they’re coming from, let’s just take them all and put them in our toolkit and take them out when we see a problem that we need to address.
[0:03:27.2] MN: Right, it’s like Batman and his utility belt, right? Depending on the villain he may fight, that utility belt’s going to be a little different. You may have your shark repellant, sometimes if you’re going out in the water.
[0:03:39.0] DA: Totally, yeah.
[0:03:41.2] MN: You switch it up if you’re not going to be by the sea, you know?
[0:03:45.3] DA: And not always having the shark repellant handy?
[0:03:48.8] MN: I mean, maybe. You might need the shark repellant, I don’t know.
[0:03:51.1] DA: Does Batman having problem with sharks?
[0:03:55.0] MN: Large mod is by the water, yeah, large mod is by the water, I always got to have shark repellant on deck. That and coyotes, I didn’t know I had to fight off coyotes. When you're fighting sharks and then coyotes, you may be exhausted from the different tools that you need to do.
Very similar in your workplace. Your team may be responsible for a lot of different parts of the code base or of the application that is needed. Task switching is something that you may experience often and there are some solutions that are introduced for both, for both XP and in the Trunk Based Development world and we’ll dive into that.
[0:04:32.2] DA: Trunk Based Development is a proponent of like having really small commits that are always ready to be released and you're kind of ready to share that with the team in short order. You're not like working on a branch for two weeks. If you're doing that then you know that there’s some other big problem there but by doing small thin vertical slices, you’re very focused on getting that out and not being distracted by other things.
[0:05:06.8] MN: Right. You keep those commits small, you’re able to finish that task and then move on to the next one as supposed to context switching back and forth, eliminates that all together. Think of a better way to address some of the task switching, would be to do that with a pair, XP often evangelizes pair programming, which is something that you work with an individual to do so that two individuals are working on a particular problem.
They finish that fast and then they move on, rather than constantly task switching between the two developers on a particular feature.
[0:05:40.8] DA: Right, or the developers can like help people stay on the task at hand and like stay focused and get it done. I know a problem that I’ve seen a lot is maybe when you’re working on that long-lived story, there is like a lot of partially done things in there.
You’ve kind of started a couple of different threads and you’re going out and hitting some barriers. That Trunk Based Development like thin vertical slice philosophy and always being release ready helps frame things so that you have less partially done work.
[0:06:23.5] MN: Right. Dave, you touched on the idea of just having small releases would also help with the partially done work because you ensure that if you had a commit or a feature that was long-lived for two or three weeks, who is to say that that commit is old, it doesn’t really merge well with all the things that have been pushed in to master and not getting that work out as fast as possible, ultimately ends up with the work not being done, which you then have to context switch.
Those two are hand in hand and the solutions of those is to make those small commits, release it to the users as fast as possible.
[0:06:57.8] DA: Right, you know, if the work is only partially done, then is it really useable to the user? You have to think about how you're structuring it so that if you're doing incremental slices and incremental releases that it’s always in a state that’s useable to people.
[0:07:18.3] MN: I know that when I myself write software, there’s never any defects, ever. I’m that good guys, trust me. If anyone ever says that you know that something’s up and they’re fishy — when the average person, unless you’re a ten X a hundred X, a thousand X, you aren’t introducing defects, you know, as a normal individual, it happens to the best of us and we need to figure out ways to patch any other defects as best of our ability, to ensure that we’re delivering proper software to our users as much as possible.
[0:07:53.5] DA: When you have a defect and you release it out into the world, then it’s going to cause you more pain trying to sift through it, like dealing with the task switching of like, “Okay, I’m writing new software” to “I’m trying to find this weird time bug” is a big overhead. Luckily, there are tools out there that can help optimize to catch defects.
[0:08:21.0] MN: Right, one of them, I think we’ve mentioned before in time, a Test Driven Development is your friend. You definitely want to test drive the code as much as possible and make sure that it’s 100% code coverage to the best of your ability and that’s really difficult and sometimes I feel like if I’ve ever seen 100% it’s like, “Really? You’re testing configurations, is t hat even possible? You're doing something weird.”
You want to keep that numbers high as possible. Make sure that you have everything covered. It doesn’t mean that even if you had your code covered that you’re never going to have defects. These things happen. One thing to do is that when you find a defect, write a new test case that covers the defect, that make sure you implement that one. You ensure that defect, wouldn’t it happen again.
[0:09:05.8] DA: Yeah, totally and if we look at Trunk Base Development how that helps us reduce defects, we’re always trying to get code back into our master branch as quickly as possible only a day or two. Our commits are going to be pretty small hopefully, the CI or continuous integration is going to be checking that on build and when we merge it, ideally we’re going to be rolling back right away because other people going to be putting their work in there as well and you know, we’re going to be catching that before it goes out to production.
[0:09:40.8] MN: Right and get tools to kind of help you identify where the bug exists and whatever command. Git-bisect is my personal favorite. If you every get a chance to use that tool, please do so. It will make you a lot – it’s a lot easier type than if I wouldn’t have it.
[0:09:53.0] DA: Then like the opposite scenario of that I guess is like, you have written a branch and it’s living for a week or two and there are bugs in that branch and those bugs have not been found and you just keep on working on it and working on it and other people are changing in the code. You have to re-base it and maybe that introduces more bugs and then by the time you actually have to get it reviewed, it takes more time to review it because you don’t remember what you’re were doing when those other bugs are introduced or like that other thing wasn’t may have been a problem trying to minimize the defects and get it out there quickly.
[0:10:36.1] MN: Yeah and a good CI tooling would definitely help you in that regard, making sure you could role that back.
[0:10:43.0] DA: What about extra processing? This is kind of an esoteric-sounding waste, which I guess means that you’re just doing too many things. You are over-processed for the work that you’ve done like you could have done less.
[0:11:02.1] MN: Some people may think that the work is necessary, you know the users want these extra features or we need to add these new software tools that are amazing that will make our lives so much easier without actually identifying whether it actually would or not. I think one of the things I want to point out in XP that they have the values of extreme programming and I’ll go down the list real quick. It’s communication, simplicity, feedback and courage and then they added respect later on in life.
I think when the tool to mitigate extra processing is communicating with your teammates as to whether the extra processes needed in the first place by identifying what is MVP for your project and then identifying that and the way you talk to and communicate with your team is very important. Ensure you have mutual respect for each other like you’re not hurting anyone’s feelings when you are talking about what are the things you need to be cut out of scope or not.
The courage to speak up, to say, “Hey, this might be extra stuff. We can do that in the next sprint. We need to get this out released to our users right now.” The extra processing could cause us to have a longer living branch, which then we will have that out to our users. It’s like a whole lot of things that I think that the values of XP actually is a tool that we can use to mitigate this extra processing.
[0:12:19.5] DA: One of the big things I like that leads to extra processing is also too much planning. If you are over-planning or over-documenting, overthinking what it might be, when you actually go to make the change. You might need to do more work. Your understanding will be different like XP tries to minimize those kinds of meetings or have very focused meetings with a minimal planning game and having the customer close at hand to answer any questions about what they might want.
Whereas Trunk Based Development really encourages quick code review. If you’re doing code review, you should try to reduce the amount of time that tasks are being left in code review so that it can get back into master and shared with people. You know, avoiding merge conflicts is another way of extra processing. If you have a merge conflict, then that’s just pointless work.
A lot of times frustrating. Sometimes, you can’t avoid it and it’s needed but other times, if the code is constantly changing under your feet and you’re just rebasing and merge conflicting and whatever then that’s a sign. It’s a smell that there’s something amiss.
[0:13:44.2] MN: Right, try to keep all of those meetings and documentation as low as possible so that your engineers and your team can continue chugging along getting those features done — as fast as possible.
[0:13:55.6] DA: Yeah, chug it.
[0:13:56.7] MN: In the organization you’re working for there could be potentially be some kind of delay or your users are waiting for a feature. They may not be even knowing that they’re waiting for a feature but you have been delayed in releasing the feature for whatever reason is a problem that can often happen at the workplace and I think that XP tries to solve that problem by ensuring that we have those small releases I think is so important, I think we mentioned before.
[0:14:22.9] DA: That’s true.
[0:14:23.5] MN: When you have small releases, then you’re able to get that out the door much faster because things are smaller, you have less things to review. You have less things to get that checkmark approved before it gets sent out and with a good CI CD-process, you get out the door very fast and very less likely to get delays.
[0:14:42.6] DA: Yeah and also, you know the customer is waiting less time to interact with that and give you feedback on what the next story should be. You know, if you wait for everything to be perfect before putting it out there then maybe you’ve built completely the wrong thing.
[0:15:00.3] MN: Right, I think the phrase I’ve heard before is “perfect is the enemy of good.”
[0:15:05.0] DA: Yes.
[0:15:05.5] MN: The idea that you try to build this thing that’s perfect, so perfect but then when it’s released, it may not even be a good thing that the user may want in the first place. If you just get that delivered out, keep it very small, small delay, no waiting, you’ll be able to slowly incrementally build the thing that the users want with the feedback given by the user to the organization so they continue working on those stories.
[0:15:28.4] DA: Yeah, then there are two other things other solutions that XP has related to waiting. I think really powerful concepts like having the customer on the team like a product manager or something like that so that you don’t have to send out an email to get an answer to a question like that person is ready to come and have a discussion with you and figure out what the best course of action is going to be for whatever conundrum you’re facing.
[0:16:00.8] MN: When you have that system in place, you’ll ensure those people in place. The delays will be a lot less and the users will get those features as fast as possible. We went through a lot of the seven waste in this with the tools that we used for XP and Trunk Based Development. What I’m really curious is if there are other systematic tools out there that are available that we may have overlooked in these seven waste of software development.
I’d love to hear what is out there. Please, you know, if there are other tools that exists, we should definitely know about it and definitely reach out to us. You could tweet at us @radiofreerabbit for sure and I will try and incorporate that into our current workflow and maybe an episode later in the future.
[0:16:51.1] DA: Yeah or let us know what kind of problem you have, we can label it. We’ll tell you what waste is being let out into the world.
[0:16:58.4] MN: Yeah, we could try and help you identify what that waste is and then what tools we may have in mind. This will be a great exercise. I love to do that. This is free consulting tips from me to y’all. Hit us up at Radio Free Rabbit, go check it out and we hope that this toolkit, you got your utility belt now. Now, you got your sharp repellant and your –
[0:17:19.6] DA: Coyote spray I guess.
[0:17:21.4] MN: Coyote hazing, right? You got to make sure you have those stuff on deck. We hope that we help solve any and all of your problems including wild life and software development.
[END OF INTERVIEW]
[0:17:33.8] 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 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:
