Adam DeJans Jr. describes the technical approach he uses, regardless of whether the tool is for optimization, ML, simulation, or even a rules engine: Link

“I start by modeling the decision, not the outcome.

That means explicitly writing down:
what is chosen, when it is chosen, what information is available at that moment, and what can be revised later. If you can’t answer those four questions cleanly, no amount of math will save you. Many systems silently assume perfect information and one-shot decisions, which is almost never true.

Next, I separate constraints into three classes: physical, policy, and preference.

Physical constraints are inviolable. Policy constraints are negotiable. Preferences are directional, not absolute. Most failures come from collapsing all three into hard constraints. The moment uncertainty hits, the system snaps. Introducing slack, penalties, and priority ordering is not “watering down” the model, it is acknowledging how decisions are actually made.

Then I intentionally stress the formulation.

I perturb inputs, loosen bounds, shift weights, and rerun. I’m not looking for a better answer; I’m looking for stability. If small changes in assumptions cause large swings in decisions, the formulation is overfit to a fictional world. A technically sound system should fail softly and predictably.

After that, I tune tolerances to meaning, not precision.

Numerical exactness is rarely the objective. What matters is whether two solutions are operationally different. If a system reacts violently to microunits, rounding, or noise, the issue is a mismatch between the mathematical surface and the business reality.

Finally, I design for iteration.

Any system that pretends it will be “right” the first time is already wrong. Decisions are revised, data improves, and incentives shift. The goal here is controllability over time. Systems that can be nudged outperform systems that demand obedience.

This approach applies whether you’re planning inventory, pricing products, allocating budgets, staffing teams, or tuning an ML pipeline.

The math matters. The algorithms matter.

But the dominant technical skill is learning how to build systems that survive contact with reality.

Welcome to engineering.”