today i want to introduce you to a concept if you haven't heard it already that is fundamental to in particular the kanban method and i want to share this not because i want you to adopt kanban today i do think kanban is a totally valid way of working but i want to share it because you can think about a lot of things through this lens that will help you with your personal kind of productivity and not just productivity but your focus and we do talk a lot about focus in fact it was one of the very first episodes that we talked about on this show uh nine years ago and focus is critical focus is critical to you getting your work done not just getting your work done but doing quality work so uh the concept i want to introduce is called little's law and this concept is uh you you may have heard it if you know much about kanban at all if you have your certification in kanban for example so little's law is expressed as a mathematical formula uh but we're not going to necessarily go into the math side of it although it is a very simple uh kind of conceptual formula here um the formula basically states that for a queue uh in little expressed it as customers because queuing theory was mostly applied to customers when he wrote this in 1961 that formalized the proof uh but the the number the average number of customers in a system is equal to the arrival rate of those customers times the average time a customer spends in the system that say that saying that again the average number of customers in the system right the the total number of people in a store but also the total number of items uh in a warehouse for example right this applies to any kind of queue the total number of jobs in an sqs queue all of that applies right the the total number of items in a queue is equal to the arrival rate of those items times the average time of customers in a store and that's the total number that the that the items spend in the system now reformulation of this is that the throughput of a given system all right the throughput of a given system what this means is things coming out uh on one end of that system the throughput of a given system is equal to the amount of items the average amount of items in that system divided by the amount of time that those items spend in the system this is the same formula just moved around the evolution of the It's a very simple kind of algebraic trick that you can do to move this around. And similarly, you can do another move to say that the amount of time that things spend in that system is equal to the total number divided by the throughput, the average number at any given point in time divided by the average throughput at any given point in time. Now, of course, there's a bunch of assumptions attached to this law. You can Google that. Probably the main assumption here is that there is a stable system, which essentially means that you can't have large fluctuations or changes in the arrival rate or the departure rate. If you are familiar with Kanban, you've probably heard of this described as flow or consistent flow. To get a basic idea of this, if you're listening to this on the day that it releases, it's a Saturday. You may have a task list of things to take care of on your weekend. I usually do. I have a lot of things I want to get. I have a lot of things I want to sit down around the house. If I were to take on, let's say, three of those things today, and I try to do all three of them at the same time, I may finish all three by the end of the day. But if I were instead to limit my work in progress, if I were to do one thing at a time, then I'm going to finish one of those essentially in a third of the time. We're not going to do that. We're not getting into the cost of context changing, which is very real. But what we're talking about here is taking three things and trying to do them all at the same time or focusing on one thing at a time. You're going to get the first thing done in a third of the amount of time because you're focusing all of your energy on it rather than splitting your energy between three different things. Even in a perfectly efficient system, this is still true. Now, why does this actually matter? Why does it matter? Well, setting aside, and this is a very rare thing for us to do on this show, but setting aside the behavioral side of this, the fact that it's very difficult for us to actually make progress on three things at once as individuals. It's also very difficult for teams, by the way, to make a bunch of progress on a bunch of things all at once, especially if you have more than one item in progress per person on that team. Right? Setting aside that fact. There's some human behavior to consider when you're talking about context switching. Even if you had all of those things figured out and you had a perfect context switching, perfectly efficient system, what this law tells us is that you can deliver things. You can get things through the system earlier. Right? That's important. Earlier. Even if it's not all of the things, right? You can get things through the system. Earlier. If you limit the number of things that you do, that's the intuitive model here. If you limit the number of things that you're focused on, if you limit the number of things you're putting your energy into, you can get more done earlier. It's the same amount total over time in a perfectly efficient system, right? But you're going to get more done earlier if you limit your work in progress. It's a very simple insight. So why is this important? Why is it so popular? To talk about Little's Law when we're talking about Kanban. Because if there is any value at all in getting something done, not the whole picture, not all 20 items that you have on your to-do list, but if there's any value at all in getting something done earlier, right? If you were to pick between getting all 20 things done at the same time or getting one thing done one twentieth of the time, which one? Which one? Which one would you pick? In most cases, it is more valuable to finish something earlier than to finish everything later. Now, this is especially true, by the way, for product development, especially true in software, especially true in unknown situations where there's a lot to learn, where you're trying to iterate. This is how iteration fundamentally happens in a Kanban team. By the way, you limit your work in progress so you can deliver things sooner and you can learn from them. And you can adjust what you're doing. Right? You can adjust what you're doing. But you may find difficulty in implementing this, particularly in systems where you're not totally in control of the system. In other words, you can't really control what other teams are doing. You can't really control what other people are doing. Let's say you're looking for a job, as an example. Limiting your work in progress when you're searching for a job is not a particularly helpful thing because a lot of the time that you spend in that cycle time. Right? The time from the time that you send your job, you know, application to the time that you hear back, there's a lot of waiting time. So it's very difficult for you to actually affect the system in a way that's useful because you're not using the full capacity of the system. In other words, your throughput is theoretically much higher. Right? You've got a lot of potential throughput that's not really being used. Right? Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. places where you apply this, start with things that are under your control. Start with your own task list. Start with the things that you directly impact or directly make decisions about. Finding flow for the things that you can control so you're not trying to multitask. Instead, you're limiting your work in progress and you're getting more done earlier. This isn't a magical insight. This is nothing particularly new. This law has been around for a long time and people have known about it even longer than it was formalized. As humans, we often ignore these kinds of relationships. We don't think about our task list and say, okay, if I only focus on one thing at a time, I will ultimately get more done sooner so that if anything unexpected happens in the middle of the day, I still have something to do. I still have something to do. I still have something to do. I still have something that's been worked through. I've still kind of completed something. I've delivered value in some way. And by the way, if you are running a team, this is one of the reasons why the blocked column is so important on a Kanban board, in my opinion. If something is blocked, then you can take it kind of out of that work in progress. This means that even though your queuing system has the thing, you've started it. You've actually started the thing. You're taking it out of the system. You're taking it out of, not out of the working system entirely, but out of the little law system so that you can continue with that same throughput. You're basically subbing out the thing that's blocked because you don't have the ability to continue with that thing. So using a blocked column and removing something from that queuing system is a very useful trick, if you will. Ultimately, like most things, on this show, I am not going to tell you to go and implement Kanban on your teams. You have to make those decisions. You have to weigh the pros and cons. But this relationship is important for you to know about because so many things that we deal with as engineers, whether it's actually in the things that we're building or if it's in the multiple kind of situations, the managing situations that we go through in our lives, we're going to experience queues very often. And how we manage those queues can have a major impact on our lives and they can have a major impact on the people that we lead and on the work that we do. Thanks so much for listening to Developer Tea. I hope you enjoyed this episode. If you did, please consider leaving a review in iTunes. This is the one thing that I ask for people to do if you're listening to the show, if you're getting any kind of value out of it. It's no secret podcasts like this one, as a general rule, have a business model that relies on sponsorship. And that sponsorship, is based on listenership. This show is able to be funded when we have listeners, especially when we have new listeners who are coming to try the show out. So that's one way to keep the show running. But additionally, I truly want for this show to reach more engineers and help them in their careers. That is really the fundamental reason. If I had no sponsors at all, I'm still going to continue doing this show. And I would still hope that you would take a few minutes to leave a review in iTunes. We also have the Developer Tea community. Head over to developertea.com slash discord to join that community. It's totally free. There's other software engineers there. There's a book club. There are people who are asking about jobs, about specific technical issues they're having, and then periodically asking about the show. So it's a community of other software engineers, like-minded software engineers that you can connect with. Head over to developertea.com slash discord. Thanks so much for listening. And until next time, enjoy your tea.