Article
Explaining optimisation algorithms through the lens of 2000s comedy
Transport optimisation sounds like it should be a clean, technical exercise. You take orders, vehicles, drivers, depots, delivery windows, costs, and constraints. You press a button. A perfect plan appears.
Except it doesn’t.
Transport planning is not a tidy puzzle of miles, minutes, and pallets. It is a live operational system full of customer promises, driver realities, depot pressures, incomplete data, shifting priorities, awkward sites, last‑minute failures, and knowledge that often lives in planners’ heads rather than in the software.
That is why this series is not just about algorithms. It is about optimisation as a product problem.
The aim is to explain the core ideas behind transport optimisation in a way that connects theory to real operations, product design, and decision‑making inside a TMS — while also opening up the black box of algorithms.
And for reasons that will become clear, our guide for this journey is My Name Is Earl.
In My Name Is Earl, Earl Hickey wins a lottery ticket, loses it, gets hit by a car, discovers karma, and decides to turn his life around by writing a list of everything bad he has ever done. Each episode becomes an attempt to fix one item on that list.
It is a comedy about a man trying to impose structure on a chaotic life. That is why it works as a metaphor for optimisation.
Earl’s world is messy. People behave unpredictably. Solving one problem often exposes another. A decision that seems sensible in the moment creates consequences somewhere else. The list gives Earl structure, but it does not make the world simple.
Transport planning is the same.
A plan can reduce miles but increase waiting time. Improve utilisation but remove resilience. Lower cost but increase service risk. Optimise one depot while making the wider network worse.
The moment you start optimising transport, you run into the same question Earl accidentally discovered:
What are we actually trying to make better?
That question sits underneath the whole series.
Before talking about software, it is worth stating something clearly: good transport planners are already optimisers.
They may not talk about objective functions, heuristics, or constraint programming, but they constantly balance competing goals — often using the same reasoning patterns as expensive optimisation engines.
A planner is thinking about cost, service, driver hours, vehicle suitability, site access, customer priority, depot congestion, reload opportunities, delivery sequence, resilience, and the likelihood that the plan will survive contact with reality.
That is optimisation. It is just done through judgement, experience, memory, and pattern recognition.
A good planner knows:
the cheapest plan is not always the best
the technically possible window may still be a bad idea
which sites are awkward
which customers need protecting
which reloads usually fail
which driver–site combinations are best avoided
This knowledge is valuable because it is operationally grounded — and difficult to turn into software.
Some of it is formal and visible: master data, rules, time windows, equipment requirements, driver hours, capacities, cost rates.
But much of it is informal:
“That collection says two o’clock, but it never is.”
“You can send an artic there, but only if the driver knows the entrance.”
“That customer is flexible on paper, but not in reality.”
“That route looks fine until you remember the M62 between 6 and 10.”
“That driver knows the site, so he’ll get tipped quicker.”
A weak optimisation product ignores this knowledge. A better one asks how much of it can be captured, exposed, challenged, reused, or supported. An even better one learns from history
The aim is not to replace planner judgement. The aim is to give skilled planners better tools, better visibility, better options, and better explanations.
Management usually wants something different — and understandably so.
Transport businesses want:
lower costs
better service
higher utilisation
fewer empty miles
improved visibility
better consistency
reduced dependency on individual knowledge
less manual effort
These are legitimate goals. No business wants its planning process to depend entirely on one experienced planner knowing hundreds of undocumented exceptions. No finance team wants cost control to rely on instinct. No customer service team wants delivery confidence based on phone calls and hope. No product leader wants critical operational knowledge trapped in people’s heads.
So management looks at optimisation and sees opportunity.
Optimisation promises to standardise decisions, reduce manual effort, improve margin, increase planning speed, and make performance more consistent across depots and shifts. It also promises visibility: once planning decisions can be measured, compared, and explained, they become easier to manage.
This is where My Name Is Earl becomes unexpectedly useful.
Earl’s list is not just a personal improvement plan. It is a control system. It makes the mess visible. It classifies the past, creates priorities, defines progress, and gives Earl a way to judge whether he is moving in the right direction.
That is very close to what management wants from optimisation.
But critical systems thinking immediately asks: useful for whom, and according to whose definition of improvement?
A transport plan is not a neutral technical output. It sits inside a social, commercial, and operational system. Different groups experience the system differently:
Management sees variation as inconsistency.
Planners see variation as necessary judgement.
Finance sees cost leakage.
Operations sees resilience.
Customer service sees risk.
Drivers see feasibility.
The same plan can look efficient, fragile, unfair, or unrealistic depending on where you sit.
This is where Foucault enters the depot.
Optimisation is not only a calculation. It is a way of making work legible. It turns judgement into data, exceptions into categories, decisions into audit trails, and performance into something that can be monitored.
Again — not automatically bad. Earl’s list helps him. Optimisation can help a transport business.
But the list also changes the world around Earl. Once something is on the list, it becomes a problem to be corrected. Once a person is on the list, Earl’s view of them changes.
The same thing happens in operational software.
Once a metric exists, behaviour changes. Once overrides are counted, they may be treated as non‑compliance rather than expertise. Once empty miles are highlighted, planners may be pushed to reduce them even when doing so increases service risk. Once utilisation becomes a headline measure, resilience may start to look like inefficiency.
This is why optimisation can create mistrust if it feels like surveillance rather than support.
When planners are sceptical about optimisation, it is easy to label that as resistance to change.
Sometimes it might be but often it is a rational response to bad experience.
Planners have seen systems recommend plans that look good mathematically but fail operationally. They have seen software ignore site realities, customer habits, driver constraints, trailer quirks, depot pressures, and the awkward details that make transport planning difficult.
They have seen “optimised” plans that still require heavy manual repair before they can be used they also know who gets blamed when the plan fails.
If the algorithm produces a poor plan, the planner still has to fix it. If the delivery is late, the planner still gets the phone call. If the driver cannot complete the route, the planner still has to recover the day.
That creates a trust problem.
A planner may reasonably ask:
Those are not just change-management questions.
They are product questions.
A black-box optimiser says:
This is the best plan.
A better decision-support product says:
Here are the options. Here are the constraints. Here are the trade-offs. Here is the recommended plan. Here is why the system prefers it. Here are the risks that remain.
That difference matters.
Planners want better tools, cleaner data, faster replanning, clearer visibility, fewer repetitive tasks, better exception management, and stronger impact analysis.
What they do not want is software that misunderstands the job and then tells them it has solved it.
When planners are sceptical about optimisation, it is easy to label that as resistance to change.
Sometimes it is. Often it is a rational response to bad experience.
Planners have seen systems produce plans that look good mathematically but fail operationally. They have seen software ignore site realities, customer habits, driver constraints, trailer quirks, depot pressures, and the awkward details that make transport planning difficult.
They have seen “optimised” plans that still require heavy manual repair — and they know who gets blamed when the plan fails.
A planner may reasonably ask:
Does the system understand the real constraints?
Can I see why this plan was recommended?
Can I override it quickly?
Will it learn from my corrections?
Is this saving me work or creating different work?
Who is accountable when the recommendation fails?
Does management now think planning is easier than it really is?
These are not change‑management questions. They are product questions.
A black‑box optimiser says:
“This is the best plan.”
A better decision‑support product says:
“Here are the options. Here are the constraints. Here are the trade‑offs. Here is the recommended plan. Here is why the system prefers it. Here are the risks that remain.”
That difference matters.
Planners want better tools, cleaner data, faster replanning, clearer visibility, fewer repetitive tasks, better exception management, and stronger impact analysis.
What they do not want is software that misunderstands the job and then tells them it has solved it.
This is why optimisation belongs firmly in product thinking.
The algorithm matters, but it is only one part of the product.
A TMS optimisation capability must:
It must also serve multiple stakeholders:
These needs are connected but not identical, sometimes they conflict and that is why “optimised” is not a neutral word.
Optimised for what?
And that is where Earl comes in.
That is where Earl comes in.
The series uses characters and ideas from My Name Is Earl as a way of explaining different optimisation concepts.
The point is not to force a sitcom onto mathematics. The point is to use a familiar structure to make abstract ideas easier to understand.
Each character represents part of the optimisation problem.
Series guide
This series uses My Name is Earl as a recurring way to explain transport optimisation. Earl gives us the objective, Joy gives us the constraints, Crabman gives us hidden operational knowledge, and Camden County gives us the messy operating system in which every plan has to survive.
The Objective Function
Optimisation role: Earl represents the decision objective: the thing the system is trying to improve.
Transport meaning: In transport, this is the definition of a better plan: lower cost, fewer empty miles, better service, improved utilisation, lower risk, or a weighted compromise across all of them.
Example: A TMS optimiser needs to know whether it is protecting cost, service, utilisation, carbon, resilience, or some agreed balance.
The Optimisation Target
Optimisation role: The list turns vague improvement into a structured set of outcomes.
Transport meaning: Transport planning needs the same clarity. Before an optimiser can help, the system must know what matters and how success will be measured.
Example: A planning model without a clear target is just a fast way to produce a confident but questionable answer.
The Feedback Loop
Optimisation role: Karma represents delayed consequences: decisions that return later as effects elsewhere in the system.
Transport meaning: A cheap plan may create late deliveries, rework, waiting time, driver pressure, customer escalation, and future operational drag.
Example: Reducing vehicles today can increase failed deliveries tomorrow, which then creates replanning work and service recovery cost.
The Constraint
Optimisation role: Joy represents rules, limits, and non-negotiables that restrict the solution space.
Transport meaning: Driver hours, delivery windows, site rules, trailer compatibility, customer requirements, vehicle capacity, and depot opening times all decide what is actually feasible.
Example: A route that looks profitable is still unusable if the vehicle cannot access the site or the driver cannot complete the hours legally.
Local Optimisation
Optimisation role: Randy represents well-meaning local decisions that solve the immediate problem but damage the wider system.
Transport meaning: A depot, planner, or customer-specific workaround can look sensible locally while increasing cost, complexity, or risk across the network.
Example: One depot protects its own resources, but the overall network ends up with more empty running and poorer asset utilisation.
Unknown Knowledge
Optimisation role: Crabman represents operational knowledge that exists but may not be visible in the formal model.
Transport meaning: Planners and drivers often know things the system does not: awkward yards, slow sites, unreliable booking slots, or routes that work on paper but not in reality.
Example: The database says the delivery window is valid, but the planner knows the customer never unloads before 09:30.
Flexible Capacity
Optimisation role: Catalina represents scarce capability that can be used in different ways.
Transport meaning: Flexible resources matter: multi-skilled drivers, specialist vehicles, ADR capability, chilled/frozen compatibility, tail-lift equipment, or assets that can cover multiple work types.
Example: A flexible vehicle or driver can protect the plan when demand changes, but that flexibility is itself a scarce resource.
The Operating Environment
Optimisation role: Camden County represents the messy, changing system in which the model has to operate.
Transport meaning: Transport planning happens in a live environment of late orders, delays, missing data, changing requirements, congestion, customer exceptions, and imperfect information.
Example: A plan that works in a clean dataset may collapse once real arrivals, delays, amendments, and site behaviour are included.
The Reset Point
Optimisation role: The motel represents where the system recovers, resets, and exposes its true state.
Transport meaning: Depots, yards, cross-docks, loading bays, and trailer parks are not passive locations. They are capacity points where plans either recover or fail.
Example: A route plan can look efficient while the depot quietly becomes the bottleneck that breaks the next wave of work.
Future Consequences
Optimisation role: They represent the future state created by current decisions.
Transport meaning: Transport optimisation should consider tomorrow’s capacity, customer confidence, driver availability, asset positioning, and accumulated operational debt.
Example: A plan that wins today by burning goodwill, buffers, or driver capacity may weaken the system for the next planning cycle.