Unfortunately, as the scale of our endeavors increases, indeterminacy of consequence becomes untenable. If we want to build a six billion-dollar microchip fabrication facility, we would like to have a process for evaluating the design before committing money for its construction.
In actual practice, the manifestation of something as complex as a microfabrication facility rarely comes off perfectly. The problems that occur are the subject of further design analysis. If the statement of goals is not clearly related to the design in place, we may have a great deal of trouble fixing problems without disrupting another desirable behavior. In software, this is the problem of iatrogenic defects: changing code to fix a bug creates another bug, which is usually the failure of a feature that once satisfied the sponsor's intention.
So how do we manage these problems? Science does not impose an intention, and engineering resolves it. What is the glue that ties science and engineering to the intention of the sponsor?
This is the discipline of programming.
A programmer responds to the goals of the sponsor with a statement of an abstract operational hypothesis (variously called a plan, or a cause-and-effect network) that states the interaction of axiomatic means that are predicted to accomplish those goals. The program is abstract because it does not specify the geometry and components of the assemblage in sufficient detail to allow its construction. That is left to engineering analysis.
With the program in place, we now have the final process for tying intention to outcome:
- Possibilities are constrained by the axiomatic principles delineated by scientists.
- Goals are addressed through an operational hypothesis provided by programmers.
- A concrete construct, addressing a specific situation, is defined in an assembly designed by engineers.