The second problem can occur with the addition of new tasks to the queue. For example, once that funny noise coming from your engine you kept ignoring prevents you from driving anywhere, getting your car to a service station to get it fixed inherits a higher priority! If a lower priority task is blocking a higher priority one, it must assume the priority level of the task it is blocking. The solution here is what is called priority inheritance. I am sure you can think of many analogous life situations like this! And the high priority task can’t get done until the low priority one gets out of the way. The low priority task will never outweigh the high priority task to make it to the top of the stack so the system resource can be freed up. In this case, all that will ever get done are medium priority tasks. The unavailability of this resource then blocks a new high priority task from starting. This issue occurs when there is a partially completed low priority task is tying up a key system resource. The cause was a problem of priority inversion. The first one famously brought the Pathfinder spacecraft to a confused, dithering halt on Mars until scientists solved the issue. There are, however, a few caveats with the above scheme. As new tasks come in, this analysis will be able to assign a clear place in line for it. This would ensure that the biggest bangs for your time bucks are first in the queue. This can be as simple as setting 1 = low, 2 = medium, and 3 = high priority tasks, or the importance could even be expressed as a monetary value for each task. When ordering by the task length, it can be weighted for priority by dividing the time by the importance. Whole books get written on this subject, but it is a fairly simple thing to account for with scheduling. None of this, however, takes into account that tasks nearly always have differing levels of importance. The first inclination may be to send out the simplest tasks, but this algorithm suggests a different approach is optimal. It’s an interesting solution to consider when you consider outsourcing tasks. We keep doing this until our scheduler is back to running like a Swiss train. Here we start by queuing up via earliest due date and, as soon as something is going to be late, toss out (or get help with) the largest task. To accomplish this, we can use Moore’s scheduling algorithm. This makes sense as we would then be keeping the number of people barking at us as small as possible! How about if we instead prefer to minimize lateness? Again, this is simple, just order by due date.īut a bit of interesting complexity arises if, instead of minimizing a time measure of lateness, we would prefer to minimize the number of tasks that are late. The frogs can wait their turn to get eaten. By specific, I mean we need to define which parameter it is we wish to optimize.įor example, if we want to maximize the number of things we get done, the solution is easy – just order by the shortest processing time. But before we hop right along to algorithmic solutions, we must make our goals specific. Even if you have just one machine to schedule and not an office full, the wrinkle in the scenario above is that most of us will never have enough time to complete all tasks. And when you come to the end, stop.”īut alas, life is more complex than this simple case. Given these parameters, the definitive advice on scheduling follows from The Mad Hatter in Alice’s’ Adventures in Wonderland: “Begin at the beginning.
So eat dessert first then the frog or whatever floats your boat. If your definition of “productivity” is efficient time management, you only need to know one thing – the task order is irrelevant. The simplest scheduling problem to solve is one where you have a single machine (or just yourself as in the case of the self-help books) and a set list of tasks. So let’s discuss instead a related, but far more concrete topic – task scheduling and its optimization. Part of the issue is that these books tend to speak metaphorically (few of us are employed to consume amphibians) and even the concept of “productive” is rarely defined parametrically. And the result is a barrage of conflicting advice, as in the example of the two quotes above. But we’re not going to call it “productivity.” Mostly because this much-ballyhooed concept has spawned far too many books and articles already. In this third installment of our Algorithms to Live By series, we are going to touch on a subject near and dear to my colleague Chris’s heart, productivity (you can check out his Not To Do List here).