Earliest Due Date vs Shortest Processing Time

Earliest due date sequences jobs by their promised date and runs the one due soonest first, while shortest processing time sequences by run length and runs the quickest job first. EDD minimizes how late the worst job gets, so it protects deadlines. SPT minimizes average time in the system, so it protects throughput and flow. The two rules frequently disagree, because the job due soonest is rarely the job that runs fastest, and choosing between them is really a choice about which cost you fear more: a missed date or a clogged shop. EDGEBIC by User Solutions lets its optimizer evaluate both orderings against your own plan so you can see the trade-off in real numbers rather than argue it in the abstract.

What each rule optimizes

These are the two most studied dispatch rules in scheduling, and each has a clean mathematical property on a single machine.

Earliest due date (EDD) sorts by the due date, ascending. Run the job due soonest, then the next, and so on. On a single machine, EDD minimizes maximum lateness: it makes the worst-late job as un-late as possible. If your pain is the one order that blows its date by a week, EDD is the rule that shrinks that worst case.

Shortest processing time (SPT) sorts by run length, ascending. Run the quickest job, then the next quickest. On a single machine, SPT minimizes average flow time, the mean time jobs spend from release to completion. Clear the little jobs and the average waiting time across all jobs drops, because a long job at the front makes everyone behind it wait.

The tension is built in. EDD ignores how long jobs take; SPT ignores when they are due. Neither is wrong. They answer different questions.

A worked example

Four jobs sit in front of one machine on Monday morning. Here are their run times and due dates.

SPT order (shortest first): MO-501, MO-503, MO-504, MO-502. Completion days: 1, 2, 4, 8. Average flow time is (1 + 2 + 4 + 8) / 4 = 3.75 days. But MO-502 was due day 3 and finishes day 8, so it is 5 days late.

EDD order (soonest due first): MO-502, MO-501, MO-503, MO-504. Completion days: 4, 5, 6, 8. MO-502 is due day 3 and finishes day 4, just 1 day late, and that is the worst lateness in the set. Average flow time rises to (4 + 5 + 6 + 8) / 4 = 5.75 days.

Read the trade in the numbers. SPT gave a far better average flow time (3.75 vs 5.75 days) but let the one date-critical job blow out by 5 days. EDD gave a worse average but held the worst lateness to 1 day. Same four jobs, same machine, opposite outcomes, and the right choice depends entirely on which cost hurts your business more.

The failure modes to watch

Each rule has a signature way of going wrong.

SPT starves big jobs. Because it always favors the quickest job available, a large order can sit at the back while a steady stream of small jobs keeps jumping ahead. Your throughput dashboard looks excellent and your biggest customer is furious. The standard remedy is a guardrail: once any job crosses a lateness threshold, pull it forward regardless of size.

EDD ignores workload. Because it looks only at the date, EDD can put a nearly-finished job with a close date ahead of a barely-started job with a slightly later date that is actually in more danger. That is the gap critical ratio and slack-based sequencing were designed to close, since both weigh the remaining work against the remaining time instead of looking at the date alone.

How EDGEBIC handles the choice

The standard engine does not force you to pick one rule and live with it. It sorts deterministically by priority, then start date, then due date, which gives you a stable, reproducible baseline where the due date is already a tie-breaker; that base is described in how a scheduler decides which job runs first.

The real answer to EDD-versus-SPT is the optimizer. The multi-run search re-runs the unmodified engine under several complete global orderings, including an earliest-due-date ordering, shortest and longest processing time, critical ratio, and seeded shuffles. It scores each finished schedule against your objective and proposes the single best one, guaranteed never worse than the baseline, applied only when you accept it. In practice that often surfaces a blended sequence: most of SPT's flow benefit, with the few date-critical jobs pulled forward the way EDD would insist. You are not stuck choosing the rule up front; you let the optimizer show you the schedule each rule actually produces on your data. The optimizer guide covers the scoring and the never-worse clamp.

Which one should you reach for

Default to earliest due date when dates are the promise you live and die by, when a single blown deadline costs a customer, and when jobs are roughly similar in size. Default to shortest processing time when the goal is flow, when you are clearing a backlog or feeding a downstream constraint, and when average lead time matters more than any single date. When you cannot decide, that indecision is itself the signal to let the optimizer test both and quantify the gap, the same way the worked example above turned a philosophical argument into a 5-day lateness number and a 2-day flow-time difference. See both orderings run against your live orders in EDGEBIC, and read where sequencing fits the whole engine in the scheduling engine guide.