operations research Archives - Page 4 of 5

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.

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.

What’s Next: 20 More Models Waiting in Excel

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.

Three Files. One Web App. Zero Web Development Experience.

At some point during this project I stepped back and looked at what we’d built.

Three files. A working web application. Deployable for $7 a month. Zero web development experience going in.

That felt worth writing down.

The three files that make up a Python Flask web app

Three Bugs That Would Have Stayed Hidden in Excel

When you convert an optimization model from Excel to standalone Python, you expect to do some work. You expect to rewrite the data loading, restructure the variable definitions, test the output. What you don’t expect is for the model to fail in three distinct ways, each one caused by something the Excel version was handling silently without you knowing it.

Handling PuLP solver errors in a Python optimization model

That’s what happened here. Three bugs. All real. All the kind that would have stayed invisible forever if the model had stayed in the spreadsheet.