Geoffrey De Smet

The through-line

Across these sources, Geoffrey De Smet keeps returning to one problem: schedules that look fine are often quietly wrong, and the hardest part of planning optimization is finding the failures nobody notices. In 2026 posts this shows up as false negatives in shift schedules that "silently drain money from your company" [2] and a 10-year-old solver bug that "didn't throw an error" and went undetected by code reviews, AI screening, and tens of thousands of users [10]. This is a continuation of a much older preoccupation: his talks describe building constraint solvers, from OptaPlanner's early days through elevator maintenance and school timetabling, that must balance many competing constraints to find schedules humans would call "optimal" but often aren't [16][17]. What has shifted is the frame around it: what started as an open source project judged by academic benchmarks [18] became a company, Timefold, now selling the discipline of validating and running solvers at production scale [4][5][11].

On false negatives and hidden bugs

De Smet's core insight is that errors in scheduling systems are asymmetric in visibility. "False positives are easy to identify. False negatives are not." [2] He illustrates this with the free-gift analogy and then applies it directly to automated scheduling, where "most false negatives go undetected" and "silently drain money from your company, with their suboptimal schedules" [2]. He backs this with a real example: a decade-old bug in Timefold Solver that caused one dataset to not actually optimize, costing an estimated "$2,855" in one case and "a far bigger dataset, with a far bigger price tag" in another, all while passing code review and going unreported by customers and open-source users alike [10]. His conclusion is practical rather than alarmist: "Luckily, with our platform, it's now easy to detect such issues." [10]

On benchmarking and validation

He treats benchmarking as a discipline that has to evolve with scale. Early on, "we benchmarked a new algorithm ... on our laptop on a number of datasets. If it's statistically better, release it. Like academic papers, basically." [5] As the solver spread globally, that approach became "a liability" because "a change might improve in one use case, it could regress in another," so the team moved to cross-use-case benchmarking, even though doing it on laptops proved "impractical, unreliable and irrelevant" since "production environments don't run on M-series Macbooks." [5] He explicitly frames avoiding regressions as a priority: "We actively avoid regressions." [5]

On the puzzle nature of scheduling

De Smet likes to explain scheduling by analogy to puzzles ordinary people already understand. "Shift Scheduling and Sudoku have a lot in common. In both cases, you're solving a puzzle to find the optimal solution." [13] He uses a Sudoku mistake to show how one wrong early assignment can leave a solution "95% of the puzzle" filled in but "only 65% correct" [13], then contrasts the two domains: in Sudoku a broken hard constraint is obvious immediately, but "in Shift Scheduling, you'll only find out 100 assignments later. And you might not know that there's a better solution." [13] The same interdependence shows up in his description of shift creation versus shift assignment: "Shift creation and shift assignment are two sides of the same coin," since demand-matching favors small shifts but "nobody wants to commute to work for a 2 hour shift." [15]

On scaling a scheduling business

He frames Timefold's growth in terms of scale and infrastructure choices made deliberately, not out of necessity. "Running a solver in production is one thing. Running thousands solvers every day reliably is another." [4] He's explicit that the technology isn't locked to one vendor: "Timefold Platform, runs on all major clouds," with GCP chosen for enterprise requirements like "uptime, data residency, security, reproducibility, monitoring, SOC2, ISO 27001, GDPR" [4]. He also states the mission in blunt terms tied to the company's funding: "13 million dollars to free the world of wasteful scheduling," aimed at not wasting "company time," "employee time," or "planet time" [11], with the API layer already handling "over 1,000,000 visits and 2,000,000 shifts per week" [11].

From the stage

In his talks, De Smet goes further into the technical and historical texture that the written posts skip. At Devoxx Morocco he uses the Traveling Salesman Problem and a real-world American road trip example to show constraint-solving algorithms beating published "optimal" solutions by reducing travel time, and separately describes an elevator maintenance scheduling case balancing customer preferences, maintenance intervals, and penalty fees across the globe [16]. At Bordeaux JUG he demonstrates building a school timetabling application "from scratch" with OptaPlanner on Quarkus, assigning lessons to time slots under teacher and student availability constraints, and connects this to job shop scheduling, equipment scheduling, and vehicle routing as instances of the same underlying approach [17]. In the Timefold interview he traces an "18-year journey" from an open source project that earned recognition through academic competitions and real-world use cases, including NASA suppliers, to becoming OptaPlanner at Red Hat in 2013, and finally to founding Timefold with co-founder Maarten [18].

Takeaways

• When auditing a scheduling system, look specifically for false negatives, not just false positives, since suboptimal schedules rarely throw errors [2][10].
• Don't trust laptop benchmarking once a solver is used across many use cases; a change that improves one case can regress another [5].
• Treat shift creation and shift assignment as coupled problems: optimizing demand curves with small shifts can conflict with employee preferences and labor law constraints [15].
• A scheduling model can look complete and still be wrong, the same way a Sudoku can be 95% filled in but only 65% correct if an early assignment was mistaken [13].
• Build infrastructure for production reliability (uptime, data residency, SOC2, ISO 27001, GDPR) as a deliberate choice, not an afterthought, once solvers run at scale [4].
• Long-lived bugs can survive code review, AI screening, and thousands of users undetected; dedicated tooling to catch non-optimizing runs is worth building [10].