Continued from Parachuting Ants: Optimization vs. Automation Part I, Reinier breaks out the ant and parachute analogies to illustrate the difference between optimization and automation.

An optimizer explicitly searches for a good solution in terms of some predefined quality measure. A commonly used metaphor therefore is parachuting alpinists in order to measure the highest peak on earth: simply drop a parachutist at many places on earth and instruct him to start climbing where he lands. He can only go up, not down. Some may land in the Netherlands and end up on some 100m church tower, others may land in the Himalayas and climb a very high peak. If you take the highest point obtained by all parachutists, you get a good impression of the height of the highest peak on earth. Can you be certain that you will find the 8,848 m of Mount Everest every time? No, unfortunately not, but the more parachutists you drop the higher the probability that you will drop one of them in the Himalayas giving you a good chance to end up above 8,000 m.

One other analogy that I particularly like is the example of finding the shortest route between A and B, given a network or graph such as a road network. Mother nature has been optimizing for billions of years already, so no better source for inspiration than your own backyard when tackling complex puzzles. Simply put a picnic basket at a distance from a colony of ants and see how the ants crawl from their colony to the basket and back. Ants cannot smell the food in your picnic basket, so initially they wander around randomly. When they wander however, they lay down a pheromone trail. If other ants find such a path, they are likely not to keep traveling at random, but to instead follow the trail, making it even stronger. Over time, the pheromone trails do evaporate however, and will become less attractive for the ants to follow.

So you see where this is going: when one ant finds a good (short) trail from the colony to the delicious picnic basket, there is little time for it to evaporate, and many ants will follow his good example, making the trail even stronger again. On the other hand, the trail made by the lonely ant that went wandering off in the woods is evaporated even before this particular ant finds his way back to the colony and the path will most likely not be followed. Optimization in its purest form: a whole colony of ants working together to find the shortest path between the colony and a basket of food, actively looking for a better solution all the time.

What would an automation of the same problem look like? As stated before, it would imply following the same steps over and over again, so every ant would for instance “go left at the big tree because if you go right you have to circumvent the pond”. Another rule that automation might use is “whenever you hit a dead end move back turning 45 degrees, and eventually you’ll find the picnic basket”. These heuristics or rules of thumb used by the automation process often draw on domain knowledge (knowing where the tree and the pond are), whereas optimization is typically a more generic approach. All you need to specify are the rules of the game (an ant can’t walk through trees nor be at two places at the same time, an ant walks at a speed of 1cm per second and leaves a pheromone trail that evaporates in 10 minutes), and a solution can be found for arbitrary environments; which is why the ants have succeeded in finding picnic baskets ever since humans went picnicking.

So which one is better to use when an advanced planning & scheduling solution is called for? That’s hard to say in general, but it must be clear what the differences are and that in some cases automation is preferable, and in others only optimization can do the trick. In some cases, the input to the planning puzzle is so variable that a more generic puzzle solver is needed. It evaluates planning solutions compared to some quality measure (length of the total path from colony to food basket and back) and improves on that measure and chooses the best solution. Or there can simply be a lack of proper domain knowledge as to how to crack this puzzle optimally; and then it is practically impossible to automate how a human planner would typically go about and solve it in an acceptable way. In other cases however, problems seem much more generic than they really are, and by adding domain knowledge and good rules of thumb a good solution can be obtained much faster. In addition, restraining an optimizer from producing an impractical plan can be cumbersome (Planner comment: “we would never plan it like this ourselves!”) In those cases, the power of domain knowledge to steer automation can’t be underestimated and can lead to satisfactory solutions that can then either be finalized or fine tuned by hand. In some cases, automation can really be the optimal solution!