Personal blog on early retirement, selling tradelines, and analytics projects. I write about credit, optimization models, and what I've learned
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.
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.
Continue reading “Porting 1,500 Lines of C# to Python Without Losing My Mind”
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.
A few years ago I helped build a truck routing system for a logistics company. It was a real project — real trucks, real delivery stops, real time windows, real money. The client spent around $2 million on it. Then the pandemic hit. The project died. And the code sat on my hard drive doing nothing.
Last week I turned it into a web app.
Continue reading “The $2M Project That Died in a Pandemic (And What I Did With the Code)”
The staff scheduler took about 20 years to build.
That’s not as dramatic as it sounds. The MILP model — the math, the constraints, the logic — that came together during the Fiverr engagement described in the first post of this series. What took 20 years was accumulating enough Operations Research experience to know what the model needed to look like. The actual build, once I sat down with the problem fully understood, was fast.
The web app took a few days. The deployment took an afternoon, plus one failed attempt that taught me about gunicorn.
