Article
Why transport optimisation has to start by defining what better actually means.
Earl Hickey starts with a deceptively simple idea write down the bad things, fix them one by one, and become a better person. It is funny because Earl’s world is chaotic, badly planned, full of unintended consequences, and permanently one poor decision away from collapsing into another mess. In other words, it is not a bad metaphor for transport planning.
The important thing about Earl’s list is not just that it gives him something to do. It gives him a way to decide what matters. Without the list, Earl is just reacting to whatever problem is currently shouting the loudest. With the list, he has a structure. He has priorities. He has a definition of progress.
Importantly, he also has constraints—the rigid boundaries of what he can physically or legally do. In transport, these are things like driver hours, vehicle weight capacity, or fixed booking slots. Earl has them too.
Think of Randy as the Hard Operational Constraint. Randy brings the absolute physical limits of human capability to Earl’s plans. If Earl needs to cross off an item, he has to work around Randy’s fatigue, intense fear of birds, or the fact that Randy simply will not function unless they stop for a grilled cheese sandwich. You can design the most morally perfect plan to fix a wrong, but if it violates the “Randy Constraint,” the execution completely stalls.
Then there is Joy: the ultimate Soft Constraint with a massive penalty function. Joy is like a high-risk, litigious customer contract. Technically, Earl can build a plan that ignores her, but doing so triggers immediate, catastrophic operational friction. Whether she is manipulating Earl’s lottery money, threatening him with a shotgun, or actively trying to kill him with poison cookies because of an old video will, Joy represents those real-world operational variables that carry such a heavy penalty you effectively have to design the entire system around them.
That is where optimisation starts.
In transport, people often talk about creating a “better plan”, but better is not a neutral word. Better for whom? Better against which measure? Better over what time period? A plan with fewer miles might increase waiting time. A plan with fewer vehicles might increase service risk. A plan with higher utilisation might leave no resilience when the day starts going sideways. A plan that looks commercially efficient might be operationally fragile.
Before an optimiser can find a better answer, somebody has to define what better means. This article explains a key part of optimisation , the objective function, however first it must introduce our heroes (if you have never seen Earl please watch it!)
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.
In optimisation, the objective function is the thing the model is trying to minimise or maximise (please try this using the model below), it tells the system what counts as progress.
In a simple routing problem, the objective might be:
Minimise total distanceThat is easy to understand, but transport is rarely that simple. Most real transport operations are balancing several competing goals at the same time. A transport plan may need to reduce mileage, protect service, avoid empty running, improve vehicle utilisation, reduce planner intervention, respect driver hours, avoid yard congestion, and still remain commercially sensible.
That means the real objective function is often closer to this:
Plan Score =
or to put it formally
That looks more complicated, but it is more honest. Transport optimisation is not about one perfect measure. It is about choosing between trade-offs.
The classic optimisation example is the shortest route. It is useful, but it can also be misleading. A route can be shorter and still be worse.
A shorter route may fail because the:
That is why transport optimisation needs a wider view of value. The route is only one part of the plan. A TMS has to support decisions across orders, loads, vehicles, drivers, trailers, depots, time windows, customer rules, service risk, cost, and operational recoverability.
If the objective function is too narrow, the optimiser will do exactly what it was asked to do and still produce a poor operational outcome.
That is not an algorithm failure. That is a framing failure.
Earl’s list is not ordered by convenience. If it were, he would only pick the easy items: the small apologies, the quick fixes, the people who are still easy to find. However the logic of the list is bigger than that, it is about making things right, which means some items matter more than others even if they are awkward.
Transport planning has the same issue. If a planning system only optimises for what is easiest to solve, it can create a plan that looks tidy but fails the business.
For example, a system might favour:
None of these goals are automatically wrong. The problem comes when the system treats one of them as the whole answer.
A useful optimiser needs to understand priority. It needs to know when service matters more than cost, when cost matters more than asset convenience, when resilience matters more than utilisation, and when a plan that looks slightly inefficient is actually protecting the wider system.
One practical way to handle this is weighted scoring. Instead of pretending there is one perfect measure, the system gives each factor a weight.
| Factor | Example weight | Meaning | My Name Is Earl trade-off example |
|---|---|---|---|
| Transport cost | 30% | Keep the plan commercially efficient | Earl’s list often starts with a simple debt: he stole, broke, borrowed, or wasted something. Examples include “Stole ten dollars from a guy at the Camden Market”, “Borrowed money from tip”, “Stole a motorcycle”, and “Been wasteful”. The trade-off is that making things right is rarely free. Earl can repay the obvious debt, but doing so consumes money, time, and effort that could have gone to another item on the list. |
| Service reliability | 30% | Protect delivery performance | Earl’s core promise is that he will keep working through the list, one wrong at a time. The show repeatedly tests whether he sticks to that promise when life gets messy. The trade-off is reliability versus convenience: Earl can do the easy item, or he can do the item that actually needs doing, even when it disrupts his own plans. |
| Empty running | 15% | Reduce wasted mileage | Earl has plenty of list items where the original harm was pointless waste: “Been wasteful”, “Been a litterbug”, “Always took a penny, never left a penny”, and “Siphoned gas”. The trade-off is between immediate selfish gain and the wider cost left behind for everyone else. Earl’s old behaviour created waste because he only optimised for himself. |
| Vehicle utilisation | 10% | Use assets effectively | Earl often tries to do too much with too little: a motel room, Randy’s help, limited money, and a list that keeps growing. The trade-off is efficiency versus overload. Like Earl trying to cram too much karma repair into one plan, a system can look efficient while becoming fragile, confused, or dependent on everything going perfectly. |
| Waiting time | 10% | Avoid hidden operational cost | Earl’s list includes items where delay itself is part of the damage: “Made Derrick Stone late for work”, “Never gave mom a good Mother’s Day”, and “Kept a guy locked in a truck”. The trade-off is that waiting is not always visible as a direct cost, but it still damages people, relationships, and outcomes. |
| Planner complexity | 5% | Reduce manual repair and exception handling | Earl’s list begins as a simple moral checklist, but it keeps expanding: he starts with 259 items, adds more later, and some items become nested problems of their own. The trade-off is between a complete plan and a usable plan. Earl can keep discovering new wrongs, but the list becomes harder to manage, prioritise, and finish. |
| Driver feasibility | Optional | Keep the plan realistic for legal hours, breaks, and lived human experience | Randy is often the reality check. Earl may have the moral objective, but Randy has limits: confusion, fear, distraction, loyalty, and emotional dependency. The trade-off is ambition versus human capability. A plan that assumes people can just keep going indefinitely is not realistic. |
| Customer priority | Optional | Reflect that not all promises, people, or obligations carry the same consequence | Earl’s list includes strangers, family, Joy, Randy, Darnell, Catalina, Kenny, and his parents. Not every item has the same emotional or social weight. The trade-off is fairness versus priority: Earl can treat every list item equally, or he can recognise that some wrongs have deeper consequences and need more urgent attention. |
| Operational resilience | Optional | Leave enough slack to absorb disruption | Earl repeatedly learns that karma does not behave like a clean project plan. Fixing one thing can expose another: he repays one person, upsets someone else, or discovers the original wrong was bigger than he thought. The trade-off is optimisation versus resilience. A plan with no slack collapses as soon as the real world gets involved. |
| Carbon impact | Optional | Reduce harm beyond the immediate transaction | Earl’s list is basically a personal externalities register: the damage he caused but did not originally pay for. Items such as littering, waste, theft, and selfish shortcuts all show the same pattern. The trade-off is short-term convenience versus the wider harm pushed onto other people or the environment. |
The important point is not that these are the correct weights. They probably are not. The point is that the weights make the argument visible. Without visible weights, the optimiser’s priorities are hidden. Users see the answer, but they do not see the values embedded inside the answer. That is dangerous in operational software because planners need to understand why a recommendation has been made before they can trust it.
A black-box optimiser says:
This is the best plan.
A better decision-support tool says:
This is the best plan based on the current balance between cost, service, empty running, utilisation, waiting time, and operational complexity.
That distinction matters.
The simulation below shows the central idea. The candidate plans do not change. What changes is the definition of better. Increase the weight on cost and the cheapest plan may win. Increase the weight on service and a more expensive but more reliable plan may become preferable. Increase the penalty for empty running and a different plan may move to the top.
The point is simple: optimisation results are not neutral. They reflect the objective function.
The simulation should make three ideas obvious.
A useful output might look like this:
| Plan | Cost | Empty miles | Service risk | Utilisation | Complexity | Overall score |
|---|---|---|---|---|---|---|
| Plan A | Low | Medium | High | High | Low | 72 |
| Plan B | Medium | Low | Low | Medium | Medium | 84 |
| Plan C | High | Low | Very low | High | High | 79 |
In this example, Plan B wins not because it is cheapest, shortest, or simplest. It wins because it gives the best balance against the selected objective.
That is much closer to real transport decision-making.
For TMS customers, optimisation is valuable when it improves real decisions. That means the product has to do more than calculate a technically valid answer.
It needs to help users understand:
This is where product design matters as much as algorithm design. A technically strong optimiser can fail if the workflow does not expose reasoning, confidence, exceptions, and trade-offs. Planners do not just need an answer. They need a decision they can explain, challenge, and act on.
That is especially important in transport because the planner is often responsible for the result long after the algorithm has finished running. If the plan fails at 04:30, the customer does not ring the objective function. They ring operations.
Many optimisation projects struggle because the objective is assumed rather than agreed.
Commercial teams may want lower cost. Operations may want fewer failures. Customer service may want stronger delivery performance. Finance may want margin protection. Drivers may want realistic schedules. Customers may want certainty. Planners may want fewer exceptions and less manual repair.
All of these are legitimate. None of them can be maximised perfectly at the same time.
That is why the objective function is not only a mathematical artefact. It is a product and business decision. It encodes priorities. It exposes conflict. It forces the organisation to say what it values.
This is one reason transport optimisation is such an interesting product problem. The hard part is not only finding a good route. The hard part is helping the business agree what good means.
Earl’s list works because it turns a messy life into a structured problem. It does not make the world simple, but it gives Earl a way to navigate the mess.
Transport optimisation works the same way. The system does not need to pretend transport is clean, stable, or perfectly predictable. It needs to help people make better decisions inside the reality they actually operate in.
And that starts with the list.
Or, in optimisation terms, the objective function.
Interactive simulation · Birmingham, UK
100 transport jobs · 1–5 pallets each · 14-pallet vehicles. Depot in Birmingham city centre. All deliveries within 30 miles. Each visible route is drawn as depot → stop → stop → depot legs, with every leg coloured by remaining load fill.
Set your weights above and click Run to see how the model changes vehicle count, fill rate, route shape, service risk and unrouted work.