As an extension to the discussion of Chapter 6, it's relevant at this point to reconsider how a feature such as Solver comes 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 at least understand 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 of the standard Solver add-in extremely difficult, and the resulting solutions prone to poor performance (substantially less-than-optimal managerial recommendations). One of the mechanisms that engines such as Solver commonly use to search for optimal solutions is a hill-climbing algorithm. In reality, this is just another heuristic (as discussed in Chapter 5). It starts with a guess for what the solution might be and then sees if small changes to any of the decision variables of that solution can result in better value for the objective function, 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.