In this episode of The Rabbit Hole we are unpacking the The Seven Wastes of Software Development! Dave and Michael break down the seven points as they appear in the book Implementing Lean Software Development by Mary and Tom Poppendieck and chat about their experience and thoughts on each. This lean approach actually has its roots in the manufacturing sector and apparently originated on the Toyota assembly lines in Japan in order to optimize less resources and compete with the bigger American companies. After going through each of the seven wastes we chat about which of them we personally like to tackle and compare notes. For all this and more, come with us, down The Rabbit Hole!
Key Points From This Episode:
Transcript for Episode 245. Seven Wastes of Software Development
[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:11.3] MN: Today, we’ll talk about the seven wastes of software development. I imagine, you know, as software developers and engineers, we’re going through the constant cycle of pushing new features out but sometimes those things can be wasteful.
[0:00:28.2] DA: Yeah, it’s like the seven deadly sins. It’s pretty catchy.
[0:00:35.8] MN: We don’t, the rule is we don’t’ want to do these things and we want to minimize these things because they’re going to happen, there’s no denying. The following things we will say the seven steps or the seven wastes, will be done and we have to figure out how to not do them as much.
[0:00:52.3] DA: Our good friend Michael Silvy, like, who, I guess unfortunately did – wasn’t able to make it through on the podcast but –
[0:00:59.8] MN: He’s going to jump on soon, don’t worry.
[0:01:01.3] DA: Yeah, definitely.
[0:01:02.2] MN: Silvy, a friend of the show, he’s going to come through, I got it, don’t worry about it.
[0:01:08.0] DA: Our good friend Michael Silvy, friend of the show, coming on the podcast soon, he spoke about this concept at a big meeting that we had and it really resonated with me, I think it’s a really good way to think about like, what kind of problems can arise when you’re making software and I think it’s pretty interesting origin too. Because it actually has its roots in lean manufacturing.
[0:01:35.6] MN: Okay.
[0:01:37.2] DA: This is actually, originally was thought up in Japan.
[0:01:42.4] MN: Okay.
[0:01:43.0] DA: As part of the Toyota production system.
[0:01:45.7] MN: in building cars and vehicles and Toyota is where they thought of ways to reduce some of the waste that was happening in the production line?
[0:01:55.5] DA: Yeah. I think the origin of that is that like, Toyota really couldn’t reach the scale of the really big car manufacturers that are in the US, so because they couldn’t like work bigger, they had to just be really good at whatever work they were doing. To find the ways to eliminate it on the line. Anyone who is in a factory, who saw waste would just you know, blow a whistle, they all like figure out how to fix it.
[0:02:23.0] MN: Nice, I mean, I imagine that process is now like Toyota’s very successful in manufacturing cars.
[0:02:31.2] DA: Yeah, pretty dang good. These folks Mary and Tom, I can’t pronounce their last name.
[0:02:38.5] MN: Poppendieck, is that correct?
[0:02:47.7] DA: Yup, you can google it.
[0:02:49.7] MN: Yeah, check it out. They were responsible for implementing this process and identifying the seven wastes.
[0:02:56.3] DA: Yeah, they used to work in like manufacturing and then they moved to software engineering and kind of noticed a lot of the same problems.
[0:03:06.1] MN: Interesting.
[0:03:07.2] DA: They wrote a book, Implementing Lean Software Development.
[0:03:10.7] MN: Dope, all right, we got some history, some background on the seven wastes, let’s just jump right in to the first one, we have online. ‘Partially done work’. What does that mean to you, Dave? What do you think about that?
[0:03:25.6] DA: Partially done work. I guess that means like anything that’s not like giving you value. Giving the customer value.
[0:03:32.7] MN: Okay.
[0:03:33.2] DA: If it’s not useful to them then it’s like not done.
[0:03:37.3] MN: Right. Worked at even – I imagine this is different than like if the user doesn’t see it but it’s useful to them then obviously it’s fully done because it helps the user experience but like, things you build that don’t think about YAGNI, right? That’s like a problem, if you ain’t going to need it, why build it, it’s partially done work, don’t do it.
[0:03:58.1] DA: Right, or like, if you start building on something you never finish it then yeah. Or like partially done work could be like your PR that’s like in code review for two weeks, it’s partially done and you know, maybe you have to come back to it later and it’s hard or you know, maybe you do actually get that PR done and it’s not deployed direction, it’s still partially done.
[0:04:24.5] MN: Right.
[0:04:25.7] DA: Or if it gets to production, it’s behind the feature flag.
[0:04:27.1] MN: Then you got to do partial. Yeah.
[0:04:30.2] DA: It’s not in front of the people.
[0:04:31.5] MN: Right. I think like, that can also lead to code that isn’t synchronized, partially done like documentation if it’s not fully fleshed out, how can people learn about this new feature, that could be really difficult.
[0:04:46.1] DA: Right, yeah, if someone has a 9DF or house, something should be implemented and you only do it half way. You know, it’s not the full feature, then it could still change.
[0:04:59.1] MN: I think last but not least in partially done work is trying to – even if you built out the feature and that’s work that has been fully done, it’s partially done if it isn’t test covered is what I believe.
[0:05:14.6] DA: Yeah.
[0:05:15.4] MN: You should have some form of test coverage on all of the things that you built.
[0:05:19.0] DA: Step one.
[0:05:20.8] MN: Right, yeah, exactly. We got a TDD episode, you can check it out for sure.
[0:05:25.2] DA: Yeah, the next one is extra processes.
[0:05:29.7] MN: Yeah, I’ve seen this in a couple of places where like, documentation is very – documentation is necessary to like move forward with the feature. Having people like sit down and think about documenting the code that needs to get done rather than starting on the code that has to get done for the user can be a waste that is often not seen by the organization because they feel that the documentation is of the utmost importance.
[0:06:00.5] DA: Right. Then you know, that can lead to a lot of thrashing, if you change the code, you got to go back and change the document and keep everything in sync. Yeah, that’s definitely an example of extra processes.
I mean, there’s a lot of process that’s in software development like releasing code to production should be a controlled thing. There’s like the right amount of process but then it’s also really easy to put too many guard rails in place and make it extra onerous. A big burden to do what you need to do and get that code out there in front of the user.
[0:06:38.3] MN: Right.
[0:06:39.2] DA: Yeah, the challenge is getting approval for a change or like, getting a proof from the customer or whatever. If there’s a lot of friction, there then that causes problems.
[0:06:51.8] MN: Yeah, I think like if you – I mean, it’s always good to have like certain processes but you should definitely identify which ones can be considered wasteful and remove them from the standard in your organization.
I think one that I’ve seen, the third one we will discuss in that I’ve seen often can be extra features, you got to have all the clicks and all the sounds and all the surprise noises, everywhere in the feature that you’re going to build and a lot of individuals may not think of what is MVP and how do we reduce some of the scope to get this out to the users as fast as possible.
[0:07:29.1] DA: Yeah. Are you going to need it?
[0:07:30.8] MN: You ain’t going to need it, then don’t do it.
[0:07:34.6] DA: Yeah, this kind of takes a lot of forms to like, you could have extra features from the product side where they’re like, this is something that I really want to build but they haven’t like really vetted this idea with the customers or it should be using it. If it’s just something that the product team thinks is important and then you actually go to build it and it’s not actually used by the users then that’s just extra code that is there and that you need to maintain.
If you know are making other changes on a system, it could make it harder.
[0:08:11.6] MN: Right. I think the inverse of the extra feature is – well, not exactly the inverse, I would say like features that you build as you mentioned Dave, that ends up not being used and then trying to find ways to force the user experience to use it can also be like a waste in some sense because if the users aren’t really interacting with this piece of – with this feature that you built then you shouldn’t force the user to have to use this thing.
[0:08:42.6] DA: Right, yeah. Maybe it’s like maybe they’re happy with experiences as it is some – you can go through it. It can also be like form the developer side, it doesn’t have to be just product’s fault that extra features like you could try to build your class really robust in like an amazing modular way but maybe it just needs to do one thing and so like, making up module or really extensive one, customizable, just makes it really hard to understand and hard to test and hard to change on the future.
[0:09:15.5] MN: Right. Even going back to the first one when we mentioned where it’s partially work done, when you think of this big grand scale of extra features and then you’re kind of overwhelmed then you're more likely to partially finish that feature and then that goes back to you know, actually finishing the feature, not having partial work at the end of the day. I think I lost count, this is number four, right?
[0:09:38.4] DA: Yeah, this is number four.
[0:09:39.4] MN: Yeah, we got number four, we’re trucking along Dave. I think, for number four task switching. Now, this is very interesting, something that I’ve seen and experienced where it’s possible that and engineer can be part of two teams or like two initiatives. When you have to context switch form one piece of code to another, it can be really difficult and daunting and can be very wasteful to that engineer, that engineer’s time and getting work done.
[0:10:10.6] DA: Right, yeah. Especially like as an organization, you know, you’re working on two projects at once and it’ll take like statistically, you’re – provably, it will take longer for both of them to get done than if you just did the one thing all in, just focus on that and then completed the other thing.
[0:10:32.9] MN: One suggestion that I’ll say is just ensure that your engineers are on one team with one initiative working on one project at a time. I think that will definitely help some of the thrashing that may happen when you have to switch from one repository to another and stuff like that.
[0:10:52.6] DA: Yeah, I guess you could also be not such a drastic task switch where you’re switching between projects but even within your work, if you get into a state of flow, where you’re just jamming on code and then like Slack bubbles keep on puffing up or like people keep on tapping you on your shoulder or you got to go to a meeting and then you come back and then you have to do interview and then start another five minutes. That kind of thing can also be pretty challenging to work around.
I like the idea of like core hours where you set aside this time to do like the really tough thinking problems like writing code and figuring out how you’re going to architect your system and what not. Then squish the meetings into another corner of the day.
[0:11:40.2] MN: How do you feel about, what are your thoughts on scheduling that on your calendar where it’s like blocked, just for that. I’ve seen a lot of different people and different companies do that and I always find that very interesting. What are your thoughts on that?
[0:11:55.7] DA: Yeah, I think that makes sense, it’s a bit aggressive, I mean, I guess, but if p elope are being really, this is actually your time, sometimes you got to do that. They really want to, they’ll just schedule right over it anyway. Disincentive maybe.
[0:12:14.9] MN: Yeah, I’ve seen it at different places and it’s a good strategy for people to be like, you're blocked at this time so let me see if I can catch you some other time. Find people to be very respectful of that which is cool. I just never – I’m really bad with the calendar but I forget to put these core hours on to my calendar, I just kind of just work and then work what’s left.
[0:12:39.6] DA: Yeah, it’s like, you’re lucky if you see that you’re in the meeting to get disrupted.
[0:12:43.7] MN: Yeah, exactly. It’s like, snap, oftentimes, I would approve yes to a meeting I just came out of. Why did I do that? I don’t know. Yeah, being able to task switch. I mean, it is important as an engineer because you may have to deal with like interruptions that may happen or like you know, if there’s a production bug, you’re working on something, you have to get to it in that regard but always try to mitigate some of the task switching that you need to do in order to get the work done because it will inevitably delay value that you may deliver with the feature that you currently work on.
[0:13:20.6] DA: Yeah, sometimes it’s good to designate someone who is like your book master, or your batman, I think we talked about that previously.
[0:13:29.4] MN: Yeah, the batman.
[0:13:32.4] DA: Yeah, we’ve tried a bug wheel and that’s pretty fun, like a wheel of bugs.
[0:13:37.4] MN: The wheel of bugs, that sounds fun and then I’m sure it’s not.
[0:13:42.8] DA: Yeah, it’s a little full of dread but you know, actually, it does help because then, you’re just focused on squishing bugs and like, it feels really good and you’re not like stressing about not getting to the feature work that everybody really wants you to do. This is my one calling right now.
The next one, the next deadly waste is waiting.
[0:14:06.5] MN: Hold on, well, I think waiting hurts, I just want to identify that waiting is a waste, right? We, as engineers can all agree. I imagine when this book or this concept was done, it was during those times where compile or compilations would take hours.
[0:14:27.1] DA: Yeah, sword fights.
[0:14:28.9] MN: We’ve come a long way when it comes to this waiting waste. I kind of wanted to bring that up but there are some form of waiting that has to happen if you have a PR process that needs to get done and you have to wait for someone to context switch, to do their task switching to go and review your code.
[0:14:47.1] DA: Right.
[0:14:48.5] MN: Deployment can take some time, I’ve seen deployments take 10 minutes up to 30 minutes in certain places that I’ve worked at and it’s always very interesting to see that but waiting is the one thing that exists, I am just glad that we’ve come such a long way from what we once had to wait.
[0:15:05.1] DA: Yeah, I mean there’s definitely a lot better technology, better tools that automate away a lot of that stuff so you can do something else while you’re waiting for that to complete or running your test suite in a watch mode so it is just running in the background news. Puff over check it out, see how it’s going but there are kinds of waiting too that are more organizational where you might be waiting for the product to start.
Maybe like your assigned on a project and they don’t know what it is that it’s supposed to be yet. They don’t have the requirements, they don’t have the story set up and so you can just be sitting there like, “Okay I guess I don’t have any work to do.”
[0:15:50.4] MN: I guess I’ve got to refactor to something in the meantime.
[0:15:52.9] DA: Right, yeah. Right, I’ve totally done that before and oh just do some tech debt for tech debt sake but then that’s kind of like you are not going to need that. It’s extra features in its own way because what is this serving.
[0:16:05.3] MN: Right, exactly. Yeah, I mean it is definitely happened where like even like a feature requirement has changed that has to wait some time in order for you to start working on. It could be a little bit frustrating.
So there are many different ways of waiting besides compilation or deployment and that kind of stuff. So always be mindful of when you’re waiting, just call it out that this is a thing that is happening and try to bring it up with the product team on how we can reduce or not we, I’m not working there with you listeners but how can we as engineers can mitigate some of that waiting and get those feature requirements upfront so that we’re waiting less so that we can start cranking out code because that’s what we want to do. We just want to get in there, just start delivering value to the user. So that’s why we’re there for.
[0:17:02.1] DA: Yeah and I could be the table stirring too where the product team has everything all lined up and people are busy delivering value elsewhere. They’re all fighting fire and one day they’ll build my awesome feature. One day.
[0:17:17.2] MN: One day.
[0:17:18.4] DA: Dare to dream but until then you wait. It’s not going to be wasteful.
[0:17:23.6] MN: The next, as I love this word, so the penultimate waste of software development - I try to use that word.
[0:17:31.0] DA: It sounds so much fancier.
[0:17:32.9] MN: I love that word, my favorite of all time, penultimate. The penultimate waste of software development in our list right now, is motion. Can you tell us a little bit more about emotion of this waste called motion?
[0:17:45.5] DA: This has its roots in manufacturing where if I’m on a line and I need to go walk over there to get the part and then walk back and bolt it onto the car then that is like wasted motions. Just put the part next to where you are and that applies in a physical way for teams today where like it is more effective if people are just sitting right next to each other and I don’t need to go walk over and talk to somebody ask them question.
If everybody is just right there, you’re taller, get everybody to answer your question and then unblocked. You are not waiting, you’re not moving. So yeah, that is more efficient. I guess you can also have less motion if people are just generally available on Slack and interruptible.
[0:18:37.5] MN: So you say Slack has been an improvement to reducing this waste?
[0:18:42.5] DA: Yeah, I guess there are tradeoffs though because there is task switching.
[0:18:45.6] MN: Yeah, there’s task switching. You’ve got to deal with the Slack channels like cat-cat-cats and animals and stuff like that. That’s a waste of itself that’s outside of this list.
[0:18:57.7] DA: That’s a eighth waste of software development. There’s cat pictures.
[0:19:04.1] MN: You know that is the waste of the internet, right? Just you looking at cat pictures.
But reducing as you mentioned before, rather than having to walk over to someone and ask them a question and they could be in a different city. It is better to have then up close, it is shortening the feedback loop and iterations of the project that you are working on would definitely allow you to have all the things you need that is very close to you. So you can continue delivering the value without having to ask someone elsewhere or time different and that kind of stuff.
[0:19:36.4] DA: Yeah, just having people available. I guess also another wasted motion could be when a story bounces between different states. You want a story to move forward like a bullet from the ideation from a product to design to development testing and release. Just straight out and having something like yo-yo back and forth between development and design and testing, whatever. That’s an intangible motion that could be wasteful.
[0:20:10.5] MN: Right, interesting. Yeah because if you have to go back and forth and they make an update you have to make the change. Design has an update, you have to make another change, that kind of stuff. Imagine there’s a problem.
[0:20:23.8] DA: So now the ultimate waste.
[0:20:27.2] MN: The final, the final waste.
[0:20:30.5] DA: This is the final form.
[0:20:31.8] MN: Oh yeah.
[0:20:32.4] DA: So the final waste is defects.
[0:20:35.9] MN: Oh, we deal with that every day in our lives. Just defects that show up, the little ones, the pile up.
[0:20:44.1] DA: All those little bugs.
[0:20:45.1] MN: The big ones that destroy your website. Yeah, defects alone is very, very wasteful and the idea that you can have little ones like death by a thousand cuts right? And the amount of minor defects that you may have.
[0:21:03.3] DA: Defects in the design of the JavaScript language. You’re like, “How do I work with a number?”
[0:21:08.2] MN: Oh God, JavaScript is wasteful guys. You just heard it from me. Don’t do that. I love JavaScript, React is awesome. Yeah, it can be very, very difficult when you have defects popping up left and right and what would you suggest to reduce some of this waste?
[0:21:29.4] DA: I think the sooner you find a defect the easier it is to fix like, you know, if I’m writing a code and I make a PR for it and they find a problem in the PR then it is going to be more work for me to go back to that in context switch and get back into it and then fix it and then put it out for PR again and you know if it not in production then maybe I don’t even remember writing that code or maybe I am on vacation.
[0:22:00.5] MN: Yeah.
[0:22:00.9] DA: So it is even harder. So the best maybe just pair program and then fix the bugs right there. Do a desk check with the designers or product - just fix it while it is still out there.
[0:22:11.9] MN: Right, I think as you called out like trying to fix it as early as possible in the development process, there is also you know ensure that you have test coverage whether it is like I prefer having tons of unit tests, to make sure that everything works well but if you have like a smoke test, regression test and that kind of stuff. I think you mentioned before was very interesting it is just fin ensuring you can find the defect as early as possible, right?
And it could be while you’re developing the feature, it could be while you’re unit testing something. It could be while you’re regression testing something before you deploy to production because if you don’t have these avenues, then a defect can exist that you may never know that it does until you get an email from your user complaining about why this feature doesn’t work for me and you’re like, “Oh snap how do we not know that this was happening to our users?”
[0:23:07.6] DA: That’s sure too, yeah.
[0:23:08.5] MN: Oh let’s set up some logs. So even a log is like having some error logs that track where these defects are happening is a start but you want to start as close to the features as possible by finding a way when you are developing it then unit testing like slowly work your way up.
[0:23:30.7] DA: Yeah, that’s true if it is already out there and you don’t even know it’s happening then that’s like you’re in trouble.
[0:23:38.8] MN: Your customers are going to be pissed, yeah. Your customers is going to be upset and you are not going to have any way of identifying why this bug is happening but if you have all of these different ways to find or to record that these defects are happening I think the better you are in reducing this waste.
[0:23:54.8] DA: I really like that point of having that logging for bugs and production. You think like Century and other tools and just great that you get your source maps in there and then you get a React bug again but the exact line of code that the problem happened on and you know how many times it is happening and it’s like, “Oh well it just happened to that one guy.”
[0:24:18.0] MN: Yeah, there is one user, we’ll figure it out. Let us just fix it for the user and we’ll get it from there.
I think finally into defects, the one way to reduce the one way to reduce the waste of defects is having continuous integration in your workflow. I think that getting from developing the feature to pushing it out to production if you have all of these different checkpoints that check for anyway that a defect can be introduced then the more better you are in minimizing this waste.
[0:24:49.9] DA: Yeah, definitely.
[0:24:51.0] MN: So that was the seven waste of software development. We are going to ask you Dave really quick, which one of these seven do you wish you would minimize as much as possible anywhere you are. You identify really quickly and you want to bring it as small as possible and as waste less as possible, right? You don’t want to be wasteful for like –
[0:25:17.0] DA: Man. You know, I really – partially done work makes me really sad.
[0:25:23.9] MN: Sad?
[0:25:24.9] DA: I feel very sad when things are partially done, when you just have like a page that’s like half done. Why? I can’t use it. No one can use it, it’s so sad. All work should be done completely.
[0:25:39.1] MN: Yeah, make sure when you’re working with Dave, all your work. Must be done completely. All features must be completely done.
[0:25:50.6] DA: Yeah, within reason.
[0:25:52.5] MN: The one that I guess I resonate with the most is probably the defects one. Because the less amount of time you have to spend on defects, the more you're able to work on things and if you just pay it down up front, you know, by having unit tests and all these different ways to cover these defects then the more efficient you’ll be at delivering the feature.
Not to say that this one is more important than all the other ones, right? You have to ensure that you minimize the rest of them. But these were our personal opinions on what is the thing we want to reduce the most.
[0:26:29.5] DA: Get rid of the defects. Do all the work.
[0:26:32.7] MN: Do all the work, get rid of the defects.
[0:26:36.3] DA: Software engineering is done, I figured it out.
[0:26:38.5] MN: Yeah, exactly. Partially done work, do all the work with less process, the amount of features necessary don’t add any more of them while not switching tasks.
[0:26:51.4] DA: No cat pictures.
[0:26:52.4] MN: No cat pictures, stop command tabbing and checking out the Slack channels. Even if you're waiting, try not to wait as much, so do things.
[0:27:00.9] DA: Right, have the things are ready to do them and we do them.
[0:27:03.9] MN: Yeah, make sure everyone’s close and you can get the feedback very quickly and don’t get defects, just don’t.
[0:27:11.9] DA: Okay.
[0:27:12.5] MN: Stop it.
[0:27:13.9] DA: That’s it. That’s the end of the rabbit hole, figured it out.
[0:27:17.0] MN: Hey, we still got it out.
[0:27:17.8] DA: Software engineering, it’s over.
[0:27:18.9] MN: It’s over, seven things, keep it in mind and you’ll be great.
[END OF EPISODE]
[0:27:24.6] 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.
Links and Resources:
