in defense of model complexity

Recently I wrote a post in defense of model simplicity. I liked a lot of things about that post, but it wasn’t the entire picture. Much of what we do in operations research deals with solving complex problems, and often we can’t settle for anything simple. Simple models can be incredibly useful, but they are generally useful when we are looking at a piece of a system without so many moving parts. Do we make a credit card offer to person X? Yes or no? An educated guess will suffice. A model (simple or complicated) that replaces that educated guess can be a big improvement. But the decision context is inherently simple: we need a model that tells is yes or no.

Operations research does so well when we need an answer to a complex problem with many interconnected parts. Case in point: it’s hard to find a feasible solution in many optimization models (capacitated facility location, scheduling models, vehicle routing problem with time windows, etc.). It’s trivial for finding a feasible solution to a yes-or-no problem

The last two semesters, I’ve team taught an introductory course for engineering freshmen on engineering grand challenges. Nearly all Wisconsin engineering students are admitted to the College of Engineering without a major (they are in a “general engineering” curriculum for the first year), although this is starting to change this year. One of the goals of this course is to introduce the students to different majors. I am in charge of Industrial and Systems Engineering. I have to talk about operations research, manufacturing, and human factors (confession: I really struggle with human factors). I’ve gotten better at telling 18 year olds about why industrial engineering is so cool. I’ve found that using a few examples is the best way to make this point.

(1) My favorite example is explaining why Major League Baseball scheduling is so hard (thanks again Mike Trick! Read more here and here) This example is so intuitive to so many students because they understand the many constraints:

• 30 teams with 162 games each
• half home games, half away games
• each team must play each other a given number of times
• a team cannot play too many away games in a row
• travel distances matter: a team can’t fly across the country all the time
• television revenue make some schedules more attractive than others
• teams play each other, so you can’t fix a part of the schedule in isolation: everything affects everything else
• you finally get a schedule you like, and then the Pope asks to visit New York and needs to be in a baseball stadium the day a game is scheduled, forcing you to reschedule the season.

(2) Scheduling people for work shifts is another problem that needs complex models. Decisions are discrete (you work the 8AM shift or you don’t), and there are many constraints, such as hour limits per week, block structure schedules, consecutive scheduling problems, union rules. Paul Rubin has a great blog post on scheduling instability:

The multiperiod nature of scheduling models tends to make them a bit chewy, especially when you need to coordinate schedules of multiple individuals (or machines, or venues) across blocks of time while dealing with multiple constraints and possibly multiple conflicting criteria. Not all complex models are optimization models.

(3) Awhile back, I blogged about an article in Nautilus about optimization and trucking [Link and Link] all about the difficulty in coming up with useful models for effectively delivering goods by truck. For the models to be useful, they need to account for many rules (like breaks) and the human behavior of the truck drivers. The resulting models are pretty complex.

There were union rules, there was industry practice. Tractors can be stored anywhere, humans like to go home at night. “I said we’re going to need a file with 2,000 rules. Trucks are simple; drivers are complicated.” At UPS, a program could come up with a great route, but if it violated, say, the Teamsters Union rules, it was worthless. For instance, time windows need to be built in for driver’s breaks and lunches.

(4) Thus far, I’ve only used scheduling and routing examples with a lot of interconnected parts. But those aren’t the only models that require complexity. My interest in public sector operations research has led me to appreciate so-called “wicked problems” (as opposed to “tame” problems). Wicked problems often addresses the soft side of operations research and is a defense of model complexity. Due to the social component of the problem, there are many stakeholders with contradictory needs. A problem that is wicked quickly unravels due to the connections it has to other issues that are also social, and so on. Russell Ackoff summed this up nicely:

“Every problem interacts with other problems and is therefore part of a set of interrelated problems, a system of problems…. I choose to call such a system a mess.”

I recommend C. West Churchman’s guest editorial in Management Science in 1967, where the term “wicked problems” was coined [pdf: Wicked Problems Churchman 1967] and this nice article on “wicked” problems by John Mingers in OR/MS Today.

Do you have a favorite complex model for a wicked problem?

Related reading:

• Planning problems are wicked problems
• Major League Baseball scheduling at the German OR Conference
• the craft of Major League Baseball schedule from 1982 until today
• engineering grand challenges that operations research can help solve
• optimization and unhappy truckers