The algorithmic approach to planning and scheduling requires that all possible
permutations of the problem be thought out in advance, an impossibility with problems
which change with time as the environment around them changes. The algorithm is a
crystallised and fixed way of doing things - perhaps perfectly valid on the day it was
conceived for the problem as then envisaged.
An algorithm often seems to be an easy way to automate a process, in
that the algorithm "keys into" and appears to fit the problem. The outline of
the algorithm can be quickly knocked up. Fleshing it out is usually not so easy. Putting
the finishing touches on a scheduling algorithm may take hours of running and months of
tweaking and tuning, while the process is slowly changing because of better techniques or
different resources becoming available. The end result is either that changes to the
process can’t be permitted because the algorithm can’t handle them, or the
algorithm is constantly being worked on and revised to keep it up to date, or junked in
favour of restarting from scratch.
Modern manufacturing techniques are continually pushing the plant to be more responsive in its outputs to the needs of the market. Building a rigid way of doing things into the process just to make the programmer’s lot easier or twisting the process to use some "off the shelf" algorithm seems like the wrong way around.
There is a better way. Instead of a programmer trying to build an algorithm whose behaviour mimics the operation of the plant, the planner can assemble a scheduling "machine" from pieces, and by changing the pieces and the logic that connects them, change the operation of the scheduler. This is the typical engineering approach - assemble components to make what you want. The desired operation comes from the interaction of the components, not from an algorithm. The more pieces and the more complex their connections, the more complex the behaviour, but any local area is understandable. With the algorithm, things can be changed from anywhere in the code, so you need to understand the whole algorithm before you can say with confidence what any part does.
The Non-Algorithmic approach embeds the logic of the application in the scheduling machine, not in an algorithm where it can only be changed with difficulty. The logic arises naturally from the way that elements are linked together, the elements themselves containing their own logic.
