Controlling functional fixedness: the essence of successful reuse

A common rule of thumb in making components reusable is to ‘make components generic’. Unfortunately, this is not always an easy task, due in large part to the tendency of software engineers to design implementations in ways that are functionally fixed. That is, software engineers tend to design (a) in a way that solves the particular problem at hand but is not easily generalizable, and (b) in such a way that opportunities to reuse existing components are not easily ‘seen’. The paper suggests how to manually uncommit design decisions from functionally fixed designs in such a way that their essence is kept. This uncommit process is done with the support of (a) reasoning by analogy, (b) statement of implications, (c) challenging of assumptions, and (of course) (d) previous experience/knowledge about both the problem domain and about general software engineering principles. It is shown how this method of working not only helps in designing a solution for a problem class instead of for a specific problem, but also how it helps in (a) seeing how a component can be applied, and (b) building (more reusable) components rather than (more) reusable components. The goal is thus to control functional fixedness in the design process both for and with reuse.