Thing#1:
Linear programming is not magic; we all do it.
Imagine any situation where you need to choose a collection of things to satisfy some goal, but there are some constraints on the choices. A “ little bit of column A, little bit of column B” kind of situation.
Say you’re choosing lunch at a buffet. (Does anyone go to buffets anymore?) You want to minimize calories, but you want a variety of colors on your plate, with good balanced nutrition — which items do you choose, and how much of each one?
This is a linear programming problem.
Really? Yes. This situation can be expressed as a linear program, because the the result you care about, say it’s the total calories on your plate (linear programming geeks would call that the output) is proportional to the decisions you can make, the amounts you take of which foods you choose. The linear programming geeks would describe the food characteristics as the parameters of the problem, and they’d call the choices you actually make the input, or the variable the solution will determine.
Here’s what that buffet situation looks like expressed in math:
[include correct mathematical formulation here]
And in AMPL [add link to AMPL.org, and a footnote], a freely available language for working on these kinds of problems, the situation could be expressed this way:
[include a correct AMPL program, both model and data files, here]
And then you see the dessert table, and you reconsider your choices. You simply must include a slice of pie, but which one? And does that mean you should get more salad instead of that second piece of fried chicken? Now you’re iterating on the solution of your linear programming problem, having modified your model to use the latest and greatest data available.
Yup, it’s not magic, it’s just everyday bread and butter (and broccoli and beans and lemon meringue pie). But expressed in math.
Thing#2:
Linear programming problems can get really complex really fast.
With only a few choices, and not many constraints, a linear programming problem can be solved by a human, even using simple geometry.
[link to an example problem here. Separate blog post]
But very quickly, adding just another variable or two, the problem can outstrip our ability to visualize it, and our patience at dealing with all the variables and their interactions is stretched too thin . We throw up our hands and make a choice based on gut feel, or we dramatically simplify our thinking about the problem and call our solution good enough. [add link to an explanation of satisficing]
But linear programming can handle many many variables, with a complex mix of constraints. And the same program can be run repeatedly, with different data each time, so that the solution dynamically adjusts to changing conditions.
But there’s a catch … a big one. That’s the third thing.
Thing#3:
Linear programming is only a model — an approximation of the real situation.
The linear program is a translation, an approximation, of the real and messy problem into clean sweet solvable math. And that translation is done by humans. Humans (or a team of humans) that understand the real situation and the math and the programming language. That means that it might not be correct enough, especially in its early versions.
And the solutions have to be translated from math back into human, for the humans to use those solutions (or to reject them in order to improve the model … more on that below)
Eventually, the model expressed in the linear program must be close enough to the real situation to be useful. (Like most humans, linear programs aren’t very useful when they are first deployed.) The alignment of each model with reality is improved through iteration.
[add a section, maybe a sketch or a cartoon strip, illustrating the process of iterating the model. Try to incorporate cartooning with a flow chart. ]
In the best of all possible worlds, a linear program is developed with many passes. The model’s developers run the model many times, comparing its results with real data to uncover its flaws. Each run allows the developers to tune the model — its parameters and its constraints and perhaps even its basic logic — so that it becomes a better, more useful representation of reality. It starts out simple—simple enough for regular humans (even executives!) to understand and to believe. And then the real-world complexities are incorporated gradually, testing along the way, until the program is close enough to reality to be trusted. Once the match of the model with reality is “good enough”, it can be deployed into prime time use. And be trusted.