As an extension to the discussion in Chapter 6, it's relevant at this point to reconsider how a feature such as Solver can come up with a solution. Although it's not necessarily critical for developers to understand the detailed technicalities of these packaged programs, any developer worth his or her salt should understand at least the limitations of these algorithms.

How Solver “Solves”

Many people use Solver with the expectation that it can find the optimal solution for any kind of problem (of reasonable size). But even small problems can have their nuances that make the job extremely difficult for the standard Solver add-in, and the resulting solutions are prone to poor performance (substantially less-than-optimal managerial recommendations). Engines like Solver commonly use hill-climbing algorithms to search for optimal solutions. In reality, this is just another heuristic (see Chapter 5). It starts with a guess of what the solution might be and then it sees if small changes to any of the decision variables of that solution can result in better value for the objective function that is subject to constraints.

Hill-climbing algorithms typically look into only one solution at a time. For example, consider the following hypothetical performance surface (where performance along the z-axis is some function of the two decision variables x and y). In Figure 7.1, a shaded dot represents a possible solution, one that, at this point, appears to be less than ideal. From a local perspective, it certainly doesn’t represent the apparent peak value of z attainable (shown by an ellipse).