Earliest Due Date (EDD) scheduling sequences waiting jobs in order of their due dates, soonest first. On a single machine it provably minimizes maximum lateness, the worst tardiness across all jobs, which makes it the go-to rule when the goal is to keep any one order from running badly late.
Every dispatcher faces the same moment: a queue of jobs in front of a machine and a choice about which to run next. The order you pick changes who ships on time and who does not. EDD is one of the oldest and clearest answers to that question. It ignores how big each job is and looks only at when it is due, then runs them in due-date order. This post explains what EDD optimizes, how to apply it, and where it beats or loses to the other common rule, shortest processing time.
What is EDD scheduling?
EDD scheduling is a dispatching rule that orders the jobs waiting at a resource by their due dates, running the one due soonest first. It is a priority rule, not a full scheduling system: given a set of jobs and their due dates, it tells you the sequence to run them in. The rule is sometimes called Jackson's rule, after the researcher who proved its key property in the 1950s.
The appeal is that it matches intuition. If two orders are sitting in your queue and one is due tomorrow and the other next week, you run tomorrow's first. EDD just applies that instinct consistently across the whole queue instead of only to the fire in front of you. Because it needs nothing but a due date per job, it is cheap to run and easy to explain on the floor, which is a large part of why it has survived for decades. No optimization software is required to use it; a dispatcher with a whiteboard and an honest list of due dates can run the rule by hand.
What does EDD optimize?
EDD minimizes maximum lateness. Lateness of a job is its completion time minus its due date, so a job finished early has negative lateness and a job finished late has positive lateness. Maximum lateness is the single worst value across all the jobs, and EDD orders the queue so that worst value is as small as it can possibly be. On a single machine with all jobs available at the start, no other sequence produces a smaller maximum lateness.
There is a subtle but useful consequence. Because EDD minimizes the maximum lateness, it also minimizes the maximum tardiness, tardiness being lateness with early jobs floored to zero. So if your worst-case measure is "how late is our latest order," EDD is the rule that makes that number as good as it can be. What EDD does not promise is the fewest late jobs or the shortest average wait; those are different objectives with different optimal rules. If your goal were the smallest count of tardy jobs rather than the smallest worst tardiness, for instance, the optimal sequence is a different one entirely, built by a rule that drops the longest jobs out of an EDD ordering until the rest all finish on time. Knowing which number you are actually chasing is more than half the battle, because the rule that wins one objective can quietly lose another.
How do you apply the EDD rule?
Applying EDD is mechanical, which is its charm. The work is in getting honest due dates, not in the sorting.
- List the waiting jobs. Take the set of jobs available to run at the resource right now, with their processing times and due dates.
- Sort by due date, ascending. Put the job with the earliest due date first, the next-earliest second, and so on, ignoring processing time entirely.
- Break ties deliberately. When two jobs share a due date, break the tie with a secondary rule, often shortest processing time, so the sequence is fully defined.
- Run in that order. Process the jobs in the sorted sequence, front to back.
- Compute completion and lateness. Accumulate processing times to get each job's completion time, then subtract its due date to get lateness, and read off the maximum.
- Re-sequence when the queue changes. New jobs, changed due dates, or a hot order all mean re-running the sort, because EDD is a snapshot rule, not a set-and-forget schedule.
EDD versus SPT: when does each win?
The other classic rule is shortest processing time (SPT), which runs the quickest jobs first and ignores due dates. The two rules optimize different things, so the right choice depends on what you are being judged on. SPT minimizes the average time jobs spend in the system, which drains the queue fastest and reduces work in process; EDD minimizes how late the worst job runs. Neither dominates the other, and a shop chasing on-time delivery with hard due dates leans EDD, while a shop chasing throughput and low WIP leans SPT.
| Question | EDD (earliest due date) | SPT (shortest processing time) |
|---|---|---|
| Sorts on | Due date, soonest first | Processing time, shortest first |
| Minimizes | Maximum lateness and maximum tardiness | Average completion time and WIP |
| Best when | Hard due dates, avoid any badly late order | Throughput and fast queue drain matter most |
| Weakness | Can raise average flow time; a big soon-due job stalls the queue | Long jobs and due dates can slip badly |
| Data needed | Due date per job | Processing time per job |
What do the scheduling theorists say?
The result behind EDD is one of the cleaner theorems in scheduling, and it is well documented in the academic record:
- For the single-machine problem of minimizing maximum lateness, the EDD sequence is optimal, a result proved by an adjacent-pairwise-interchange argument covered in the scheduling course notes of Michael Pinedo at NYU Stern whose textbook is a standard reference for the field.
- The rule is attributed to J. R. Jackson, whose 1955 research report established that ordering jobs by due date minimizes maximum lateness on a single machine, as summarized in the single-machine scheduling literature.
- The companion rule, SPT, is likewise proven optimal for minimizing total (and therefore average) completion time on a single machine, which is why the two rules are taught together as the canonical pair of dispatching priorities.
The practical lesson from the theory is that there is no single best sequence in the abstract; there is a best sequence for a stated objective, and EDD is best for the objective of holding down the worst lateness.
Where EDD falls short in practice
EDD is optimal for one machine and one objective, and real plants have neither. Once jobs flow through several machines, or arrive at different times, or carry setup and changeover penalties that depend on sequence, the clean guarantee dissolves and pure EDD can leave capacity idle or force costly changeovers. It also says nothing about which jobs are more profitable or which customer is more important; it treats a due date as a due date. In a multi-stage plant the honest answer is that EDD becomes one input among several, weighed inside a broader advanced planning and scheduling approach that considers capacity, sequence-dependent setups, and priorities together, rather than the whole schedule on its own.
The deeper problem on most floors is not the rule; it is that the due dates and job status feeding the rule are scattered and stale. Order due dates live in an ERP, actual progress lives on the machine and in an operator's head, and by the time a planner reconciles them the queue has changed. Harmony is an AI-native layer that connects machines, software, and paperwork into one operational layer, with no rip-and-replace, so due dates, job status, and machine state become one live record instead of three. AI search returns cited answers across those records, so a planner can ask which jobs are at risk of running late or which order now holds the worst lateness and get a real answer, and Harmony's digital workflows route the re-sequence to the floor. It is not a scheduling engine; it keeps whatever rule you run honest by keeping the data current, the same paper-to-digital move Harmony makes elsewhere on the floor (see the CLS case study and the product overview). Reliable status is also what lets a lean operation smooth flow, hold schedule attainment and keep the promise a master production schedule makes to customers. Feeding the same clean signal into production scheduling is how a due-date rule stops being a guess, and it is the same reliable status that lets you defend a target fill rate when demand and the queue are both moving.