Pickup and Delivery Route Optimization (Free Tool)

If you’ve ever tried to plan a pickup and delivery route by hand — grab a package here, drop it there, then double back across town for the next pickup — you’ve felt how fast it stops being a map problem and turns into a logic puzzle. Every delivery depends on a pickup happening first, every vehicle has a limit, and every stop has a window when it can actually happen. I spent two decades building optimization models for exactly this kind of problem, and I eventually turned one of them into a free tool anyone can use. Here’s what makes pickup and delivery routing genuinely hard, and how to stop solving it by guesswork.

Continue reading “Pickup and Delivery Route Optimization (Free Tool)”

Twenty Years of Models, One at a Time

I’ve been doing operations research for over 20 years. Most of what I’ve built is locked inside Excel files on a hard drive. Not because Excel is where OR models belong — it isn’t, really — but because that’s where the data was, that’s where the clients were, and that’s what worked at the time.

The backlog is real. Staff scheduling, vehicle routing, warehouse slotting, least-cost formulation, a few others. Each one took months to build and calibrate. Each one is doing nothing right now except existing as a .xlsm file.

Continue reading “Twenty Years of Models, One at a Time”

Same Three Files, Much Harder Problem

When I finished porting the routing engine to Python, I had a 480-line file that solved vehicle routing problems and printed results to a terminal. That’s useful exactly to me, in exactly one context. The staff scheduler had already gone through the same transition — terminal script to Flask web app — and I’d figured out the pattern there. So I assumed wrapping the VRP would be roughly the same amount of work.

It wasn’t the same amount of work. But the structure was.

Continue reading “Same Three Files, Much Harder Problem”

Porting 1,500 Lines of C# to Python Without Losing My Mind

The original routing model was 1,500 lines of C#. The Python port ended up around 480 lines. Some of that compression is the language — Python is more concise. Some of it is that I stripped out the proprietary cloud backend, the database calls, and the dispatch interface. What remained was the core: the model structure, the constraints, the solver parameters.

The translation itself was mostly mechanical. OR-Tools has Python bindings that mirror the C# API closely enough that you’re often just changing syntax: camelCase to snake_case, semicolons disappear, type declarations disappear. But “mostly mechanical” left room for a few things that didn’t work the first time.

OR Tools c sharp version

Continue reading “Porting 1,500 Lines of C# to Python Without Losing My Mind”

Why Google OR-Tools and Not the Excel Solver You Already Know

The staff scheduler I wrote about a few weeks ago was a MILP — a Mixed Integer Linear Program. You define variables, constraints, and an objective function. Hand it to a solver, get an answer. Clean, relatively tractable, runs in seconds on a laptop.

The vehicle routing problem is something else entirely.

routing optimization directions
Continue reading “Why Google OR-Tools and Not the Excel Solver You Already Know”