In one of the open mic sessions we got at the advent, his clarity when talking about modeling stuck with me.

A few weeks ago, while preparing the 2025 edition, his name came back onto my radar. I had been thinking about showcasing great engineering practices inside optimization, and Tim’s work on GAMSPy fit that theme perfectly.

So we reconnected.

After looking carefully to his course, it became obvious we shared the same perspective:

Optimization isn’t just math, it’s software engineering.

And Tim has years of experience turning that philosophy into real, industrial-grade systems.

That’s why I’m thrilled to bring him to Feasible today.

Tim Varelmann is the founder of Bluebird Optimization. He’s a Computational Engineering Scientist trained at RWTH Aachen, the University of Queensland, MIT, and UT Austin. He’s built optimization software for demanding environments and teaches others how to do it with clarity and structure.

His track record includes work with European brands such as Zalando and SAP, alongside a diverse set of startups — from local innovators in his home region to cutting-edge teams in Silicon Valley.

And today, he’s sharing a story every OR engineer should read.

I’ll leave you with him. ✨

Software maintainability is never accidental — and when it’s neglected, complexity grows faster than your model ever will.

So if we can’t get high-quality optimization software for zero effort, what if I told you that you only need to put effort into one concept (for which I built the Code-Check Compass, you can get it here) to make your model implementations robust, readable, and easy to extend?

That would be the minimal feasible effort, wouldn’t it?

Let’s phrase it like an optimization problem:

min     Effort

s.t.    Ease of maintenance ≥ 90%
        Ease of extension   ≥ 90%
        Ease of readability ≥ 90%

Are you ready to see the optimal solution with an objective value of “put effort into one concept only”?

This concept is called: algebraic modeling.

Once you start modeling algebraically, you’ll naturally reap the benefits of high-quality software.

🧹 Refactoring chaos: a personal story

Several years into my career, I joined a project that had grown into a 2,500-line tangle of optimization code. The previous team had done impressive work getting it to run at all — but without software-engineering structure, the codebase had become unmanageable: duplication everywhere, untested branches, and enough hidden bugs to keep anyone awake at night.

I had already used algebraic modeling for years, but this was the moment that proved its full power to me.

I started refactoring, applying algebraic modeling principles: reuse parameters, express logic through sets, and separate data from equations. Each step made the next easier — it was like the code began cleaning itself.

In the end, those 2,500 lines collapsed into just 48 lines across two files — more than fifty times shorter, crystal clear, and remarkably stable. Testing became trivial, bugs were eliminated, onboarding new collaborators became effortless.

That project reignited my appreciation for how algebraic modeling naturally enforces software-engineering discipline. It also inspired me to channel years of this experience into something shareable — “Effortless Modeling in Python with GAMSPy”, the world’s first dedicated course on GAMSPy.

I’m still proud of that milestone. Seeing practitioners finally model with elegance and engineering rigor is one of the most rewarding parts of my work.

📐 Why algebraic modeling is worth your focus

Algebraic modeling isn’t just a convenient syntax. It’s a framework that quietly enforces high-quality decisions throughout your model implementation.

Here’s how the landscape looks:

• ⚖️ Commercial vs. open-source environments: Open-source frameworks are fantastic for experimentation, but commercial environments still lead in sparsity exploitation. They generate models faster and scale better for industrial applications — crucial when your time budget is measured in seconds, not coffee breaks.

• 🏆 Why GAMS stands out: GAMS is the original algebraic modeling language. Its long history isn’t nostalgia; it’s practical advantage.
  Because GAMS has had the largest and most diverse client base for decades, it’s likely seen more real-world edge cases than any competitor — and every one of those cases has sharpened its already world-class sparsity exploitation engine. The more feedback GAMS processes, the bigger its performance gap grows.

• 🐍 What makes GAMSPy unique: GAMSPy brings that heritage into Python, combining GAMS’s industrial strength with Python’s flexibility and seamless integration of machine learning. It’s the bridge between optimization and data-driven intelligence — and it’s closing the gap faster than any other tool.

When you adopt algebraic modeling through GAMSPy, you’re not just writing cleaner code. You’re stepping into decades of accumulated engineering wisdom.

✨ Two immediate improvements you can make

Let’s start with two things anyone with a model implementation can do right away.

✂️ 1. Separate data from equations

A cornerstone of software engineering is separation of concerns: every component has exactly one purpose — and therefore only one reason to change.

In your optimization models, this means keeping data and model logic apart. Try the following exercise:
In your code, insert a visual separator (for instance, in Python: # ----------------------- ).

• Above this line: define all data and assign them to named variables.

• Below this line: only describe your model logic — decision variables, constraints, objectives.

capacity = 5 # data section
# -----------------------
plant_production <= capacity # model logic

Closely related is the principle DRY – Don’t Repeat Yourself.

DRY doesn’t mean a parameter is used only once; it means each value has a single source of truth. Define capacity = 5 once, then reuse that variable wherever it belongs. If capacity changes to 7, there’s just one line to update. That’s reuse instead of repetition.

🔁 2. Replace manual arithmetic with set-based operators

Instead of:

total_production = prod_machine1 + prod_machine2 + prod_machine3

use

machines = set(1, 2, 3)
total_production = SUM(i in machines, prod_m[i])

Again, the benefit of the revised version is: in case of changes (i.e adding/removing machines), you only have to touch the set definition, but not the constraint formulation.

Algebraic Modeling Environments provide this functionality natively — defining sets, iterating over them, and correctly expanding operations such as sums over them.

I sometimes think “set-based modeling” would be a more intuitive name than “algebraic modeling,” because it describes what’s really happening under the hood. But for historical reasons, the field calls it algebraic.

▶️ Your next step

Can’t get enough of these practical hints, but don’t want to dig through dozens of articles to find them?

Grab my Code-Check Compass at https://gift.bluebirdoptimization.com/feasible.

It’s a concise, industrial-strength checklist that turns “I hope this model holds together” into “I know exactly what to check”. Each line saves time, prevents bugs, and nudges your models toward elegance.

→ Get the checklist and make your optimization models a joy to maintain.

Until the next iteration!

-Tim.

🗞️ Other related posts people like

I attended it carefully, as the concepts were meaningful. Not only to me, but to the whole field of Operations Research.

The talk was given by Matthias Als, Lead Data Scientist at ECCO, and it was brilliantly articulated around DecisionOps.

Matthias came to say that OR models are mathematically sound but operationally fragile, for many reasons. And that new discipline is here to help.

It might sound that DecisionOps is to OR what MLOps is to ML, but it’s not just renaming.

That’s why today in Feasible, we’ll see:

• ⏲️ The time for DecisionOps has come

• ♻️ The DecisionOps lifecycle

• ⏭️ The path forward

Are you ready? Let’s dive in… 🪂

⏲️ The time for DecisionOps has come

Optimization used to end when the solver returned a solution.

That’s what we were told at university.

But that’s not real-life Operations Research. And if we’re looking at an agentic world -where AI systems and humans make decisions continuously- optimization is no longer a one-off event. It’s continuous infrastructure. And when infrastructure fails, businesses break.

Every decision becomes a production event.

That demands something new: a discipline that treats decisions like systems. Versioned, tested, monitored, explained.

That discipline is DecisionOps.

It’s not a buzzword, it’s the next layer of decision reliability in Operations Research.

The term is gaining traction, and the practices are real.

But there are at least three points that highlights its importance.

🏔️ The deployment chasm

For decades, there has been a lot of manual workflows when deploying OR solutions.

Testing in Excel. Sending the code by email. No monitoring.

This erodes trust as algorithms are seen as opaque decisions instead of tools to rely on and help speed up decision-making processes.

There hasn’t been a systematic deployment methodology as academia was more interested on teaching algorithms and getting to mathematical perfection rather than operationalizing what’s really useful for the industry.

And when we try to mirror Machine Learning workflows, we see the difference.

Lots of tools there, just a couple here.

Lots of tutorials there, one or two here.

Practitioners preaching about good practices there, almost no one here.

I know, I know. ML and OR are different disciplines. Does that mean we need to treat OR differently in this aspect too?

🤏🏻 What makes OR different from ML

One thing that ML and OR have in common, especially in the late months/years, is explainability.

While ML explainability asks ‘what did the model learn?’, OR explainability asks ‘why is this optimal and why not that alternative?’.

Machine learning models need tools like SHAP to reverse-engineer learned patterns. Optimization models have explicit logic embedded in constraints and objectives, but that transparency only helps if you can communicate it.

Hard constraints cannot be violated (there’s no 95% feasible solution concept), and sometimes that’s difficult to explain to stakeholders.

Apart from that, ML and OR differ in several ways.

I’ve never heard “why this model predicted this class with that accuracy?”, but you face similar situations in OR every-single-day: “Why did my driver get this route?”, “Why can’t we squeeze in one more delivery?”, “Why is the solver saying this is impossible?”.

That explainability is business-critical as you need to justify why the model took some decisions to stakeholders.

So instead of monitoring model drift (when your production data distribution changes from your training data, causing prediction accuracy to degrade over time), you need to monitor problem characteristics through scenario testing.

Your routing model might historically have handled 100-200 orders, now it gets 500.

Your scheduling model assumed 8-hour shifts, now you have 12-hour shifts in the new market the business is operating on.

Your pricing optimization model was tuned for stable costs, now costs are volatile, producing solutions that make no sense to the business.

💸 The cost of inaction

There was a conversation between Hexaly’s CEO, Fred Gardi, and Nextmv’s CTO and co-founder, Ryan O’Neil, where Fred argued that:

During the past decades, OR has suffered to be taught as a mathematical discipline in my opinion. Too much emphasis on math, algorithms, and not enough on IT, software engineering, and project management best practices.

It resulted in a poor execution in OR projects, with very expensive projects, if not project failures. Despite progress in the last decade, OR lacks an established, practical methodology and tools which implement such a methodology.

Nextmv fills this gap. Nextmv helps developers to execute their OR projects better and faster.

Cannot be more accurate.

There’s an academia-industry divide I’ve written about before several times. The last one, in this open letter I made.

Academia focuses on theoretical soundness while industry needs maintainable solutions that work with messy data, accurately, and over time.

But there’s a new elephant in the room. It’s going to come sooner or later, and we need to be ready for that.

Yes, AI agents.

AI agents are increasingly deciding, not just predicting.

Optimization engines are being embedded into workflows and systems that run without human supervision.

That means:

• Failures propagate instantly.

• Trust becomes infrastructure.

• DecisionOps becomes indispensable.

The future of OR isn’t just better models, it’s better operations around those models.

We won’t just build optimization models anymore.

We’ll operate decision systems.

♻️ The DecisionOps lifecycle

DecisionOps formalizes the continuous loop that connects model outputs to business outcomes.

It makes decision systems iterative and auditable, rather than episodic and opaque.

It’s the set of processes, tools, and principles that allow organizations to build, deploy, test, and monitor decision models reliably and continuously.

If DevOps brought agility to code, and MLOps to machine learning models, DecisionOps brings it to optimization and decision intelligence.

As stated by Matthias in that ECCO talk, it’s not just a specific technology stack. It’s about how we manage the lifecycle of decisions, not which technology produces them.

It sits at the intersection of:

• Operations Research, which defines how to make good decisions,

• Software Engineering, which ensures they run reliably, and

• Decision Intelligence, which ensures they make sense in context.

It’s a mindset shift where you…

1. 🧪 Experiment and version-control every change to make it traceable. You must track configurations, datasets and outputs so you can reproduce every possible run. It also enables side-by-side comparison of results.

2. 💉 Test. If code can be tested, constraints and objective functions can too. Testing decisions means verifying that every rule behaves as intended.

3. 🚢 Deploy. Models are only valuable when they can act. Deployment in DecisionOps means moving from “runs on my laptop” to “runs reliably for the business”. APIs, containers, and automated pipelines are the ones governing this part.

4. 💻 Monitor. A decision doesn’t end when it’s made. Monitoring closes the feedback loop: track solutions (quality, time, violations) and visualize KPIs for non-technical stakeholders.

In practice, this creates a continuous workflow:

0. LOCAL DEVELOPMENT
├─ Write model formulation
├─ Test locally with sample data
└─ Version control

1. EXPERIMENTATION & VALIDATION
├─ Run scenario tests (different inputs, params)
├─ Compare solutions side-by-side
├─ Track experiments
└─ Validate with stakeholders

2. QUALITY ASSURANCE
├─ Push code to Git repository
├─ CI pipeline triggers
├─ Automated tests run
└─ Build passes ✓ or fails ✗

3. DEPLOYMENT
├─ Package model
├─ Deploy to production environment
└─ API endpoint becomes available

4. PRODUCTION & MONITORING
├─ Applications call API with real data
├─ Solutions returned to business systems
├─ Logs track performance (solve time, quality)
└─ Alerts trigger if anomalies detected

5. ITERATE
└─ Feedback loop: monitor → analyze → improve → repeat

Whether you’re using open-source tools, a dedicated platform, or something in between, the pattern remains the same: develop locally → test systematically → deploy automatically → monitor continuously.

⏭️ The path forward

Up until this point, we’ve discussed why DecisionOps is important and what exactly it is.

We’ve seen that DecisionOps ultimately is a mindset shift.

But if it mainly is a mindset shift, are there any tools that make your life easier?

Yes, and the good news is most of them already exist.

You don’t need to wait for a perfect ‘DecisionOps platform’ to appear. You can start today with adapted tools from MLOps and DevOps, plus a few OR-specific additions. Here’s the minimum viable stack for each of the four tasks:

Read more

But AI agents might be about to change what work even is.

In Operations Research, that means decisions will move from being designed to being performed.

Automatically.

And that has consequences. Not only for our way of working, but for the field itself.

So today in Feasible we’ll cover:

• 🏎️ From batch to real-time decisions

• 😶‍🌫️ OR is growing, but becoming (even more) invisible

• 🛠️ OR will need more engineering discipline than ever

But before we jump into the topic:

Next Friday, I’ll be sharing one of my favorite projects at Trucksters, where we built Axis, a simulation and optimization tool that transformed how we plan our European routes, combining graph theory, heuristics, and CP-SAT optimization.

Axis has created a positive flywheel inside the company: improving decisions, reducing free capacity, and increasing margins 💸

If you’re curious about how optimization goes from model to margin, and what it takes to bring OR into production, join us at the EURO Practitioners’ Forum.

Now… Are you ready? Let’s dive in… 🪂

🏎️ From batch to real-time decisions

Imagine you’re a planner at 10:30 AM.

You open the planning tool and see there are 5 loads near Eindhoven for the next 6 hours.

You know there are some drivers ready to get the load on time, but you need to open three dashboards:

• 🚚 One for the available loads with all their information (loading time windows, exact location, trailer type).

• 📍 One for drivers, their location and their availability.

• 🗺 One for distances between drivers and loads.

And you see there are 7 available drivers.

You create a distance matrix among all locations (drivers and loads) and start assigning them so to minimize the total distance.

It’s second nature to any logistics business: empty kilometers are pure waste.

Then you start assigning drivers to loads, and after some iterations (as it wasn’t quite easy), you end up having 5 drivers assigned to those 5 loads. 15 minutes gone.

(BTW, this is the exact problem our planners had when I described the process to solve it here)

Instead of all that process, that repeats 10 times a day, every single day, we could have an agent that:

1. Retrieves all the information from the database (loads, drivers, distances).

2. Pass it to a specialized solver that minimizes empty km.

3. Return the solution in a human-readable style.

Mimicking what I did for solving the Queens game:

You could just replace the web browser MCP with a database MCP, and the solver MCP with the needed one for this use case. But the architecture and ideas remain the same. And the user just had to say “find me the drivers that minimize empty km to get the 5 loads around Eindhoven”.

You’d be solving an easy problem from the optimization perspective, but saving 13 of those 15 minutes for the planner. Multiply it by 10 as the planner repeats the process 10 times daily. More than 2 hours savings per day that can be used for other, more impactful actions.

You might be wondering this is just automation, and we’ve had APIs for decades.

The main difference here is that agents compose tools dynamically. A traditional system needs pre-programmed workflows. An agent can handle: “find drivers near Eindhoven OR Rotterdam if Eindhoven has less than 3” without anyone coding that logic explicitly. And without their explicit task of finding the information to feed the solver. They’re able to get natural language and translate it into proper instructions.

But even if we still need humans in the loop to verify all the process, we’d create agents taking those tasks autonomously, without any human intervention in the process of retrieving information and clicking a button after feeding a tool to get a solution.

And that might mark the beginning of a new era for Operations Research; one where we stop doing optimization, and optimization starts doing itself.

😶‍🌫️ OR is growing, but becoming (even more) invisible

We, as humans, are constantly solving decision problems.

If we want them to be properly solved, we need Operations Research techniques.

At the same time, AI agents are like gas: they’re expanding to fill every interface they can reach. And decisions will not be any exception to that.

Soon, OR will be the silent mechanism powering every autonomous workflow. Even if they’re not completely autonomous and you need a human in the loop to verify every step, OR will be diluted into the process.

💧 Like plumbing in our buildings.

🌐 Like TCP/IP for the internet.

🛰️ Like GPS for navigation.

OR will become their decision infrastructure: the invisible layer translating data into action.

Here’s the uncomfortable part:

Read more

What happened?

Last week I posted “I vibe-coded an OR agent”.

That sentence hides two big shifts.

The first one is that I vibe-coded something, that is, I used AI coding tools to write the code for me. That has implications for you and me as developers of models, algorithms, and systems that work.

The second one is that I built an OR agent, an AI agent that actually does Operations Research. That has implications for the field itself, and for the way we think about optimization in a world of agents.

Today, let’s focus on the first one.

AI coding companions like Claude Code, Codex CLI, or Gemini CLI make development dramatically easier by writing the code themselves, not you.

But this has consequences.

Do you need to be an expert to effectively vibe-code OR, or does vibe-coding make expertise less necessary?

When AI writes 80% of your code, what are you actually contributing? How do you stay sharp as an OR engineer when you’re typing less? Are we becoming better problem solvers, or just better at delegating to AI?

Let’s unpack that in Feasible:

• 📈 Skills that matter more

• 📉 Automated, not obsolete

• 🧭 The open questions

Are you ready? Let’s dive in… 🪂

📈 Skills that matter more

When people started using GenAI to write code, there was a catastrophic view of developers being replaced by AI.

The knowledge accumulated by AI is bigger than the one accumulated by humans in general, that’s true. And thus AI is lowering the barrier for developing products.

But that doesn’t mean you’ll instantlly have more competition.

That means you’ll need to focus on other areas.

Which ones? you’d be asking. Let’s see some of them, but this is not a restricted list.

🧪 Experimentation

Experimentation becomes cheap with GenAI. You can test infinite approaches to solve your problems in less time.

If you take my previous article as an example, I myself tested an idea (agents + solvers) in less than one hour.

I don’t know exactly how long that would’ve taken that automation, but I can guarantee you I couldn’t write that automation in less than one hour.

That means that before GenAI, I’d only test ideas I was really confident about.

But now I can explore more of them.

What if instead of using Python + Google OR-Tools I want to test Java + Timefold? What if instead I wanted to code my own heuristics and local search methods? What if now I want to get the board with computer vision?

We can iterate more on formulations and ideas, and validate (or invalidate) assumptions faster.

🧠 Design thinking

As a consequence of the previous one, design thinking will be more relevant as you’ll need to think in business solutions, not just solutions to optimization problems.

And here I see two kinds of design thinking.

One that goes to architecture design, where you’ll design systems with clear interfaces. This module reads data, this one solves, this other one presents results. The AI can implement each module, but you’ll be the designer of them.

The other one goes to product thinking, where you’ll spend more time on thinking which problem you’re actually solving, who’s going to use it, or what does success look like. But you’ll spend less time on how to code the thing itself.

🔢 Problem formulation

If you want to let Claude Code build the Queens solver, you wouldn’t say “write a constraint programming model”.

You’d rather say “the Queens can’t touch each other, can’t be in the same color region, can’t be in the same row or column”.

The clearer my business rules, the better the code.

The AI can translate formulation → syntax. But it can’t ask your stakeholders the right questions to get that formulation.

That’s still on you.

🐛 Debugging

Here’s the uncomfortable truth: debugging vibe-coded OR models is harder because you didn’t write them. You don’t have the mental model of how it works, unless you personally approve every single change made by the AI. Which turns the development into something slow (slower than if you write the code yourself).

But debugging also gets better in some ways: I can ask Claude “why is this constraint infeasible?” and it can explain the logic back to me, or create a plan to understand why.

It’s like pair debugging.

You’ll talk with the AI to create plans that find the bug, and over time you’ll build your own sense of what to do, you’ll create a better intuition when working with it.

♻️ DecisionOps

The gap between a prototype and production shrinks as vibe-coded models can go from idea to working demo in hours.

But does that mean they’re production-ready?

I don’t think so. Most of the times, they aren’t. You’ll need -more- discipline to not ship vibe-coded experiments into production.

And that discipline has a name: DecisionOps. Vibe-coding accelerates creation, DecisionOps safeguards adoption.

📉 Automated, not obsolete

At the same time there are skills that matter more, there are skills that matter less.

It’s not like they’re going to disappear, it’s just they’re being automated.

Read more

It opens the browser, reads the board, let a solver get the solution, and clicked on the board to actually solve it inside the game.

I didn’t plan to build that, just vibe-coded my way there.

And it worked pretty well.

In less than one hour, Claude Code did all the heavy lifting.

If AI can help us build things faster, what happens to how we do Operations Research? Is our way of coding going to change? And are there more implications to the field itself?

We talk a lot about AI replacing coding. But maybe what it’s really doing is changing how we think when we code.

Today in Feasible we’ll see:

• 👑 Building the LinkedIn’s Queens solver agent

• 📚 What I learned about GenAI for OR coding

• 🧩 What this means for my work (and maybe yours too)

Are you ready? Let’s dive in… 🪂

👑 Building the LinkedIn’s Queens solver agent

One hot August morning last year, I solved the Queens game automatically.

It was easy, but also not so automatic.

At that time, there was no Claude Code nor anything similar, and ChatGPT, while working pretty well, couldn’t handle everything by itself.

Thus I built something useful: a spreadsheet with a button to call a solver. You just needed to color the cells as in the game, put the initial Queens (if any), push the button, and you got the solution fast.

That’s still working, you can see all the info in this post and its comments.

But it felt kind of meh.

You needed to put a lot of effort by replicating the board in a spreadsheet, and after solving the game you needed to click into the board so to give the solution to LinkedIn.

I knew there had to be a better way. Since Claude Code had come, I started using it in my regular job, and I thought about replicating this by letting Claude Code actually code everything so that it’s solved automatically.

This is what I did.

The game is a variation of the well-known N-Queens problem in which you need to place N Queens in a board game of NxN squares so that none of them can attack each other. In this variation, you cannot place two Queens in the same row, nor in the same column, nor in the same color, nor touching them.

I asked Claude about how to leverage AI Agents with MCP (Model Context Protocol) servers to solve the game, and after a couple of messages it was clear I could:

• Create an agent.

• Let the agent explore the board game through Playwright to launch the web browser (as an MCP server).

• Pass the board game to a solver (as an MCP server too).

• Let the solver actually solve the game and return a solution.

• Let the agent get that solution and click on the cells to place the Queens.

Then I went to Cursor (I was just testing it, you can use VSCode as you’re just using the agent’s terminal), gave some instructions to Claude about the context of the game, how I want it to solve it, the initial code that I already had because of the previous conversation, and the initial code I already had from the Google Sheet’s code I had one year ago.

🧠 Curious about the code?

You can explore the full implementation (Playwright + solver + agent logic) here (everything’s exactly as I vibe-coded it, didn’t touch a single line that Claude Code produced):

Get the code

In a couple of minutes, it had everything in place: I could launch it and see how it went to the LinkedIn Queens’ page, get the board game, solve it and click on each position so that it gets solved. Like this:

It was slow: 5 minutes and 48 seconds for something I’d solve in just a minute? No way. What was happening here?

Just by looking at how the agent interacted with Playwright, I could easily see it was reading again and again the board to look for the specific cells to click twice (in fact, to click once, then look for the cell again, and click again).

That was a waste of time!

So I told it to improve that part and look for more improvements if there was any.

Its solution? Saving the board game in local (finding the important html parts), and caching the information in memory so it easily knows where to click.

After that, the agent could open the browser, read the board game, solve it and click for the solution in 1 minute and 2 seconds.

Not blazing, but good enough to prove two points:

1. Humans can orchestrate while AI explores.

2. Solvers fit naturally inside agent workflows.

Vibe-coding isn’t about coding faster but about extending our intuition and run experiments.

This was just that, one experiment, but a powerful one.

And I want to share with you if LLMs are good at coding for us or not, and what this means for OR practitioners like you and me.

This tiny puzzle became a testbed for a much bigger question: can LLMs really code for us, or are they just mimicking patterns?

Subscribe now

📚 What I learned about GenAI for OR coding

This vibe-coding thing seems it worked for me, but am I just lucky or is this reproducible?

There has been multiple studies out there trying to decipher whether LLMs are good at coding or if they improve our productivity or not.

First things first, measuring productivity in developing environments is something really hard.

As an industry, sofware engineering has never found much consensus on many engineering practices, and there have always been teams able to outperform others by orders of magnitudes. So it feels just natural that, with AI as well, we have teams reporting wildly different outcomes.

This means that whatever your bias is about AI helping you (or not at all), you’ll get a study supporting it.

For example, you can read things like:

90% of our code is written by AI.

- Dan Shipper, founder of Every, on the Refactoring podcast.

But at the same time you can read some of the worst-looking numbers on AI productivity:

Developers thought they were 20% faster with AI tools, but they were actually 19% slower when they had access to AI than when they didn’t.

- METR, in their randomized control trial.

And if we look at developer’s and modeler’s surveys as we did in a past post:

84% of Stack Overflow’s respondents are using or planning to use AI tools but 46% actively distrust accuracy. As we can see in Gurobi’s survey, only 6% of OR practitioners are actually using it, with 24% experimenting with it.

GenAI is everywhere in the conversation, but as you can see just 30% of people are actually doing something with it. Still less adoption than in general development environments.

The truth probably lies in the middle: AI coding tools make us faster at writing code, but not necessarily better at thinking through logic. And optimization is mostly logic.

Only 6% of OR practitioners are actually using AI tools, compared to 84% of general developers planning to. Why? Because our work isn’t about writing more code faster, it’s about reasoning through constraints, trade-offs, and feasibility. LLMs can generate syntax, but can they truly understand this constraint conflicts with that objective?

In the previous project, I vibe-coded everything, and even let ChatGPT one year ago to code everything for the spreadsheets’ solver.

But this project was more about how to let agents get information and pass it to a solver rather than actually coding a model/algorithm to solve a problem.

To me, using Claude Code (and probably other agents like Codex Cli) for coding tasks will give you a boost in productivity. I mean, I did let Claude Code manage everything, then I continue doing other things, and when I saw it somehow finished, tried it by myself and iterate again if needed.

It’s like I didn’t need to spend time on testing something I wanted to test (can we leverage agents to automate solving optimization problems?).

But I admit that optimization code might require a lot of reasoning about constraints and trade-offs.

In optimization, our bottleneck isn’t typing speed, it’s reasoning speed. And that’s exactly where AI shows both its brilliance and its blind spots.

As I already used Claude Code for helping me in that regard, let me tell you a couple of things in the next section.

Subscribe now

🧩 What this means for my work (and maybe yours too)

Yes, I vibe-coded an entire thing without spending a lot of time actually coding.

It was more about giving context, my ideas, and how to connect the dots. Like I was just orchestrating Claude Code to actually do the job for me.

It all started some months ago, when I was skeptical about using AI to write my code. I tried it, and failed miserably. I thought AI would never be useful for coding.

At that point, I was just chatting with ChatGPT and/or Claude. It lacked enough context, so it couldn’t do its job well enough.

Then, I started to see its value. It was like “hey, it’s helpful; maybe not the best companion, but it gives you 80% of the code”. Not bad.

I gave better context to the chat, uploaded code, and some documents if I thought they were useful. The issue here is that it creates friction: you need to constantly update your code and documents to the chat project. But it can give you good results.

After that, I was so excited that I almost never read the code generated by AI. Just vibe coding. Tab, tab, tab. Apply, apply, apply. Run.

Then I moved to agents like Github Copilot coupled with GPT, Claude, or Gemini. It’s great as it has the context of the whole project (or at least a good summary of it), and lives inside VS Code, so the friction got removed. As a consequence, I applied more easily the changes done by the AI.

But I was disappointed. Debugging became #1 task. Also my #1 enemy. So much time and energy put here that I did a step back.

As a consequence of that ‘speed’ of coding, it created a lot of buggy code. The real problem is that as I didn’t audit the code that much, I spent more time debugging. And debugging code you didn’t write is a pain.

Finally, I looked at it with new eyes. If everyone was talking about it, “how come I couldn’t get barely any value from it?”. So I tried a different approach. And now with Claude Code, this is the approach I’m following:

1. Give Claude all the possible context I have so that I can understand if it understands everything well or if I lack giving it enough context.

2. Let it make a plan that I can edit if I think is not complete enough.

3. Let it code everything.

Everything looked like this:

As a note in the third point: I started by auditing every piece of code that it created. But the more I used it, the more I trusted it. So now I just audit all the changes it does at the end of the process.

But also: I don’t give it big tasks, just small ones -but big enough- that I know they’re needed for the project. That way, the agent can fully understand the tasks and increase the chances of doing it well.

Sometimes it gets cycled through the process of building something that fails, looking for the bug, trying to fix it, generate a different bug, trying to fix it, to get to the initial code.

When it happens, I stop using it and get my hands dirty. As I know what it did, it’s usually easy to catch the bug, but it could become hard if you don’t know what’s happening behind the scenes, so watch out: audit the code to understand it!

This way of working reflects a collaborative rhythm between human intuition and agent execution.

And I like it!

Optimization engineers like you might soon spend less time writing constraints, and more time deciding which problems are worth optimizing.

Agents aren’t replacing OR work, just changing the coding workflows. At least for now.

Share

🏁 Conclusions

Today I wanted to show you how to leverage coding agents like Claude Code to automate workflows embedding a solver in a part of the chain.

I could easily do it, getting an agent that can get data from an external source (in this case, the web browser) and inputting that data into a solver to get a solution.

The whole system works pretty well, and this way of working lets you define the problem and ensure the solution makes sense in the real world:

• Context first. Load notes, specs, sample data (when possible), and prior code until the agent can restate goals accurately.

• Co-plan. Let the agent propose a plan; edit it to set scope and success checks.

• Build small, ship small. Ask for self-contained increments (one tool, one interface, one test).

• Audit at the end. Review the diff holistically; run tests; profile the hot path.

• Break the loop. If it cycles bug→fix→new bug→new fix→old bug, take over, patch, and feed the fix back as context.

Now it becomes even more clear than ever that knowing what to build and how to evaluate it to increase trust in it will become much more important in the near future.

Today, AI can write and run the models we design. Tomorrow, agents might decide when and why to run them. That’s the next frontier.

That’s why next time, we’ll go one step further and explore what will happen with the OR field in this new context.

But for now, I’d love to know: how did you leverage Claude Code lately?

Let’s keep optimizing,

Borja.

🗞️ Other related posts people like

Let’s dive in! 🪂

1) 🤖 Vibe-coding AI agents to solve optimization problems

I’ve run a fast test.

I wanted to know how to embed an optimization solver into an AI Agent workflow.

So I used Claude Code (and tested Codex CLI, though not that much).

What it does:

→ Goes to LinkedIn

→ Opens the Queens game

→ Reads the board

→ Solves it

→ And clicks to place the Queens automatically

In its first try, it took 5 min 48 seconds to solve it, and after improving the workflow a bit, 1 min 02 seconds.

It’s not perfect yet, but it shows something powerful: how you can plug an optimization engine inside an LLM Agent.

The result: intuition from AI, rigor from OR.

2) 🎓 From academic to industrial settings

Moving from university to an industry environment can be difficult.

You don’t know how to translate business problems into math/algorithms, ship solutions, or communicate with stakeholders.

But next Wednesday 22nd October you’ll be one step closer to understanding that shift thanks to this Nextmv event:

3) 🎯 Suboptimal solutions are sometimes the best

A model is a simplification of reality, so it will not include all the details (by definition).

Also, an optimization model is an investment, so use it wisely to help you better understand the reality of your problem.

That’s why Jeff Cam reminded us that optimal solutions are not always the best ones.

Read more here:

Feasible

📈 #25 OR in action: why suboptimal solutions are sometimes the best

I've been dealing with a terrible spring allergy for a the last couple of days, and it's only the end of January…

Read more

2 years ago · Borja Menéndez

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

I don’t know if it’s the time of the year, but I wanted to do an update to those articles.

I think most of the blame goes to having read a research paper from Laura Albert et al. where they explore the same topic.

You guessed it right: I’m talking about the systemic issues that keep OR from mainstream adoption and how to improve the situation for our field.

We reached to similar conclusions, and that’s a good sign but also a reminder that knowing what to change isn’t the same as changing it.

So today in Feasible we’ll cover:

• 🛣️ Alignment (and where to go further)

• 🪛 The tools to make it happen

• 📝 An open letter to Master’s programs: introducing the Product Track

Are you ready? Let’s dive in… 🪂

🛣️ Alignment (and where to go further)

If you didn’t read my OR Reimagined series of articles nor the research paper, I strongly suggest you do.

But if you don’t want to spend time now, there are some points covered in them, like:

🪟 The accessibility and transparency gaps.

OR tools require specialized knowledge and there’s a steep learning curve; you can see that issue reflected on the many PhDs or advanced Master’s programs needed for the jobs.

Compare it to Machine Learning where you just need to import a library and 10 lines of code after that you can classify cats and dogs.

On the transparency, it’s ironic because OR is mathematically transparent but practically opaque.

There are some efforts on explainable optimization (XOpt) like expopt or the way some solvers like Timefold can structure the output to explain it better.

📜 The lack of marketing/storytelling. Most of the OR successes are invisible either because of confidential reasons (saving millions with route optimization is usually proprietary), or because the field itself is not widely known.

And in this latter part, the name may play a crucial role.

One year ago I argued we didn’t need a change on that part. Now I think we don’t need that urgently, as I don’t think it’s the primary reason for the lack of knowledge around OR, but it could benefit the field.

Anyway, it seems that OR’s wins are infrastructure: invisible when working, catastrophic when failing. It’s like plumbing: nobody celebrates good plumbing, but everyone complains when it breaks.

↔️ The theory-practice divide. This is also a crucial point: what academia studies is usually irrelevant for the industry.

So there’s a big gap between the two. I see four parts where it shows up:

1. Problem selection. Academia usually studies problems because they’re theoretically sound, but the industry asks for things like optimizing routes for 50 trucks with messy data, while drivers aren’t following the routes and customers are constantly changing their minds.

2. Solution approach. While there might be value in achieving optimality for some problems, if it takes 4 hours then it’s -most probably- less useful than getting suboptimal solutions in 5 minutes.

3. Model complexity. In academic settings, you’re responsible for your code, but in industry settings you’ll work within a team that need to understand your code, or even worse, you’ll leave the company some day and someone else need to take care of it. So usually, the simpler, the better.

4. Code quality. The industry needs to run those beautiful algorithms and models in production environments, not in a lab. So they need things like automated tests, data preparation, error handling, logging and monitoring, documentation…

There’s one point in the paper that, at least to me, needs a bit more clarification.

As I was reading it, it seemed that open-source ecosystems are the main reason ML succeeded and the main bottleneck in OR. And that we don’t have open datasets.

On the contrary, the field is full of really good open-source solvers like HiGHS, Timefold, or CP-SAT (from Google OR-Tools), and there exist open datasets for the most common problems like the VRP, QAP, or CSPs. You can see a list of 40 solvers and 9 datasets (or pages with datasets of all kind) in my Notion database with OR resources.

The bottleneck isn’t code availability anymore; it’s usable pipelines and shared, decision-centric benchmarks. We need something like the Kaggle for OR.

And all of those points are a diagnosis, but they’re not a cure.

As a summary, what I think now is that academia doesn’t prepare engineers enough to i) build models easily (and easy models neither) nor ii) productize those models for others (backend and/or frontend systems) to consume it.

So if we agree on why, the next step is how: what tools make this change possible?

🪛 The tools to make it happen

If you remember the Part II of OR Reimagined, I showed what are the missing layers when solving optimization problems, and I identified two specific layers.

🗣️ Problem definition.

There’s this usability layer where math-heavy frameworks dominate the OR world.

One of the main issues I saw when I started solving optimization problems is that you either needed big math foundations or big algorithm foundations. If we want to appeal to those outside our field as ML does, we need the “import a library and 10 lines of code after that you can classify cats and dogs” kind of thing.

But we don’t have that.

The most engineering-friendly modeling approach I’ve used so far is Timefold, and I’d be very happy to see more solvers like that one. Why? Because it lets every software engineer model optimization problems without being mathematicians or algorithms experts.

Instead of writing…

minimize ∑ c_ij * x_ij
subject to ∑ x_ij = 1

You can simply write…

(...)

private Constraint assignEachTask(ConstraintFactory factory) {
  return factory.forEach(Assignment.class)
    .join(Task.class, Joiners.equal(Assignment::getTask, Task::getId))
    .penalize(HardSoftScore.ONE_HARD)
    .as_constraint(”Assign each task once”);
}

(...)

The constraint is -more- readable.

The model itself is -more- testable.

And the developer doesn’t need a PhD.

♻️ Deployment: from prototype to DecisionOps.

DecisionOps is to OR what MLOps is to ML.

But we need similar things in this regard:

1. 🔢 Versioning and experimentation. Each model run tracked so we can compare solutions through different parameterizations.

2. 🧪 Testing. So that we can confidently develop new constraints or change them without fear of breaking everything.

3. 🔍 Monitoring. The thing needed to watch KPIs over time or performance degradation.

If you don’t want to write an entire DecisionOps pipeline yourself, you have proprietary tools like Nextmv and also open-source ones like Cornflow.

For both -problem definition and deployment- the tools exist today. What’s missing is connecting them into a reusable pipeline. The technology is ready; the mindset isn’t.

How can we change that?

📝 An open letter to Master’s programs: introducing the Product Track

The other day I let ChatGPT to do some research about Master’s programs worldwide. The output was pretty long, but it can be summarized as:

Graduates are highly employable for modeling and analytics, but a truly product-aware OR engineer usually layers on extra training in software engineering and business communication & product sense.

To be fair, that was my main hypothesis. In fact, you can see that reflected on this very same newsletter as I’m usually linking my posts to those topics. So…

If I could write one letter to any OR department in the world, it would say something like the following.

“Mathematical rigor and algorithmic excellence are our identities, our assets.

Those are the things for which companies pay a lot of money in every industry.

Cost savings, margins improvement, or reducing the carbon footprint can be achieved thanks to our specific knowledge.

We just need one more step towards offering the industry what it deserves: engineers able to build, ship, and adopt that knowledge in any organization:

🏗️ Build

The goal at this phase should be to translate optimization models into usable software. A mathematical model or an algorithm is not the same thing as having an optimization engine that can be connected to other parts of the software.

We can leverage tools like FastAPI or Flask to develop APIs so the models become callable, and if we stand to reproducibility as we do with algorithms, we should teach containerizing tools like Docker.

This is what moves algorithms from “it works on my machine” to “it works everywhere”.

🚢 Ship

The goal here should be to integrate the best practices from software engineering so that we can safely move the optimization engine to production environments.

We can include here things like automated testing with tools like pytest or Junit, and some CI/CD ideas to productize engines more easily with GitHub Actions and the like.

This will create a working pipeline that runs tests automatically before moving trustable code to production.

🪡 Adopt

The goal here should be to connect optimization outcomes to business language, including all the stakeholders in the conversation.

Clear communication through business KPIs and simple dashboards is key to explaining results to non-technical users.

Tools like Streamlit or Plotly Dash may help here.

In this Master’s program, the math and algorithms remain. The difference is that students graduate knowing how to put their models into motion.”

→ If you can’t wait for your university to build this track, build it yourself:

• Take a FastAPI course.

• Containerize one of your models with Docker.

• Develop tests with pytest.

• Setup CI/CD for automated testing with GitHub Actions.

• Build a simple UI that connects to the optimization engine and show results in Streamlit.

That way, you’ll get all the tools in your arsenal to be the OR Engineer that the industry is looking for.

🏁 Conclusions

One year ago, I described some of the most pressing issues in our field: commoditization, mindset, marketing, and practicality.

A couple months ago, Laura Albert et al. somehow validated it academically by identifying those issues and comparing Operations Research to Machine Learning. It can be incredibly useful, as long as we approach it with intention. They also suggested 10 actions to take to improve the situation.

Now I’m updating my thoughts and providing a path forward built on usability and education reform.

The tools exist. The education path is clear. Let’s hope everything aligns in the next few years.

But one of the tools we’ve seen today, DecisionOps -treating OR like software, with versioning, testing, and monitoring- deserves its own deep dive. I’ll explore that soon.

And then there’s Agentic AI. I’ve recently read about a job posting from one of the biggest retailers worldwide where they want expertise in OR and Agentic AI. Think it carefully: it’s a signal of what’s going to come. Agents are here to make automated decisions and assist users in a new fashion way. And those decisions will need OR at their core.

If we succeed, OR will become invisible for the right reason: not because it’s forgotten, but because it’s everywhere, powering the agents that reason, plan, and decide.

Let’s keep optimizing,

Borja.

🗞️ Other related posts people like

Let’s dive in! 🪂

1) ↔️ Comparing OR to ML

Machine Learning is -without question- far more popular than OR.

Yet the two fields are closer than they seem.

That closeness often tempts us to compare them, usually out of a desire for OR to gain the same visibility and recognition it deserves. I’ve done it myself. And just recently, Laura Albert and co-authors captured this feeling perfectly in their paper “Making OR more accessible: insights from the rise of ML”.

Having a role model like ML isn’t a bad thing. In fact, it can be incredibly useful, as long as we approach it with intention.

Instead of envy, we can use it as a mirror: to identify what’s holding OR back and to tackle those issues one by one, with a concrete plan.

2) 🗣️ OR in the age of ML

Even saying the name of our field can be a problem.

Operations Research.

It rarely speaks for itself. You end up explaining what it means: decisions, optimization, algorithms, complexity… and by the time you finish, the person you’re talking to is already thinking of something else.

And this isn’t just my experience. I’ve seen it happen countless times to colleagues too:

(click in the image to go to the post)

3) ⁉️ Should we rebrand the field?

The naming debate in OR isn’t just semantics, it exposes deeper challenges at the intersection of branding, professional identity, and market communication.

The appearance of new labels shows how the field constantly reframes itself to sound more modern and aligned with tech trends. But frequent name changes can also create confusion, rebranding fatigue, and even signal instability to outsiders. So the real question is: should we change the name at all?

But that’s only the surface.

Beneath it lies a much bigger problem: the lack of recognition that keeps OR from being understood, adopted, and valued.

What we face isn’t just a naming issue, it’s a marketing one.

And that’s where the next challenge begins:

how do we communicate OR in a way the world actually understands?

Read about the marketing challenges here:

Feasible

📈 #54 Operations Research reimagined (Part IV): marketing

Imagine walking into a room and introducing yourself as an "Operations Researcher…

Read more

a year ago · 3 likes · Borja Menéndez

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

But if you’re an Operations Research engineer, they often feel like background noise. Why should you care?

Because they reveal not only where the industry is going, but also the blind spots.

Taken together, they show how OR sits at the crossroads of software engineering and decision science.

The future of your career depends on three signals you can’t ignore:

• OR teams are growing while tech industry contracts.

• Python dominance + real-time decision needs = new skill requirements.

• The future belongs to OR engineers who can ship reliable production systems, not just build models.

That’s why today’s Feasible article will cover:

• 🎯 Why these surveys matter

• 📀 What the data reveals

• 🎓 What this means for your career

Are you ready? Let’s dive in… 🪂

🎯 Why these surveys matter

More than a decade ago, Stack Overflow did its first developer survey. Since then, it has grown from just a couple thousand respondents to dozens of thousands from more than 170 countries.

It shows where the broader tech ecosystem is heading in terms of tools, languages, and trends.

Gurobi, on the other hand, started its annual surveys back in 2022, and it’s a specialized view of optimization adoption and business priorities.

It reveals what’s actually happening in the OR industry.

They’re super relevant for our daily jobs, but neither tells the full picture: Stack Overflow underrepresents OR while Gurobi reflects its commercial solver ecosystem.

If you only focus on Stack Overflow’s survey, you might chase general dev trends that don’t apply to our niche as just a tiny fraction of respondents are optimization specialists.

But if you only focus on Gurobi you’ll see there’s nothing capturing the open-source ecosystem and that the entire survey focuses on Gurobi users and prospective users.

And our job as OR Engineers lies within that intersection:

So there’s a big value of reading both so you can cross-reference them to validate trends, identify disconnects between the more general dev world and the OR reality, and see where OR is ahead or behind broader tech adoption.

Having said all of this, let’s scrutinize them both!

(On top, if you follow me on LinkedIn you’d know I’ve been running some polls there. Nothing fancy, but they show where are we heading now.)

📀 What the data reveals

First thing to notice is: Stack Overflow1 received 49k+ responses while Gurobi2 received 473 (one of them, as you might guess correctly, is me).

Considering Gurobi is one of the most used (if not the most) and known solvers in the market, we could say that the number of total employees worldwide dedicated to Operations Research is around two orders of magnitude less compared to general development.

If we look beyond Stack Overflow and check sources like JetBrains’ Data Playground3, Shiftmag4, or Statista5, the global developer population sits somewhere between 20 and 47 million, with a previous projection of 28.7 million for 2024.

Let’s be conservative and call it 30 million.

That means Operations Research represents roughly 300,000 engineers worldwide.

I knew OR has always been a smaller world, but I didn’t see real numbers before.

So let’s look at the results.

📈 Confirming trends

There are some trends that go hand in hand. I’ve identified at least three of them:

🐍 Python’s absolute dominance.

As it’s the language for AI/data/backend, it’s jumped 7 percentage points in one year according to Stack Overflow. Gurobi says something similar as the vast majority of respondents (81%) prefer to program in Python. My survey goes in the same direction pointing at 87% of people using Python.

This isn’t just hype, it’s the reality across both general dev and OR-specific work.

🤖 The GenAI reality check.

84% of Stack Overflow’s respondents are using or planning to use AI tools but 46% actively distrust accuracy. As we can see in Gurobi’s survey, only 6% of OR practitioners are actually using it, with 24% experimenting with it.

GenAI is everywhere in the conversation, but as you can see just 30% of people are actually doing something with it. Still less adoption than in general development environments.

🔧 Collaboration tool preferences.

GitHub is more preferrable than Jira as Stack Overflow’s survey suggests. This is not directly measured in Gurobi’s, but 77% have small teams (2-5 people) requiring collaboration.

Model versioning through Git might be more valuable than issue tracking through Jira.

↔️ Revealing gaps

There are also some gaps or major differences between responses of one side and the other:

💼 Counter-cyclical hiring patterns.

We all know there are massive layoffs in the tech industry, but…

Read more

In other words: a curated list of news 🗞

🔍 Explainable Optimization (XOpt) brings transparency and trust to powerful models. Discover how it works inside expopt. Via Ilker Birbil.

🌍 GenAI and optimization are finally closing the gap between proven power and real-world adoption, and experts will remain vital for building, auditing, and governing these systems. Read it here. Via Tinglong Dai, David Simchi-Levi, and two more colleagues.

✨ Structured reasoning for LLMs is closer than you think thanks to this new framework. Via Sai Rajeswar.

⚠️ A reality check on NVIDIA cuOpt: demo technology or a true alternative to established algorithms? Via Vasiliy Zamolotov.

👥 A hand-picked list of optimization leaders worth following; honored to be included. Thanks Jerome!

Found something I should see? Send it my way and I’ll credit you next week.

In the meantime…

Let’s keep optimizing,

Borja.

Let’s dive in! 🪂

1) ⌛ Predicting runtimes

Yesterday I was debating with my wife about predicting running times in optimization problems.

(She’s a physicist working as Data Scientist, meaning she’s a very analytical person + know about Machine Learning algorithms, and has more optimization knowledge than the average person.)

Anyway.

I argued it’s a super difficult task, if not impossible, due to:

• the structure of the problem,

• parameterization,

• and even what you define as “solved”

…make it a moving target.

2) 🤔 Others on this

Curious as I am, I went digging and found an interesting r/optimization thread:

(click on the image below to go to the source)

3) 🏎️ The true driver of solver speed

Here’s a question I love to ask:

1. Would you rather solve a MIP with today’s solvers on a 1991 machine?

2. Or with 1991 solvers on today’s machine?

In other words: what matters more, hardware or software?

Here’s why I think software is the true driver:

Feasible

📈 #47 Why software is the true driver behind faster solvers

Two weeks ago I told you why NVIDIA’s solvers might be the future…

Read more

2 years ago · 2 likes · Borja Menéndez

A short overview of the most impactful surveys around optimization

Next Monday, I’ll share my take on two recent optimization surveys, including the State of Mathematical Optimization 2025.

I’ll cover 📌 what’s in them for you as an OR practitioner and 🧭 strategic implications.

If you care about how our work is evolving, you’ll want to read that one.

See you Monday!

PS: take a look at my first impressions to the Mathematical Optimization report.

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

Either users look at the plan and say “yes, this works”, or they dismiss it outright.

And often, the difference between trust and rejection doesn’t lie in the math. It lies in the data.

Three years ago, I learned the hard way I needed to spend more time on improving the data that feed our models. Our team spent months on building a system that consistently failed on giving good plans, and one of the reasons was because data had several issues.

That’s why I believe one of the most underrated responsibilities of an OR Engineer is owning the data that enters the model.

If you don’t own the inputs, you don’t control the outputs.

So today in Feasible we’ll see:

• 🔑 Why you must own the inputs

• 🧭 What data ownership really means

• 🛠️ How to put it into practice

Ready? Let’s dive in… 🪂

🔑 Why you must own the inputs

Optimization is unforgiving.

One wrong flag can invalidate an entire plan. It creates a domino effect difficult to stop.

Unlike Machine Learning, where noisy data just lowers accuracy, optimization collapses when data contradicts business reality.

But in most companies, data ownership is fragmented. Sales owns customer data. Operations owns asset and driver data. IT owns the pipelines.

And the OR team? We get whatever flows downstream.

This creates an “accountability gap” where:

• 🤷 Everyone owns a piece of the data, but nobody owns the fitness of the data for optimization.

• 📉 When the model produces bad solutions, upstream teams point to the solver. The solver points to the data, and the only thing left is distrust.

• 🙅 Users don’t care where the failure started, they only see that the plan doesn’t work.

And when a plan fails, users don’t say: “Ah, must have been the upstream data pipeline”.

They say: “This model doesn’t work”.

Prevent this by focusing on input reliability before algorithm sophistication. Instead of spending weeks perfecting algorithms to squeeze another 0.5% improvement, spend more time making sure the inputs are trustworthy.

It pays for itself: you’ll build faster, more reliable models that meet business constraints and win user trust.

The math usually favors ownership.

🧭 What data ownership really means

Owning the inputs doesn’t mean becoming a data engineer.

It means taking accountability for what the solver consumes.

And it can consume input in different stages, all of them breaking trust in its solutions.

I’ve seen several of them in the past few years, so let’s take a look at the most common ones with examples from logistics:

Read more

Let’s dive in! 🪂

1) 👑 The programming language of OR

Machine learning catapulted Python into default status.

There’s a huge ecosystem of libraries that make prototyping models and deploy production code effortless. When ML teams standardized on Python, the rest of the analytics world took notice.

Operations Research followed naturally. OR projects increasingly need data-driven pipelines and seamless integration with company data stacks. Python offers all of that in one place: mature OR toolkits, direct access to ML frameworks, and production-ready web frameworks for APIs.

The result is a faster prototyping, easier collaboration with data scientists, and a single language from data ingestion to optimization and deployment.

Python is the bridge between classical optimization and the ML workflows shaping modern decision-making.

2) 🙊 Which one are you using?

There’s one clear winner, but I’d love to hear your thoughts on this:

(click on the image to go to the post)

3) 🥇 OR-Tools wins again

Last Monday, the MiniZinc challenge announced its winners in different categories.

And without any surprise, the CP-SAT solver from Google OR-Tools won again:

It’s a powerful solver.

I’ve been using it for more than 3 years now, and I had a couple of things to say about it, especially if you’re looking for good documentation.

You can read the post here:

Feasible

📈 #76 Optimizing with Google OR-Tools: strategies and insights from three years of real-world experience

It was nearly the summer of 2020…

Read more

a year ago · 4 likes · Borja Menéndez

Are you the owner of your results?

That’s the same as asking if you’re the owner of the data that feeds your models/algorithms.

Because it’s common that users look at the plan and say “yes, this works” or they dismiss it outright.

And often, the difference between trust and rejection doesn’t lie in the math. It lies in the data.

Next Monday, I’ll share my thoughts on data ownership as an OR Engineer.

I’ll cover:

🔑 Why you must own the inputs
🧭 What ownership really means
🛠️ How to put it into practice

If you are using real-life data to feed your models, this will be useful. See you Monday!

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

It’s trust.

I’ve seen projects fail not because the model was wrong, but because stakeholders stopped believing in it.

We're so focused on mathematical elegance that we forget the human element. But here's the thing: in optimization, trust isn't just nice to have. It's everything.

And I’ll tell you a story that happened two years ago and shaped our current projects.

So in today’s Feasible post, let’s unpack three things:

• 🔑 Why trust is all you need

• ⚠️ 5 common sources of distrust

• 🌱 How to overcome them

Are you ready? Let’s dive in… 🪂

🔑 Why trust is all you need

Lower costs.

Better decisions.

Smarter resource allocation.

Optimization promises a lot, yet the most elegant model is useless if nobody believes in it.

Two years ago around these dates, the model we were building was at risk.

My team manager told me during the summer we needed a different approach.

My direct manager questioned our decisions on why and how that model was going to have a positive impact on the company.

The final user didn’t want to spend time with us understanding what we were building and was only saying there were a lot of things wrong.

That was a difficult situation. Yet the ongoing developments on that specific model is what we’re selling now as a simulation tool that can save a lot of money: it skyrocketed the margins of our company from negative to positive.

But with the right communication and changing the perspective of what we were doing at that time, we got the buy-in from the user and everything started to go smoother.

And all started with trust after looking at solutions more carefully. The model was uncovering some patterns from a strategic point of view of the company, and those insights were key to our success.

So let’s look at what that experience taught me:

⚠️ 5 common sources of distrust

Based on my experience and the insights shared by the OR community on LinkedIn, I could finally draw the biggest trust-killers in optimization projects.

💽 Data

You need to be able to demonstrate the quality and reliability of your data so that you (and final users) can trust solutions from your model.

It’s not just about testing whether you’re getting a null value or a specific date format, it’s about data quality.

If you feed your model with data that don’t represent the problem faithfully, then the output will be inconsistent.

National drivers assigned international routes. Routes that can only be done with double drivers assigned to single drivers. Box trailers assigned to routes that only accept cool trailers.

I’ll talk more deeply in a future post, I promise, as this is an interesting and important topic.

🗻 Big problems, complex scenarios

When you’re trying to solve an optimization problem, I bet you selected a big problem.

The bigger the problem, the bigger the impact, right?

(I used to think like that)

The issue with that approach is twofold. Bigger problems mean:

1. Many decisions in the process, so there’s a bigger risk of everything failing at once just because you couldn’t develop a tiny, little thing.

2. Difficult comparisons with other solutions, regardless whether they’re done manually or automatically with another algorithm (or the same one).

Which leads me to the next point…

↔️ Big differences with what users are used to do

Users have the operational knowledge of the company, they have the know-how of everyday business.

So when they’re presented a solution to a problem they fight every day, it’s common for them to look at it carefully.

The real problem lies when those solutions are extremely different to what they’re used to seeing.

That gap makes them easily reject new solutions, especially if they cannot explain them.

Which also leads me to the next point…

Read more

Consider these new posts on Saturdays your dose of OR discoveries without the time investment of finding them yourself.

In summary: a curated list of news.

Today’s a special edition. We’re going back to school, so now’s the time to get inspiration and learn new concepts!

🎨 Learning with visualizations is super powerful, especially when you’re on the way to learn complex algorithms. And if it’s in a beautiful manner, even better. I stumbled upon Learn Graph Theory by chance, and I see it as a great resource for learning graph theory (bet you didn’t see that coming). Thanks, Mohammed.

🎲 Speaking about beautiful visualizations, what about learning optimization with games? 13 games for 13 optimization problems that you will compare against the machine. Incredible work from Jonas Velasco. You can also subscribe to his newsletter!

🏭 Learning the fundamentals, the underlying mathematics, and practical coding examples of the industrial applications of mathematical optimization is great, and if it comes from a Decision Scientist at Amazon, even better. Donato Maragno just started a blog about that.

⭕️ To close the circle, let’s finish with visualizations that I found by chance too. Constant, logarithmic, linear, quadratic… What are they? You get it right: some categories of Big O notation. Click here to visualize them.

Found something I should see? Send it my way and I’ll credit you next week.

In the meantime…

Let’s keep optimizing,

Borja.

Let’s dive in! 🪂

1) 🌊 Good OR vibes

Having the right instructors at university can shape your career.

I know it first-hand as I started my OR journey because of that.

But when those instructors bring passion and excitement, that’s even more powerful. Recently, I’ve seen great enthusiasm towards OR in academic environments:

• Michael Watson is excited to teach Supply Chain Modeling.

• Jesper Larsen sees strong interest in OR from his students.

• Laura Albert shares her energy and excitement à la Michael Watson.

It’s inspiring to see this momentum for Operations Research, optimization, and decision-making, and I hope those good vibes continue like that 🤞🏻

2) 🚚 A CVRP challenge

The CVRPLIB team is launching a 30-day global competition to push the boundaries of the Capacitated Vehicle Routing Problem (CVRP).

What’s new?

• 100 XL benchmark instances: diversified and realistic, with 1,000 to 10,000 customers.

• A real-time leaderboard tracking both per-instance and overall progress.

• Certificates for the overall winner and for teams discovering new Best Known Solutions.

Key dates:

• 📅 Jan 12, 2026 → Competition starts (official XL instances released)

• 📅 Feb 11, 2026 → Competition ends

This is a rare chance to showcase classical algorithms, ML-based methods, or hybrid optimization approaches on one of the toughest CVRPs ever released.

Learn more and register

3) 🍕 VRP transforming logistics

Delivering pizzas around the city can be daunting.

Not only because of the competition with other pizzerias, but also because you can pick up power-ups to improve your speed or time.

Oh no, that was one of my favorite videogames back in the 90s, Radikal Bikers.

Anyway, it’s a complex problem as you need to take into account a number of factors like:

• The location of customers

• The capacity of vehicles

• The size of orders

• Traffic conditions

• Time constraints

The goal of the VRP is to find a set of routes that minimizes the total cost or time of the delivery operation, while satisfying all of the constraints.

But how can you solve it easily? And what applications of it are in the real world?

Read more here:

Feasible

📈 #12 From Pizzerias to Paramedics: How VRP is Transforming Modern Logistics

Radikal Bikers, a fast-paced motorcycle popular racing game from the late 90s, was a favorite of mine…

Read more

3 years ago · 2 likes · Borja Menéndez

Common sources of distrust in OR projects

Next Monday, I’ll share a crucial topic for Operations Research projects: trust.

Or, better said, sources of distrust.

I’ll cover:

🔑 Why trust is all you need
⚠️ Common sources of distrust
🌱 How to overcome them

If you’ve ever felt a lack of confidence in your optimization project or team, this will be useful. See you Monday!

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

I argued that the most successful OR professionals would be those who combine:

• deep optimization knowledge,

• with a product mindset,

• cross-functional collaboration skills,

• and a relentless focus on business impact rather than mathematical elegance.

It was an emerging role called Product Operations Research Engineer.

It could’ve been thought as wishful thinking, but I was spotting some initial patterns while reviewing job postings.

Then Waymo -the Google-born autonomous driving company- published a job posting that reads like it was lifted directly from my post. They called the role differently, but the DNA is unmistakable.

And this isn’t coincidence. It’s proof that the market is converging toward a role I said was coming.

Today in Feasible we’ll cover:

• 🎯 What Waymo got right

• 🎫 What they’re still missing

• 🤔 Why this matters for your career

Ready? Let’s dive in… 🪂

🎯 What Waymo got right

As Operations Research Engineers, we’ve been trained to master algorithms and mathematical models.

That feels like the right place to go. Our area of expertise. Our comfort zone.

But you know that after starting working for the industry, that doesn’t matter that much.

Yes, you need that expertise, and they hire you because of that, but overtime you realize that you need other things like:

• Owning problems, not just the model.

• Working cross-functionalily with product and ops teams, not in isolation.

• Thinking about adoption, usability, and KPIs, not just about optimality gaps.

• Building with users and even becoming one of them to understand their real pains.

There are quite a few reasons why is that the case, and you can read them in the post I wrote back in April this year:

And this transformation, the change in the perspective, is happening in real life. Waymo posted this summer an interesting job that aligns perfectly well with what I outlined.

The job description explicitly calls for someone who will "build models, measurement and decision making frameworks to make the best data-driven decisions" while collaborating "cross-functionally with Engineering, Product and Operations teams."

That’s powerful.

They want someone who can "think big picture, understand the broader business and product context and integrate it with model outputs to make clear recommendations." Sound familiar? That's exactly the business impact mindset and product context integration I emphasized as core to the Product OR Engineer role.

And the salary range of $196,000-$248,000 tells another story:

There’s a strong match on several parts: business impact mindset, problem ownership, and cross-functional ownership.

But there are a few gaps.

🎫 What they’re still missing

Waymo’s role represents about 70-80% of the full Product OR Engineer vision.

I see two specific areas of improvement here. Two areas that, if you master them, you’d be ahead of competition. Not only for this role, but for any OR-related role, because you cannot own the entire end-to-end pipeline of an optimization project without them.

1️⃣ The first one: they mention Python/SQL.

That’s pretty standard as you’ll need to retrieve information from a database and code something to solve optimization problems.

But there’s no explicit mandate for code quality, testing, or deployment pipelines.

And that’s a problem. A big one.

Applying TDD-like way of working for automated validation, techniques for making your code reusable and scalable, and CI/CD pipelines for model deployment will not make you just a better engineer, but a trustable one.

Those skills are needed for building trust, and it’s twofold: first, for you to trust you won’t break anything in future developments; second, for stakeholders to trust your solutions work.

You can read more here:

But that’s just half the story. The real gap -and the one that will define the best careers in the next decade- is missing entirely…

Read more

Let’s dive in! 🪂

1) 🎒 Going back to school

September is traditionally the month of going back to school…

And here I am! :-)

One of the first things I did was to upgrade the Notion database with Operations Research resources adding an entire new section: use cases.

They’re useful to find inspiration from similar problems, industries, or tools.

Here you can find my announcement.

I’d also like to take advantage of this publication to say a big THANK YOU if you subscribed during August (considering I didn’t write any. single. post).

Literally, dozens of you subscribed during this past month:

Most probably, you did it because I appeared in one of my favorite podcasts.

And speaking about that…

2) 📻 I was featured in The Decision Intelligence Lab podcast

I didn’t write any single word here.

Yet I appeared in one of my favorite podcasts: The Decision Intelligence Lab podcast.

Vijay, Mike and I talked about…

• Not developing for your users.

• The importance of testing your optimization models.

• And where to start when automating decisions at any business.

(among other things)

I encourage you to subscribe to the podcast here:

And why did I appear there? Well, Vijay found my ideas around the Product OR Engineer role powerful 👇🏻

3) 💭 Product OR Engineers

Algorithms, mathematics, chasing optimal solutions…

That’s what academia teaches us.

But that’s a small part of our work to deliver value to the business. What if your focus is on…

• 🎯 Having a business impact mindset.

• 🔥 Owning problems, not just models.

• ⚖️ Balance optimality with usability.

• 🧑‍🤝‍🧑 Build with users, not for them.

All of that, together with writing good software, is what you need to succeed in more integrated roles within organizations.

This shift reflects the transformation in software development, where engineers are taking on responsibilities traditionally held by product managers.

Continue reading here:

Feasible

📈 #70 Are Product OR Engineers the future of Operations Research?

I saw this many more times than I wanted (and I bet you did too…

Read more

a year ago · 1 like · 2 comments · Borja Menéndez

A proof of the Product OR Engineer role

Next Monday, I’ll share something I saw during August: a role that’s speaking directly to those who want to make a real impact.

It’s important because I talked about the Product OR Engineer role back in April, and now it’s materializing into job offers.

I’ll dissect the job offer for you so that you’re able to identify and match its requirements with the ideal candidate.

If you want to see the role of the future, this will be useful. See you Monday!

And that’s it for today!

If you’re finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version: if you aren’t already, consider becoming a paid subscriber. You’ll get access to the full archive, a private chat group, and 30% off new products.

Get the full version

2) 🤝🏻 Collaborate with Feasible. I’m always looking for great products and services that I can recommend to subscribers. Also, if you want to write an article with me, I’m open to that! If you are interested in reaching an audience of Operations Research Engineers, you may want to do that here.

Collaborate now

3) 📤 Share the newsletter with a friend, and earn rewards in compensation. You’re just one referral away from getting The Modern OR Engineer Playbook: Mindset, methods, and metrics to deliver Optimization that matters.

Refer a friend

If you have any comments or feedback, just respond to this email!

Have a nice day ahead ☀️

Borja.

To be honest, I didn’t think about it previously, so I started digging. I was vaguely aware of efforts by a couple of OR societies around the world, but I didn’t know the details: how the process works, how people actually volunteer, or what’s expected from them.

What started as a casual conversation has been a surprising window into how many people in OR want to make a difference, and how structured, impactful opportunities already exist, often hidden in plain sight.

The ability to apply our technical skills in a pro bono capacity can be incredibly rewarding, both for the volunteers and the organizations they support. OR professionals have a unique opportunity to leverage their expertise to create meaningful change in the world.

So today in Feasible, the article will be a bit different. Rather than write my own take, I decided to go straight to the source: I reached out to the leaders of two of the most active pro bono initiatives in our field, Pro Bono Analytics at INFORMS and the Pro Bono OR programme at The OR Society (UK), and asked them a series of questions about how these programs work, how anyone can get involved, and what kind of impact they’re making.

Below, you’ll find their answers… Clear, thoughtful, and straight from the people driving these efforts.

I hope this piece of content may help not only potential volunteers and the societies I mention here, but also encourage other OR societies around the world to do similar, as well as organizations to connect with the societies to look for some help in this regard.

Ready? Let’s dive in… 🪂

🇺🇸 Pro Bono Analytics (INFORMS)

Here’s the conversation I had with Victoria Chen and Paul Rubin. I knew Paul was part of the PBA project as he said that in his blog, and he rapidly pointed me out to Victoria Chen, who is the current Chair of the PBA committee at INFORMS.

Victoria’s responses have been very detailed and helpful, so you’ll find them here along with extra comments from Paul:

1️⃣ What are the 3 projects you're most proud of?

This a tough question because our Pro Bono Analytics (PBA) Committee members will have their own favorites. I can refer to completed projects with 3 nonprofit clients from which we have testimonials: Housed Working and Healthy, Mobile Integrated Health, Mentoring Mentors.

All 3 of these clients had multiple projects with PBA. There are also ongoing projects that are highly impactful, including one with the Georgia Criminal Justice Coordinating Council that is studying human trafficking, one with Neighborhood Defender Service that is studying bias in municipal court proceedings, and one with Taimaka that is studying malnutrition in children.

→ Comments from Paul:

I'll mention two of my favorites.

• We are winding down a project with Taimaka, an NGO that works to ameliorate the effects of pediatric malnutrition. They're working in Nigeria. Our volunteer team is helping them create statistical models and a dashboard to assist in determining which children to send home with nutritional supplements, which need follow-up care, which need to be admitted to a hospital and what their projected morbidity/mortality is. The work they are doing saves children's lives, and we are hopefully making it easier for them to do and potentially improving outcomes.

• One of the first projects I did was with Mentoring Mentors, a nonprofit in Baltimore that mentors young people, primarily people of color and primarily (I think) from economically disadvantaged communities. This was my first encounter with the term "social entrepreneur" -- someone who sees a need and starts a nonprofit from scratch to fill that need, roping in friends and relatives to get it off the ground and build it the point that they can raise sufficient funding to make it a stable venture. The founder, Alphonso Mayo, learned that he needed "analytics" to generate the sort of evidence required by funding agencies these days. He had no data and no idea how to get started, so he was profoundly grateful for the assistance we were able to provide, first in determining what data to collect and how to collect it, and then in analyzing the data. I'm in turn grateful to him, because he spread the word to his network of local social entrepreneurs and got us several additional projects (two with other mentoring organizations).

2️⃣ What kind of organizations typically benefit from Pro Bono OR?

One way to gather this information is to review the PBA Our Work page and check out the filter by Organization Type.

The most common is nonprofits that help vulnerable populations, including youth programs, health care programs, assistance for low-income families and homelessness.We have also served nonprofits in the arts, sports and recreation, conservation, and animal welfare.

3️⃣ What skills or backgrounds are most useful for volunteers?

The most common needs for nonprofits involve data collection, data management, and impact measurement.

It is a common misconception that a PBA project starts with data. The fact is that many nonprofits are unsure of what data to collect.

They know what impact they want to show, but they are unsure how to measure it. This is where a PBA volunteer can bring their experience to translate “impact” into metrics, define the desired data to obtain these metrics, identify available data, and determine if new data collection is needed and/or is feasible.

Once data are collected, then the analysis skills are needed, including the ability to display the analysis pertaining to impact in a manner that is easy for the client to interpret. Finally, data management skills are needed to organize these data and provide a process for continued data collection by the nonprofit client.

I would say that many projects handle only a piece of the process above.

Read more like this in the future

4️⃣ How much time do volunteers usually commit to a project?

It is up to each PBA volunteer to specify their availability, but a commonly stated amount is 5-10 hours/week.

Honestly, we do not have a shortage of potential PBA volunteers. We have thousands more volunteers in our pool than we have nonprofit clients. Each Call for Volunteers yields about 20 responses, and only 2-4 of them will be selected.

→ Comments from Paul:

I would say 10-20 responses, but I completely agree that potential time commitment does not seem to be a barrier to getting volunteers. Also, it is not uncommon for volunteers to drop off a project if the time commitment becomes too high or other aspects of life intervene, and we can always recruit more volunteers if needed.

5️⃣ Is there any training or support offered to volunteers?

We are currently working on creating better processes to on-board new volunteers.

In general, we try to create teams of volunteers, with each team member bringing different perspectives and different levels of experience. In general, volunteers that have work experience are already comfortable working with a variety of clients. Less experienced volunteers, such as students, can be included under the supervision of these experienced experts.

The challenges typically involve the “pro bono” aspect of the work, where there are not strict timelines or deliverables, so the urgency to keep on task, for both nonprofit clients and PBA volunteers, is absent.

6️⃣ Have any of these projects led to long-term collaborations or changes in the organizations?

We continually seek to retain prior nonprofit client connections, with varied success. The longevity of a relationship can been observed with the number of projects a client has with us (also seen on the Our Work page).

In general, clients know that they can reach out to us again in the future.

7️⃣ How do you usually find or select projects to support?

We have had a few outreach events sponsored by T. Rowe Price, in which they invite nonprofit organizations to a PBA webinar, and we have had in-person activities at the INFORMS Annual Meeting in which we engage with local nonprofit organizations at the meeting location.

Recent locations were Seattle in 2024, Phoenix in 2023, Indianapolis in 2022, and we are planning an in-person event at the Annual Meeting in Atlanta this year. Since we have been operating for several years now, word-of-mouth has also been a generator of potential projects, where a nonprofit can submit a project inquiry via our website.

As for the selection of projects, there are very few nonprofits that we turn away, but the primary criterion is whether or not analytics can help them. Because a nonprofit may not know how analytics could help, the first conversation is typically trying to understand the client’s needs and resources, then scoping an initial analytics investigation.

Usually, we can find a way that analytics can help.

→ Comments from Paul:

Referrals from satisfied clients has definitely been a source of projects.

8️⃣ Is there any advice you'd give to other OR societies looking to set up something similar?

I would advise trying to be flexible.

The individuals that are leading such as effort, in our case, the PBA Committee members, should have open minds. In our case, PBA started with the vision of helping nonprofit organizations analyze their data or streamline operations. However, the reality is that pro bono efforts have to start from the ground floor.

If a client stays engaged with us long enough, then a project can reach the analysis stage and possibly even the decision stage, but one cannot have that expectation up front.

Our goal is to help these nonprofits with whatever is best for them.

→ Comments from Paul:

I'd also advise other societies to check out our "sister" program in the UK, Pro Bono OR. Their model is a bit different from ours in some respects, in part because they tend to have more "in person" projects whereas our volunteers work remotely with very few exceptions.

🇬🇧 Pro Bono OR programme (The OR Society)

Paul gave me a very good last response as I already wanted to highlight the Pro Bono OR programme.

I had a conversation with Sarah Davies that led to raising the same questions to Isma Shafqat, the Pro Bono OR Manager at The OR Society. She went one step further and answered me in an already article-like style. I hope you enjoy it 🙂

Applying Operational Research to Support the Charity Sector

Charity leaders face a triple challenge: increasing costs, unpredictable demand, and emotionally demanding decisions. Many lack the specialist analytical tools required to navigate these complexities. The Pro Bono OR programme bridges this gap by enabling third-sector organisations to access expert help free of charge.

Since 2011, the scheme has engaged over 2,100 volunteer hours across more than 200 projects, benefiting charities big and small.

The types of organisations that benefit from Pro Bono OR are as diverse as the challenges they face. Most are small-to-medium charities and non-profits with limited internal analytical capacity but big ambitions to help people and communities. These include:

• Health and wellbeing charities, such as hospices or mental health support organisations, aiming to optimise service delivery or understand client outcomes.

• Education and youth services, working to track long-term impact or target interventions more effectively.

• Environmental groups, seeking help prioritising conservation efforts or improving resource allocation.

• Social justice and crime prevention charities, like Crimestoppers, which used Pro Bono OR to redesign its staffing model for efficiency and resilience.

• Community-focused causes, including food banks, bereavement support charities, and organisations tackling homelessness.

Who Drives the Change

The programme is structured around volunteers who are either ORS members, skilled analysts with relevant OR experience, early career professionals or postgraduate students endorsed by university supervisors. Projects vary in scale, from brief engagements to comprehensive six‑month engagements, typically requiring between 2-8 volunteering days.

From Kick‑Off to Close‑Out: How It Works

1. Finding Projects

Charities reach out to us by filling out an expression of interest and sharing their challenges with us. We draft project adverts on our website outlining their goals, data needs, and volunteer expectations.

2. Volunteering

Analysts sign up for project advert alerts, fill out the application, and are selected by the charities. Once matched, they convene with charity staff, develop a project plan, and set data and timeline expectations.

3. Working Together

During the project, volunteers apply core OR techniques such as data analysis, simulation, process optimisation, impact measurement, strategic planning—to help streamline operations, refine fundraising strategies, or measure social outcomes. The ORS supports each volunteer with handbooks, debrief tools, and QA resources.

4. Wrapping Up

Each project is formally closed with a debrief session, feedback collection, and a short case study written by the volunteer. Completed projects are often shared at ORS events, inspiring others.

Real‑World Impact

• Harvey Hext Trust, a small bereavement charity, gained a structured database from past invoices. The system now helps them measure outreach, identify gaps, and strengthen funding bids.

• RUHX, an NHS-related charity, used OR-led analysis to understand donor behaviour, enabling more targeted campaigns and improved engagement.

• Crimestoppers received a simulation‑based staffing solution for its call centre, reducing costs while boosting performance.

Testimonials:

“The ORS processes were seamless and smooth. We got what we were looking for, and then some. The final outcome was exactly what the NSPCC needed, and the training and upskilling provided have equipped them with a solution they can now use to accomplish things they couldn't do before."

• Kevin West, NSPCC

“Pro Bono OR’s modelling transformed our budgeting decisions—suddenly we saw clear paths through complexity.”

• Director, UK youth services charity

“As a result of support from Pro Bono OR, Contact has a much better understanding of the ethnicity of our service users; how it varies by entry point and area of the UK; and how it compares to the Census. The evidence informed our strategy planning process immensely”

• Silvia Laraia, Contact

“Their process‑mapping helped us halve our administrative burden.”

• CEO, Midlands food‑poverty organisation

Explore more of our case studies to see the impact in action.

While charities receive powerful insight for free, volunteers build new skills, gain cross-sector experience, and contribute to something bigger than a bottom line.

How to offer Pro Bono OR help

Thinking of setting up a similar scheme? The OR Society offers three key tips:

1. Start small but structured - Pilot a few projects with clear documentation and volunteer support materials before scaling.

2. Designate a coordinator - A part-time project manager is crucial to match charities and volunteers, track progress, and maintain quality.

3. Build visibility and trust - Run webinars, publish case studies, and partner with sector bodies to attract both volunteers and charities.

Most importantly, focus on mutual value - when both the charity and the volunteer grow from the project, success becomes self-sustaining.

Get Involved

If you are a charity looking for help with your data, please contact us by filling out this EOI form.

If you are interested in volunteering, please sign-up to our mailing list to receive regular project updates.

Isma Shafqat
Pro Bono OR Manager

🙌 Final thoughts

Volunteering in OR may not be as visible as other career paths, but it’s deeply meaningful, and it's already happening in structured, impactful ways. These initiatives show that there's room for everyone to contribute.

I hope this article serves as both a guide and a spark:

• A guide to understand what volunteering in OR looks like today

• A spark to help more societies, individuals, and nonprofits see the potential in this kind of collaboration

If you know of other pro bono OR efforts, or have participated in one, I’d love to hear about it. Just reply to this email or message me directly.

And if you want to explore more about these programs, go to the Pro Bono Analytics and Pro Bono OR pages.

Let’s keep optimizing,

Borja.

🗞️ Other related posts people like

All models are wrong, but some are useful.

George E. P. Box

The usefulness of a model lies in that fine line that separates if the model can solve the problem in a reasonable amount of time or not, and it comes with -lots of- challenges.

After taking a different approach on a problem I tackled, I reduced the needed time by 50% and improving the number of best solutions found by 3x. Just by looking at it from a different perspective.

That was revealing.

So today we’ll see in Feasible:

• 🪨 Understanding is the hard part

• ⚙️ Tractability drives our careers

• 🛠️ …And the way we work

This is not only the last part of the 6-post series about tractability, but also the last deep dive until I come back from vacations until September. If we don’t have the chance to speak again, have some wonderful weeks!

Are you ready? Let’s dive in… 🪂

🪨 Understanding is the hard part

Let’s go back to September 2015.

I almost didn’t arrive to my destination, but two people were waiting for me in Lorient. Sunny day, even better than in Madrid. And there I had my supervisor for the next three months and a PhD student I knew through one of my girlfriend’s friends.

I was there to solve the Minimum Sitting Arrangement Problem, and I must admit I did just read the paper of reference while on the train from Paris to Lorient. I didn’t even speak English properly, and French was a pending subject.

The thing is I wanted to use a similar approach with this problem as in the previous ones I tackled. In the end, it was a good one!

But this problem was different.

Instead of being just a pure combinatorial issue, you could spot patterns of what good solutions would look like. You could imagine nodes connected among them, and plot them with GraphViz or a similar tool. Why? Because here we needed to arrange a graph into a line to minimize the number of errors. These errors occur when elements with negative connections are closer together than elements with positive connections in the arrangement.

The problem was easier to think about, but still difficult to tackle: there were many solutions

After a couple of meetings with my supervisors, I took a different approach.

Instead of just relying on VNS entirely, I added a new first phase to analyze the problem and solve an easier one. I could split it into cliques with those negative connections, and then solve the problem of connecting those cliques in the best possible way.

This allowed me to reduce the computational time by half but also solve some instances to optimality, multiplying the number of best solutions found by 3x.

This experience was a big lesson: if you can reframe your problem and look at it from a different angle, you’ll take advantage of its structure and solve it easily.

⚙️ Tractability drives our careers

When we’re solving our optimization problems, we expect to have a solution in a specific period of time.

Well, even more than that. We expect to have a high-quality solution in a short period of time.

(that’s better)

But sometimes we don’t get that, and we may get frustrated.

Understanding tractability changes what we do first, what we ignore, and how we sell results.

Throughout the course of this series, we’ve learned several things:

📊 The importance of benchmarking

When you have a model or algorithm that usually solved in 10-15 minutes but suddenly broke when making the problem bigger, what do you do?

Is it a problem of scale? Structure? The algorithmic approach? Simply hardware?

You shouldn’t guess it, but profiling the execution of your model so that you understand where it comes from. We learned in the first part of this series we need to measure CPU time, solution quality, and memory footprints if possible.

Those metrics will give you enough information to start solving the tractability problem.

I also shared with you one prompt to let AI interpret the logs for you (very useful!), and a flowchart to simplify the way you address this and detect where the issue comes from.

Benchmarking is crucial to understand your next steps.

🚀 Scaling will change the way you solve your problems

Working at a startup forces you to think out of the box quite a lot of time.

When we were managing around 120 trucks, they asked me if we could use the very same approach as of today’s if we had 1,000 trucks instead. The answer: “of course not!”.

We wouldn’t have that scale of the business in a short period of time, that’s true, but it also sparked some ideas on how to handle the problem in the future. The complexity lying under a problem with 100 trucks is not the same if we multiply them by 10.

The problem of assigning drivers to routes grows almost quadratically with the number of routes. Add it relay points to split a route into different segments, and instead of having just one route you have 2, 3, or even 4 segments of routes in the worst-case scenario. This means that the problem is significantly harder to solve.

So in the second part of this series we saw four ways of tackling this large-scale optimization problems, being heuristics and metaheuristics my preferred way of working.

Anyway, I always try to reduce the granularity of the problem before diving into them.

🧱 Many similar solutions will reduce the performance of your solver

Symmetries make the search space artificially bigger, complicate the way we compare solutions, and thus make it harder to find the best possible solution.

But how? They multiply the number of equivalent solutions.

The good thing is that many others in the space have studied symmetries already, and we saw in the first part of symmetries sub-series the types of symmetries and classical algorithms to tackle them. In the second part though, we saw advanced techniques, some of them reserved to the most advanced solvers in the market. And in the third part we saw ML-guided techniques that seem to be promising.

But remember: symmetry breaking constraints add memory overhead, so sometimes it’s better to just accept longer solve times than exceed memory limits.

Or…

⚖️ Not all the typical algorithms are easily parallelizable

You and I know we’re not here to lower our arms and accept we cannot solve the problem.

That’s not in our DNA.

So another way of breaking the limits is by parallelizing our algorithms. That will give us the possibility of either explore a wider portion of the search space or reduce the computation time.

The main problem? We cannot -easily- parallelize all the algorithms.

Algorithms with minimal communication between threads, independent progress, and that aren't overly sequential tend to be the best candidates. Parallelizing these can lead to meaningful speedups or the ability to explore more of the search space.

In the fourth part of this series, we saw the worst and best algorithms to parallelize, and some techniques to do it.

💻 The typical ‘throw more hardware’ may not help you here

In 2019, I started working for Fujitsu to use their quantum-inspired hardware to solve optimization problems.

It was quite promising: a process that took more than 2 hours could be solved in 5 minutes. That’s not theory, it’s something I could develop for the very first proof of concept we ran.

But if we have that speedup with just quantum-inspired hardware, is there any hardware better than CPUs to solve optimization problems? Why we’ve been stuck with them all this time?

In the first part of this sub-series about hardware, we explored why CPUs are tailor-made for optimization work, that there are workloads that break the “CPU only” rule, and CPUs are hitting their own ceilings. Which leads us to exploring other hardware approaches to solve this difficult problems.

Which ones? Apart from Digital Annealer, the quantum-inspired hardware from Fujitsu, we can see others. The most promising ones: quantum (not inspired, the real one) and GPUs.

The right question here is when should you consider alternatives?, and that’s something we talked about in the second part.

🛠️ …And the way we work

The tractability mindset isn't about learning new skills, it's about fundamentally changing your approach to optimization problems.

To me, there are three major changes in the way I work after tackling so many difficult problems:

🔢 Selecting a solver

It’s easy to fall into the trap of “Gurobi is the best solver, let’s use that”.

But if you analyze your optimization problem, you’ll understand that some algorithms are better suited than others to solve it.

This is not a race of knowing more and more solvers, but about matching problem structure to algorithmic strengths.

🗣️ Communicating the issues

When you face tractability issues you easily see the main symptom: the problem is becoming more and more difficult to solve. A process that used to take 10-15 minutes become more than one hour.

How do you communicate that to stakeholders? The wrong choice is just “the optimization engine is slow, we need more time for running it”.

Better: “we’re hitting multiple equivalent solutions, so we can try to solve this issue or accept suboptimal solutions in that 10-15 minutes range”.

You’ll need to communicate root causes and strategic choices, not just symptoms.

✅ “Good enough” is good enough

The main metrics we’re taught at university is gap thresholds (for exact approaches) or deviations from the best possible solution (for heuristic approaches).

That only speaks about optimality.

And you know the number of stakeholders that cares about that in the industry? Exactly, close to zero, null, zéro, ninguno.

So if you see that your current approach saves a good amount of time or a good amount of money (extra points if it does both things at once), just ship it. You’ll have the chance to improve it later while saving time/money in the meantime.

🏁 Conclusions

Tractability thinking changes your problem-solving sequence:

Old sequence: Model → Solve → Scale → Debug performance New sequence: Understand → Simplify → Model → Solve → (Scale only if needed)

Most "hard" problems become "easy" problems when you find the right simplification. And most scaling challenges disappear when you're scaling something that's already efficient.

This is what changes with tractability mindset: not the individual skills, but the strategic approach to applying them.

Let’s keep optimizing,

Borja.

🗞️ Other related posts people like