The term functional fixedness stems from cognitive psychology and is altered by us to be applied to software engineering and reuse. This alteration results in three definitions. This 3-view interpretation gives a unifying concepts that refocuses the attention from components to the complete picture of frameworks, software engineers/reusers, and finally, components. We'll first explain the original meaning, then come up with the three software engineering definitions, state the current focus and end with the new focus.
Functional fixedness is a term from cognitive psychology referring to the way in which knowledge is learned for the solution of a specific problem. Such fixedness limits the range of perceptual organizations capable of being developed by the problem solver with respect to the learned knowledge, and as a result interferes with problem solving capacity with respect to the knowledge [13][4][3].
An example of the cognitive psychology meaning of the term is: when shown a box with tools, and getting the assignment: ``solve problem A with help of what you see here'', the people did not see the box that contained the tools as a tool to be used for the solving of A. They saw the box only as a container of the tools.
The definition as taken from the cognitive psychology literature does not in itself help us in an operational sense. We need to explore the analogy between general knowledge and software engineering knowledge in order to apply this principle. But of course we immediately see an analogy with reuse, where one has to use existing components not only in one application but also in other applications. In that case if knowledge of such components is tied closely to a former problem solution, it becomes difficult to see the applicability of that component to another problem. Specifically, (and paraphrasing our cognitive psychology definition) if a component is learned for the purposes of using it in one application then the (possibly) broad general properties of the component are learned as perceptions of specific, limited, functional characteristics.
In fact, by massaging the definition a little bit, and using an analogous interpretation, we make the definition apply for reuse and software engineering in a more general sense. In this we derive three different ``functional fixedness'' definitions:
Consider first the functional fixedness inherent in a component. An example of a component performing only one (set of) task(s) in one way, and in one context is an abstract data type for sequences of integers. Such an ADT can easily be generalized into an abstract data type for sequences of any type of elements. But this generalization doesn't buy us too much, since most software engineers can easily re-write its implementation without invalidating the specification and implementation constraints. Even though this generalization allows us to use the component in more than one context, it still performs only one set of tasks in one way.
Consider next functional fixedness from the software engineer's point of view. Suppose we need to implement a search tree, and choose a binary tree for the search tree structure. Focusing primarily on this application, we might not see that such a structure can also be used as an expression tree in a compiler. One might argue that we don't care at this point about expression trees for compilers. But this is exactly the point. We have solidified our view of a binary tree as a search tree because of the application, but we still have only a vague feel for a binary tree as an expression tree in a compiler, again because of our focus on the search tree application.
Another example of user view functional fixedness, one that we are all too familiar with, is our frustration and inability to cope with the wide range of features provided by our word processing/ spread sheet/ paint/ draw/ programming environment/ etc. software on our PC (which of course we all have). We tend to assimilate this knowledge in a functionally fixed way, learning only what we need to learn to do our work. The above problem is compounded by the fact that in order to properly use more complex components/sub-systems/software packages, one has to have intimate knowledge of the usage patterns of applications using such facilities.
Two examples, each at opposite ends of the ``abstraction continuum'' come to mind. The abstraction continuum meant here, is in terms of the top-to-bottom layering of a complex system implementation.
One is the use by a photographer of a complex photographic image processing package, and the other is the use by a systems programmer of a complex device controller interface. In both cases a tremendous amount of domain knowledge is required to use the facilities as they were intended to be used. In the case of the image processing software, tools to hi-light, low-light, darken, or lighten an image make little sense to a novice, and in the case of the device controller interface, disk heads can be destroyed in the hands of a novice. Ways to alleviate such problems are to give courses for photographers, and provide pre-packaged device drivers for complex devices.
Both of the first two ``views'' of functional fixedness focus on the components to be reused. The third interpretation of functional fixedness focuses on the framework in which components are reused. Specifically, when designing the framework for a problem solution, we tend to do so for that solution and not for the class of solutions of which it is a part. The focus on domain analysis rather than system analysis addresses this issue but from a top-down rather than bottom-up point of view. We also need to deal with functional fixedness in the framework design of mid-size components. Often a great deal of functional fixedness analysis of small components is lost if they are then composed into a functionally fixed mid-sized component framework.
As an example, a real-time feedback control module might be designed in a functionally fixed manner without an awareness that analogous feedback control modules are available for reuse. In this case the designer might not even be aware that the system is a control system, thus not being aware of the wide variety of analysis methods and tools available for such systems.
The actual functional fixedness of a component is typically what most reuse literature focuses on when considering design for reuse, and the software engineer's view of the problem solution is typically focused on (although in a functionally fixed way) when considering design with reuse. The software engineer's view of a component is typically not considered, essentially because the literature focuses on the reuse product and not the process.
What is also typically missed is that if one designs with reuse, the resulting product is also a component implementation, and needs to be analyzed with respect to design for reuse. Thus in order to achieve the elusive ``scale-up'', designing with reuse needs to always be done within the context of designing frameworks for reuse. Essentially the primary inhibitor of ``scale-up'' is when one designs for reuse ``in a vacuum''. In such a case components are viewed as stand-alone artifacts out of context of the framework or frameworks from which they originally were conceived.