Geoffrey De Smet

Geoffrey De Smet's public writing over the past year traces a consistent arc: scheduling optimization is deceptively hard, failures are more instructive than successes, and the discipline of proving quality matters as much as the algorithms themselves. He returns again and again to the gap between a solver that looks like it works and one that actually optimizes well, and he is unusually candid about how that gap gets discovered.

The clearest thread is his evolving view on benchmarking. He describes how his team originally validated new algorithms the way academics validate papers: run it on a laptop, check if it's statistically better, ship it. As the solver spread across industries, he says that approach "became a liability: while a change might improve in one use case, it could regress in another." Benchmarking across many use cases on laptops turned out to be "impractical, unreliable and irrelevant... because production environments don't run on M-series Macbooks" . This is a rare instance of a vendor admitting their internal QA process was inadequate for years before fixing it, and it frames much of his other commentary about needing real infrastructure, not intuition, to trust an optimizer.

That theme sharpens considerably in his account of a decade-old bug. He frames it almost as a confession, joking that his solver runs "ransacked the neighborhood search and misused company property," before revealing that a specific dataset "didn't actually optimize" due to a bug tracing "all the way back to early OptaPlanner times." What stands out is his insistence that every existing safeguard failed: "None of our code reviews saw it. AI screening didn't catch it. None of our customers reported it. Nor any of the tens of thousands of open-source users." He quantifies the cost precisely, "38% less travel time. 57 hours and 6 minutes. At $50 per hour, that's a loss of $2,855," and notes it wasn't isolated, "at least one other dataset" had the same problem at larger scale . The lesson he draws is not that testing is impossible but that opaque optimization needs better tooling to catch silent underperformance, which he ties directly to the platform's new detection capabilities.

He is fond of everyday analogies to explain why scheduling is unintuitive to non-specialists. Comparing shift scheduling to Sudoku, he notes that a wrong early assignment can still let you "fill in 95% of the puzzle" while being only "65% correct," and highlights the harder problem in real scheduling: "you'll only find out 100 assignments later. And you might not know that there's a better solution" . This same instinct for concrete, numbers-driven demonstration shows up in his what-if scenario posts, where he takes an open-source conference-scheduling quickstart and shows measurable trade-offs, like relaxing "theme track room stability" to reduce "content conflicts" , and in his framing of shift creation and shift assignment as "two sides of the same coin," pointing out that demand-driven scheduling wants small shifts while labor law and worker preference push against them, since "nobody wants to commute to work for a 2 hour shift" .

His talks going back years show these convictions were present from the start, not newly acquired. Early presentations on OptaPlanner used road-trip optimization and elevator maintenance scheduling to argue that constraint solvers can outperform published "optimal" solutions once real-world constraints like customer preference and penalty fees are modeled properly ¹⁵, and his school-timetabling demonstrations made the same point about balancing hard constraints like availability against soft preferences ¹⁶. The throughline from OptaPlanner to Timefold, as he describes it, is an 18-year effort to take planning technology from an academic-competition curiosity to production infrastructure used by everyone from NASA suppliers onward ¹⁷.

On the broader failure of operations research as a field, he is blunt that this is not just a Timefold problem. Citing a EURO Practitioners' Forum panel, he notes industry-wide project failure rates, worse than IT's already troubling one-third failure rate, and describes the mood among veteran OR practitioners as feeling "like an AA meeting" . Yet he pairs that candor with real conviction that the field's upside is enormous, pointing to its "direct impact on the daily operations of railways, drugstores, transports, factories" . That same optimism underlies his framing of Timefold's mission in commercial terms, describing new funding as capital "to free the world of wasteful scheduling" across company time, employee time, and "planet time," with the shorthand "Better schedules = better planet + better work + better life" .

Taken together, his public statements read as a practitioner's argument for humility paired with ambition. He wants people to understand that scheduling problems are combinatorially brutal and that even mature, widely deployed solvers can silently underperform for a decade without anyone noticing . But he also wants to demonstrate, concretely and with real numbers, that better infrastructure, better benchmarking discipline, and tools that let users run their own what-if scenarios can close that gap. The concrete takeaway from his own words is that trust in an optimizer has to be earned through visible, production-realistic validation, not assumed from a good demo or a statistically significant laptop benchmark .